[Python] Python for Embedded Devices?

On questions of the suitability of Python for CGI, embedded apps, etc.,
execution speed comes to mind. I previously read some comparisons which
did not show Python in a good light in this regard: i.e. Python is slow
compared to Perl, C++, Java.

http://www.flat222.org/mac/bench/

Is there more authoritative and current information IRT speed comparisons?

Is newer Python any faster?

Also, if Python is a bit slower in execution than some alternative
languages, what do others do in practice to speed it up, and how much of
that optimization do they do? Or is a slower speed to be accepted like one
learns to accept that their lovely bride takes a long time getting ready to
go out ?

TIA,


Eric

P.S. I tried to replicate the simple "console test" with Python 2.3 on my
PC. Using the Windows command prompt, on a reasonably modern PC (128MB
RAM, 1.3 AMD chip), I clocked 72.45 seconds to print the numbers up to
999,999, which is more than 3x as long as the results reported in the link
given.

Then running the same program out of IDLE I clocked 627.48 seconds printing
the numbers only up to 99,999. Perhaps that's a caution about launching
any large processes out of IDLE? Here's the test script:

import time

def loop_time():
start=time.time()
for x in xrange(1000000):
print x
end=time.time()
exectime=end-start
return exectime

nada=raw_input('Press return when ready')
run=loop_time()
print 'Timed loop ran for: '+str(run)+' seconds'

EP> On questions of the suitability of Python for CGI, embedded
EP> apps, etc., execution speed comes to mind. I previously read
EP> some comparisons which did not show Python in a good light in
EP> this regard: i.e. Python is slow compared to Perl, C++, Java.

Donald Knuth, God of Computer Science, said "Premature optimization is
the root of all evil". The essence of the quote is that you shouldn't
code for performance until the current implementation is hogging a
disproportionate chunk of the CPU cycles. In layman's terms: code
something that works, and when you hit a performance bottleneck, run a
profiler, find the inefficiencies, and refactor looking for a 2-20x
performance boost.

I write python apps for the hospital I work for, mainly for epilepsy
patients. The EEG data files are large, several hundred megabytes
each, and in addition we have CT and MRI 3D image data to incorporate.
python, with judicious use of Numeric and pygtk, is more than enough
to handle the everyday cases. Are you dealing with several hundred
megabytes per record or more? If not, my guess is that you can handle
your use cases in python with a little careful thought.

In a Nut's Hell, write a prototype app. If you are unsatisfied with
performance, post here. Otherwise, mark today as the last day you
ever coded perl, as I fondly mark that day 5 years ago.

JDH

In article <mailman.43.1073115353.12720.python-list at python.org>,
John Hunter wrote:
If Knuth is God, then Hoare is God's father:

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare (often misattributed to Knuth, who was himself quoting Hoare)

"We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil." --Knuth restates Hoare

Grr...

aahz at pythoncraft.com (Aahz) writes:
This is from "Structured Programming with goto Statements", and he's
not quoting Hoare at this point. Really!

Cheers,
mwh

In article <m3brpi72rb.fsf at pc150.maths.bris.ac.uk>,
Michael Hudson wrote:
http://www.haskell.org/pipermail/haskell-cafe/2001-January/001461.html

Anybody have a copy of _Literate Programming_ to check?

Surely someone else must have checked this before now. Perhaps the
reply went astray, or isn't threaded properly so that I don't see it.
Anyway. Yes, Knuth says, in a parenthetical aside on page 276, "But I
also knew, and forgot, Hoare's dictum that premature optimization is
the root of all evil in programming."

Which fails to answer the quite reasonable wish for a cite attributing
the phrase, rather than the concept, to Hoare. (a distinction Cally
likes to troll in her .sig, as you know.)

(I can't believe that I have, by dint of rigorously ignoring all but
the most fascinating threads, gotten close enough to the working end of
this dynamic work-always-in-progress to feel I might have something to
add other than a belated footnote. Maybe if I got up at 2:30 AM every
day I could find time to read clp!)

