Andrew Dalke <[EMAIL PROTECTED]> writes: > Years ago, presented at one of the Python conferences, was a program > to generate C code from the byte code.... The conclusion I recall > was that it wasn't faster - at best a few percent - and there was a > big memory hit because of all the duplicated code. One thought was > that the cache miss caused some of the performance problems. Does > that count as a compiler?
I would say it counts as a compiler and that other languages have used a similar compilation approach and gotten much better speedups. For example, Java JIT compilers. The DEC Scheme-to-C translator and Kyoto Common Lisp also produced C output from their compilers and got really significant speedups. Part of the problem may be with the actual Python language. One of the reasons for wanting real compilation as a high priority, is that the presence of a compiler will affect future evolution of the language, in a way that makes it more conducive to compilation. Despite the shrieks of the "Python is not Lisp!" crowd, Python semantics and Lisp semantics aren't THAT different, and yet compiled Lisp implementations com completely beat the pants off of interpreted Python in terms of performance. I don't think Python can ever beat carefully coded C for running speed, but it can and should aim for parity with compiled Lisp. -- http://mail.python.org/mailman/listinfo/python-list
