how fast is Python?

[Jimmy Retzlaff]

Alex Martelli wrote:
> Irmen de Jong wrote:
>    ...
>> Nevertheless, a Psyco-optimized piece of Python code
>> that runs as fast as compiled C is still very impressive
>> to me. I know that JIT compiler technology theoretically
>> could produce better optimized code than a static optimizing
>> compiler, but am happy already if it reaches equal level :-)
>
> If anybody does have an actual example (idealy toy-sized:-)
> where psyco's JIT does make repeatably faster code than a
> C compiler (well-used, e.g. -O3 for gcc, NOT just -O...!-)
> I'd be overjoyed to see it, by the way.

In a way this comes back to practicality vs. purity. In a synthetic
benchmark where one function is called repeatedly with homogeneous data,
it's hard to imagine that a JIT compiler could ever outperform a good
optimizing C compiler. But that's the pure side of a performance
analysis. The practical side is how that function performs in a real
application where a JIT for a dynamically typed language has much more
information to work with than a C compiler does.

For example, a C compiler might only know that you declared a parameter
as a double and so it can only optimize for that. If you happen to call
the function more often than not with an int (that gets promoted to a
double on the way in) then the compiler generated code may waste a good
deal of time doing floating point arithmetic rather than integer
arithmetic. Now the programmer might take the time to profile their C
program and hopefully notice that time is being wasted doing floating
point arithmetic and then create an int version of their function, but
often practical constraints will get in the way of this happening.

This brings back memories of the old arguments about optimizing C
compilers being able to generate faster code that hand written assembly.
Of course an expert at assembly could write a faster program given
enough time, but most people didn't have the time or expertise to write
assembly code that could perform as well as optimized C once the
compilers attained a certain level of sophistication. In many practical
situations C is faster than assembly. PyPy is exciting because it
presents hope of providing the JIT with enough extra information and
flexibility that it may be able to make practical Python code outperform
practical C code in many cases.

The example above involving double/int was not just an example. It
happened in an application of mine a while back. I replaced a function
in a C extension with a Psyco-compiled Python version of the same
function and the performance of the part of my application that used the
function doubled. I posted a couple of notes about it. The first is
about a test in isolation (the pure test) and C was faster:

http://tinyurl.com/kpgd (includes Python code and links to C code)

The second note came later after I decided the slightly slower
Python/Psyco version was fast enough to eliminate the headaches of
maintaining the C extension. After replacing the C code I was startled
by a performance improvement in my application. This is the about the
practical test:

http://tinyurl.com/kpg6

And finally a bit of a caveat:

http://tinyurl.com/kpid

Jimmy