EP:
These are usually pure compute benchmarks at the interpreted language
level. In practice I find that my Python programs perform somewhat better
than Java, probably because Python has many libraries implemented in C,
whereas Java has many pure Java libraries.

There have been a few projects to bring Python to "small" platforms like
handheld computers such as wince and palm. These are typically full
implementations of Python with a few omissions from the core language
(eg unicode, complex numbers) and a stripped-down set of standard
modules. I think this typically requires a meg or two for installation,
and I don't know whether these projects are actively maintained.

Jeff

In article <efa6f675.0401021920.3bffced0 at posting.google.com>,
Brandon wrote:
Yes.

And no. Yes, Python is certainly feasible for current
cellular telephones. I don't see it poised for explo-
sive growth there, but neither for technical defects
nor because of any lack of good wishes on my part.
'Twould thrill me to write more Python on embedded
projects.

The one point I'd emphasize when thinking about this
is that "embedded devices" covers a wide range, as I
believe you already know. Some developers commonly
work with hardware that's far, far more constrained
than are cellular telephones; others, who also program
embedded devices, can't be distinguished from vanilla
Linux coders.

claird at lairds.com (Cameron Laird) wrote in message news:<vvdl0nbogvm74 at corp.supernews.com>...
I am one such developer who works with very small systems: 8-bit
micros with under 128K flash and 4K RAM. I am keenly interested in
Python or some other similar langauge that would run on such hardware.
'C' is the usual language for such environments, but I believe that,
in many cases, using a dynamic and 'object-able' language would reduce
development time and improve product quality significantly.

I've looked at Io, Lua, PyMite and Pippy, to name a few, and none are
quite appropriate. Io is perhaps the closest match, if it were
stripped down a lot.

I have been tinkering around with some ideas to make a new language to
fit the environment I deal with. This is slow work, as I haven't a lot
of time to spend on it, and I am not a language design expert, but I'm
having fun with it!

Luxury! My current interest runs to microcontrollers with 2k flash, 128
bytes sram, and 128 bytes eeprom. Yours sounds a lot like one of the
larger models in the same line, though. (Atmel AVR)

It's actually quite fun, and since 128 bytes is too little to use
recursion or dynamic allocation for anything, stuff like reference
counting and GC are unneeded---not a lot of strings, either. C is a
not a bad language for this hardware.

Jeff

