For a fast implementation of Python

[John Roth]

Alex Martelli wrote:
> cmdrrickhunter at yaho.com <conrad.ammon at gmail.com> wrote:
>
> > Psyco does some JIT compiling of Python, supposedly making it faster.
> > You do need to think a bit, however, beforehand.
> > If you really thing that the "speed" of execution is important for your
> > application, a scripting language such as python may be the wrong tool.
> >  A language such as C++ or Java which is designed to be a compiled
> > language can be optimized much faster than python because they impose
> > more rules.
>
> Java generally produces bytecode that is then run by a virtual machine,
> just like Python does; yes, Java has many more rules, but in general
> they're not ones particularly conducive to optimization -- in fact,
> optimization in Java generally hinges on just-in-time code generation
> just like psyco performs, and if such JIT VMs optimize better it's
> chiefly due to the huge number of person-years that have been devoted to
> perfecting them (as opposed to maybe 1 person-year spent on psyco).
>
> C and C++ do usually generate machine language directly, and their tools
> (optimizing compilers first and foremost) have enjoyed investments of a
> magnitude comparable to Java's (though, by now, Java's getting a lot
> more investment); moreover, C++'s rules _are_ heavily optimization
> oriented (e.g., no garbage collection -- being responsible for every bit
> of memory is a huge chore during application development, and a cause of
> many application bugs, but it DOES allow absolute maximal speed).

That's one of those "yes and no" answers. I remember a Java vs C++
performance comparison a few months ago that gave some really
surprising results: for programs that create a lot of 'by reference"
objects
Java is substantially faster than C++!

The reason is that Java's garbage collector is substantially faster
than
malloc. Sure, you can speed up C++ in that scenario by writing your
own allocator, but as you point out that's a substantial effort that
simply
isn't worth it unless you really, really need super performance.

When C++ was designed the latest garbage collector designs weren't
even on the drawing boards; committing to garbage collection would
have been a fairly controversial decision.

The same is true of Python: it spends a lot of time in reference
counting. My suspicion is that getting rid of reference counting in
the 3.x series might lead to a substantial speedup, simplify C and
C++ extension coding and eliminat reference counting bugs.
Interestingly, it doesn't seem to be in PEP 3099, so I suppose the
issue is still open.

If there was a simple way of using a compiler or language switch
in C++ that said: "use garbage collector", then the inherent speed
advantage of compiled over interpreted would come through. As it is,
C++
simply isn't in the speed race for _real_ object oriented  programs.
I'm not interested enough to follow the current round of the C++
standardization effort. It might be coming, it might not.

John Roth
> 
> 
> Alex