FAQ

[Python] Python for Embedded Devices?

Brandon
Jan 3, 2004 at 3:20 am
Java seems to have taken off as the platform and language of choice
for many embedded devices. Would it be feasible for Python(perhaps
running on an embedded version of Linux) to act in such a capacity.
Most of my experience with Python has been with Unix-type scripting
tasks and using it when it is an applications built in scripting, but
I know some people try to use to build larger complex applications. Is
the Python interpreter portable and good enough to be used in resource
constrained devices like cell phones?
reply

Search Discussions

22 responses

  • EP at Jan 3, 2004 at 7:01 am
    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'
  • John Hunter at Jan 3, 2004 at 7:27 am
    "EP" == EP <EP at zomething.com> writes:
    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
  • Aahz at Jan 3, 2004 at 3:26 pm
    In article <mailman.43.1073115353.12720.python-list at python.org>,
    John Hunter wrote:
    Donald Knuth, God of Computer Science, said "Premature optimization is
    the root of all evil".
    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
    --
    Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/

    Weinberg's Second Law: If builders built buildings the way programmers wrote
    programs, then the first woodpecker that came along would destroy civilization.
  • Michael Hudson at Jan 5, 2004 at 4:56 pm
    Grr...

    aahz at pythoncraft.com (Aahz) writes:
    In article <mailman.43.1073115353.12720.python-list at python.org>,
    John Hunter wrote:
    Donald Knuth, God of Computer Science, said "Premature optimization is
    the root of all evil".
    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) Cite?
    "We should forget about small efficiencies, say about 97% of the time:
    premature optimization is the root of all evil." --Knuth restates Hoare
    This is from "Structured Programming with goto Statements", and he's
    not quoting Hoare at this point. Really!

    Cheers,
    mwh

    --
    Or here's an even simpler indicator of how much C++ sucks: Print
    out the C++ Public Review Document. Have someone hold it about
    three feet above your head and then drop it. Thus you will be
    enlightened. -- Thant Tessman
  • Aahz at Jan 5, 2004 at 7:53 pm
    In article <m3brpi72rb.fsf at pc150.maths.bris.ac.uk>,
    Michael Hudson wrote:
    aahz at pythoncraft.com (Aahz) writes:
    In article <mailman.43.1073115353.12720.python-list at python.org>,
    John Hunter wrote:
    Donald Knuth, God of Computer Science, said "Premature optimization is
    the root of all evil".
    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)
    Cite?
    http://www.haskell.org/pipermail/haskell-cafe/2001-January/001461.html

    Anybody have a copy of _Literate Programming_ to check?
    --
    Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/

    A: No.
    Q: Is top-posting okay?
  • Martin Maney at Jan 11, 2004 at 5:07 am

    Aahz wrote:
    In article <m3brpi72rb.fsf at pc150.maths.bris.ac.uk>,
    Michael Hudson wrote:
    aahz at pythoncraft.com (Aahz) writes:
    "Premature optimization is the root of all evil in programming."
    --C.A.R. Hoare (often misattributed to Knuth, who was himself quoting Hoare)
    Cite?
    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!)

    --
    One lesson I've learned from my years as Linux's hood ornament is that
    there's something worse: some folks can't be content to just take things
    too seriously on their own. They're not happy unless they can convince
    others to go along with their obsession. -- Linus
  • Rene Pijlman at Jan 3, 2004 at 1:57 pm
    EP:
    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.
    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.

    --
    Ren? Pijlman
  • Jeff Epler at Jan 3, 2004 at 1:58 pm
    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
  • Cameron Laird at Jan 3, 2004 at 2:39 pm
    In article <efa6f675.0401021920.3bffced0 at posting.google.com>,
    Brandon wrote:
    Java seems to have taken off as the platform and language of choice
    for many embedded devices. Would it be feasible for Python(perhaps
    running on an embedded version of Linux) to act in such a capacity.
    Most of my experience with Python has been with Unix-type scripting
    tasks and using it when it is an applications built in scripting, but
    I know some people try to use to build larger complex applications. Is
    the Python interpreter portable and good enough to be used in resource
    constrained devices like cell phones?
    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.
    --

    Cameron Laird <claird at phaseit.net>
    Business: http://www.Phaseit.net
  • Phil Schmidt at Jan 4, 2004 at 11:37 pm
    claird at lairds.com (Cameron Laird) wrote in message news:<vvdl0nbogvm74 at corp.supernews.com>...
    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.
    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!
  • Jeff Epler at Jan 5, 2004 at 1:28 am

    On Sun, Jan 04, 2004 at 03:37:46PM -0800, Phil Schmidt wrote:
    I am one such developer who works with very small systems: 8-bit
    micros with under 128K flash and 4K RAM. [...]
    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
  • Miki Tebeka at Jan 5, 2004 at 7:07 am
    Hello Phil,
    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.
    Have you looked at tinyscheme? It a full scheme interpreter in one C file.
    http://tinyscheme.sourceforge.net/home.html
    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!
    Maybe you can work with Fredrik Lundh on Pytte (http://effbot.org/zone/pytte.htm)

    HTH.
    Miki
  • Nicola Larosa at Jan 5, 2004 at 9:01 am

    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!
    Maybe you can work with Fredrik Lundh on Pytte
    (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
  • Dave at Jan 5, 2004 at 3:22 pm
    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.
  • Cameron Laird at Jan 5, 2004 at 4:45 pm
    In article <33b7435c.0401050722.3b01a3d0 at posting.google.com>,
    Dave wrote:
    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?
    .
    .
    .
    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.
    --

    Cameron Laird <claird at phaseit.net>
    Business: http://www.Phaseit.net
  • Peter Hansen at Jan 6, 2004 at 1:39 pm

    Phil Schmidt wrote:
    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.
    Would you be willing to spend a sentence or two describing what basic
    problems you feel each of those has for your application?

    -Peter
  • Mir nazim at Jan 3, 2004 at 4:26 pm
    brandon6684 at yahoo.com (Brandon) wrote in message news:<efa6f675.0401021920.3bffced0 at posting.google.com>...
    Java seems to have taken off as the platform and language of choice
    for many embedded devices. Would it be feasible for Python(perhaps
    running on an embedded version of Linux) to act in such a capacity.
    Most of my experience with Python has been with Unix-type scripting
    tasks and using it when it is an applications built in scripting, but
    I know some people try to use to build larger complex applications. Is
    the Python interpreter portable and good enough to be used in resource
    constrained devices like cell phones?
    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.]
  • Cameron Laird at Jan 3, 2004 at 6:01 pm
    In article <425cc8d1.0401030826.59a9d4ca at posting.google.com>,
    mir nazim wrote:
    .
    .
    .
    It should possible to create complete J2EE like platform for python
    for creating complex applications. [ i m no expert. lokking for a
    simple discussion.]
    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.
    --

    Cameron Laird <claird at phaseit.net>
    Business: http://www.Phaseit.net
  • Peter Hansen at Jan 6, 2004 at 1:44 pm

    EP wrote:
    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 ?
    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
  • Skip Montanaro at Jan 6, 2004 at 4:21 pm
    [ 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
  • Peter Hansen at Jan 6, 2004 at 6:49 pm

    Skip Montanaro wrote:
    [ 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.
    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
  • SBrunning at Jan 6, 2004 at 4:32 pm

    From: Skip Montanaro [SMTP:skip at pobox.com]
    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.
    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.

Related Discussions