Hello Phil,
Have you looked at tinyscheme? It a full scheme interpreter in one C file.
http://tinyscheme.sourceforge.net/home.html
Maybe you can work with Fredrik Lundh on Pytte (http://effbot.org/zone/pytte.htm)

HTH.
Miki

(http://effbot.org/zone/pytte.htm)

Thanks for this link. There's nothing to download there, unfortunately. :^(

Something else that's interesting for embedded devices is an environment for
working in Python and generating the RTOS:

"WhatOS is a free open source embedded system development solution. It
provides a complete set of tools for creating high-quality, reliable embedded
systems. These include: a real-time operating system (RTOS) generator, a
simulator for testing and debugging generated systems, and tools for
interacting with systems remotely after they have been embedded."

http://www.sticlete.com/whatos/index.html


- --
Nicola Larosa - nico-NoSp at m-tekNico.net

"I am afraid that if the United States had to live by the [monetary]
rules that are imposed on, say, Brazil, the USA would become a
developing country in one generation. It's the system that is
currently unstable, unfair and not working." -- Bernard Lietaer

What about cases where the OS shields you from porting issues?

This is a question which interests me at the moment, as I'm
considering some future embedded work.

Python is available as a package for NetBSD. To what extent
does this mean that, if you can install NetBSD, you can run
a Python interpreter?

http://www.netbsd.org celebrates the fact that it targets
SBCs and some handheld devices.

Has anyone out there any experience of Python on NetBSD on embedded platforms?

Here's hoping,

Dave.

In article <33b7435c.0401050722.3b01a3d0 at posting.google.com>,
Dave wrote:
.
.
.
I'm quite confident that a good NetBSD installation will be
able to run (core) Python nicely. Was that your question?
While I haven't used NetBSD myself on any interesting hard-
ware, all my experience tells me the combination will be
robust.

Would you be willing to spend a sentence or two describing what basic
problems you feel each of those has for your application?

-Peter

brandon6684 at yahoo.com (Brandon) wrote in message news:<efa6f675.0401021920.3bffced0 at posting.google.com>...
Why only embeded devices?
It should possible to create complete J2EE like platform for python
for creating complex applications. [ i m no expert. lokking for a
simple discussion.]

In article <425cc8d1.0401030826.59a9d4ca at posting.google.com>,
mir nazim wrote:
.
.
.
This thread interests me, if only because you and the original
poster have such different perspectives from mine. I'm confi-
dent that Python can support something like J2EE in a technical
sense, and also that J2EE is an important part of Java--but is
it a *good* part? I'm sincerely unconvinced that there's much
there Python *should* emulate (apart from what Python already
has). J2EE's certainly a marketing success; I don't know what
it teaches us about how to rationalize application development,
though.

I'm even more certain that there's no model in prospect for
organizing the current Python development team to create such
a framework.

Briefly, I see J2EE, like .NET, as aimed at the commodification
of application development. It's aimed at "Enterprise" teams
of mediocre, alienated coders. I have no enthusiasm for Python
competing with that approach.

I would question the wisdom of using any generic benchmark (such as the
"console output test" you included) to make decisions about adoption of
key technologies.

Identify the core characteristics of your intended application, code up
a simple benchmark which contains representative code, and see how it
stacks up against the competition.

We did this with Python on one embedded system we were considering,
with a benchmark that included threading, memory allocation and releasing,
some simple math, and lots of string operations. The results told us
much more than PyStone or something similar would have, and gave us much
more confidence in the results.

And with Python, of course, it's almost trivial to do this kind of
thing, compared to some other languages. Sigh.

-Peter

[ on creating benchmarks ]

Peter> And with Python, of course, it's almost trivial to do this kind
Peter> of thing, compared to some other languages. Sigh.

Which was just another data point in your decision, right? After all, if
Python is so much easier to write your benchmarks in than some/most/all of
the alternatives, that has to factor into the choice of implementation
language.

Skip

Well, I suppose it would have been a factor in the decision, if the
decision had really been about which language to use. In fact in this
case we had already picked Python as a key technology, but needed to
see whether the performance of the hardware was adequate to support its
use. Doing it with C was an alternative, but we'd already tried a
prototype with C and concluded that while performance was fine, naturally,
we would not complete the required feature set in our lifetimes (or at
least in our funding's lifetime ;-) ).

To be completely honest: we ended up picking faster hardware in the long
run, but the choice was more because the trial platform was too limited
in RAM and ROM memory (1MB each) and had an inadequate development
platform. The final choice (as I mentioned in another thread today) uses
32MB RAM and ROM (Compact Flash actually) and happens to run at 100MHz
instead of the 33MHz of the first one.

Tying this in with yet another thread: we have spent next to no time
optimizing, so far, because we're still adding features and making things
work. I firmly believe we could have optimized the code for the
original 33MHz system to a point where it would have run acceptably,
and still in much less time than it would have taken to get a C version
running (that was the alternative possibility). I'm just happy we
were able to buy our way out of having to spend a lot of time optimizing.

In summary: we picked Python for reasons relating to ease of use
(development and maintenance) and flexibility, and performance was
really not a significant issue. As I've said before, we've written
literally hundreds of programs with it, ranging from small utilities
to major products, and have only *very* rarely had to pause to consider
performance and spend time optimizing anything. Python is *not* slow!

-Peter

Not necessarily. Only if you are sane.

Cheers,
Simon Brunning,
http://www.brunningonline.net/simon/blog/
-LongSig





-----------------------------------------------------------------------
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorised. If you are not the intended recipient, any disclosure,
copying, distribution, or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. TriSystems Ltd. cannot
accept liability for statements made which are clearly the senders own.