"sturlamolden" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | Franz, CMUCL, SBCL and GCL teams made Lisp almost as fast as C. A | dynamic language can be fast if the implementation is good. | | If you look at SBCL and GCL, no code is interpreted. It's all compiled | on the fly to native machine code.
Unfortunately, native machine code depends on the machine, or at least the machine being emulated by the hardware. Fortunately or not, the dominance of the x386 model makes this less of a problem. | The compiler begins with some code | and some input data, and compiles as much as it can. Then the RT | executes the machine code, compiles again, etc. Often long stretches | of code can be compiled without break, and tight performance critical | loops are usually compiled only once. In addition to this, one needs | an efficient system to cache compiled code, in order to do the | compilation work only once. making a dynamic language fast is not | rocket science. This sound somewhat similar to Psyco. If a code section is entered with different machine types, recompilation is needed. One of the problems with Psyco is that its efficient caching of multiple versions of compiled code is space-hungry. | We should have somthing like "GPython", a Python RT on top of a GCC | backend, similar to what the GCL team did for Lisp. There is no | obvious reason as to why Lisp should have better performance than | Python. In the 1980s, during the Lisp/AI boom, perhaps a billion dollars was put into making Lisp run faster. Plus decades of work in Computer Science departments. Other than that, I agree. Now, Python is slowly making inroads into academia as a subject of research and theses, and the PyPy group got at least one large EU grant. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list