intentional tease ( was: New Python User Question)

[Christian Tanzer]

Grant Griffin <not.this at seebelow.org> wrote:

> Python has become an essential tool for me, but, unfortunately, due to
> the speed/size issue, I'm able to use it only for "offline" PC tasks
> like this. My own production code generally runs in embedded systems.
> In those cases, due to the inherent requirement for maximum speed and
> minimum size, one has little choice but to use a compiled language.
> (Historically, due to compiler availability, one has had little choice
> in DSP but to use C, though C++ compilers have recently become
> available for DSP microprocessors.)
> 
> In embedded systems (and many other application domains), using an
> interpreter is simply not an option. Other posts in this thread have
> suggested that the lesser speed of Python is worth what you gain in
> development time. I wholeheartedly agree--at least in those cases
> where you can trade the two. For the offline data processing I do,
> it's a no-brainer: use Python.
> 
> But depending on how many embedded boxes one plans to sell, the ease
> of development of Python can _truly_ be false economy, if it forces
> you to put $10 of extra computer inside the box. (Python still makes a
> good prototyping language, though.) More imporatantly, you sometimes
> simply couldn't get there from here if you used an interpreter.

True. Incidentally, I'm programming design tools for high-volume
embedded systems. In our market, they fight to shave of cents (for
some nodes, the whole embedded CPU costs a few dollars).

So for some embedded code, we use Python to generate C code to be
embedded <wink>.

> Although there are might be some folks who can spend 100.0% of their
> programming lives in Python (except when they have to write extension
> modules <wink>), I suspect that _most_ folks who use Python do part of
> their work in Python and part in a compiled language--probably C/C++.

Since about two years, I'm one of the lucky 95%+ Python programmers.
Sometimes I do reviews of C code...

> *KEY POINT*: Anything that greatly speeds Python (and a compiler--in
> whatever form--is the only thing we can reasonably expect would, after
> 10 years of careful tweaking by lots of talented folks!) increases the
> percentage of programs we can write in Python. That is undeniably A
> Good Thing.

Agreed. As long as it doesn't take away Python's strengths.

> However, in working on my little project, I've realized that even
> leaving dynamic variables aside, certain things in the design of
> Python are inherently "slow". A simple example is the fact that Python
> allows negative array indices. When implementing that, one can only
> check for a negative index, then add the length. And even if it wasn't
> negative, you have to bounds-check the result, to possibly raise an
> IndexError. (An "assert" won't do: the Python code might have been
> written to rely on an IndexError.)
> 
> Therefore, compiled Python will always be slower than something
> written from scratch in C++ (which doesn't do bounds-checking: you
> write it where you need it rather than it happening automatically in
> every case).

I don't agree with this. Two points:

- In a former life, I implemented a big C++ system. The code used
  Eiffel-style assertions (implemented as C macros). For the
  production code, only preconditions were enabled -- postconditions
  and invariants were checked during testing. Disabling the
  preconditions increased application performance by about 10% -- not
  worth the gain, IMHO.

  OTOH, making a key class (linked list) non-dynamic (i.e., removing
  all inheritance relations and virtual statements) increased
  application performance by about 20% -- still not worth the pain,
  IMNSHO.

  The real bottleneck of that application lies somewhere in the depths
  of a flex-generated module doing macro expansions -- pure C and very
  hard too fix.

- If your compare Python and C++ programs implementing exactly the
  same algorithm, C++ will always be faster. But that's a unrealistic
  case.

  Normally, the Python program will be ready to run in a fraction of
  the time of the C++ program. Even in the first version, the Python
  program might use smarter algorithms -- due to the lower cognitive
  overhead of Python, the programmer has more cycles left to think
  about the application at hand. And long before the C++ version is
  ready, the hot spots of the Python version might have seen multiple
  rounds of optimization...

> Although Python has a few methods common among strings, lists, and
> tuples, any code that uses a special string method (e.g. split) wants
> the string to be statically typed: you're not going to be using that
> code for lists, tuples, ints, floats, files, etc.
> 
> I bet there's nobody who has used Python for more than a month that
> hasn't used a string method. Moral of the story: even those who claim
> to do a lot of generic programming don't do it 100.0% of the time, so
> even they can benefit from a little static typing.

Except for the little difference between "" and u"".



-- 
Christian Tanzer                                         tanzer at swing.co.at
Glasauergasse 32                                       Tel: +43 1 876 62 36
A-1130 Vienna, Austria                                 Fax: +43 1 877 66 92