Alex Martelli wrote: > [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
