[ann] Minimal Python project

[Jimmy Retzlaff]

Edward K. Ream wrote:
>...
>The essence of what psyco is doing in this example is (cleverly!)
>discovering the types of Python objects and generating code to handle
>_those particular type of objects_.  A C compiler has no need of
>cleverness: the C programmer declares the types of those objects.  Thus
a C
>compiler starts out with the information that psyco must discover at
run
>time.
>...

Before I tried Psyco for the first time, I'd had a function that
performed unacceptably slowly in Python. It was nothing more than loop
with a series of comparisons and arithmetic on numbers - no advanced
data types, no explicit memory management, and no calls to other
functions. I had re-implemented it in C and was quite happy with the
resulting performance, if not the pain of having to maintain C code in
my application. When I tried Psyco, I thought it would be interesting to
see how close Psyco could come to the performance of my C function. When
I put the Python version of the function back into my application and
set Psyco loose on it, I was shocked to find it performing more than 2x
faster than the C version. I had to investigate...

What I concluded was that Psyco does have access to more information at
runtime than a compile-time optimizer. The source of the speed-up was
that Psyco knew how I was using my function while C just knew how I
declared it. In C, I used doubles for the parameters and local
variables. This was necessary because I need to call the function with
floating point values in my application. As it turns out, >95% of the
usage in my application is with integers. Psyco created two specialized
versions of my function - one for use with integers and another for use
with floating point numbers. The integer version was >2x faster than the
C version that used doubles. Out of curiosity I tested a C version that
was all ints and it was 2x faster than the Psyco integer version - but
with C I'd have to discover this usage on my own and then write and
maintain two separate versions of the function in order to beat Psyco's
speed and maintain the flexibility I needed, something I never would
have done.

So in my real world case, Python code with Psyco was faster than the
equivalent code in C. That's not to say that a faster alternative
couldn't be created in C, but that a faster version in C wouldn't have
been created because it would have required significantly more time
spent profiling and analyzing code (after already spending significantly
more time writing the code in the first place).

Optimizing compilers only have the information in the code at their
disposal - that's why they need all the information they can get in the
code (e.g., type information, hints/pragmas, etc.). A runtime optimizer
has the entire runtime environment to look at, including real world data
and actual type usage (rather than anticipated type usage). In fact,
static typing can even be a hindrance. In my case above, even a runtime
optimizer wouldn't have helped my floating point C code because my
integer data would have been promoted to doubles before the function was
called, and hence the integer optimizations would no longer be
available.

>...
>P.S.  Just for the record let me try to be as clear as possible.  Even
the
>most useful, interesting and clever engineering techniques have areas
in
>which they apply and areas in which they do not apply.  I have simply
been
>pointing out that psyco can not improve _all_ C code.  This is actually
a
>weak and not-very-interesting statement.  (And it was not, I think, the
>meaning intended in the original announcement.)  Again: psyco promises
to
>be of great benefit to all Python programmers.
>...

I agree!

Jimmy

p.s. -
Just imagine someone someday saying: C is fine for most of your
programming tasks, but for those time critical tight inner loops you
should use Python for performance reasons. Statically typed code just
can't be optimized for performance the way dynamically typed code can
be. :)