Alex Martelli wrote:
cm************@yaho.com <co**********@gmail.comwrote:
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
