Hi, Kay Schluehr wrote: > > Why this? eval() consumes a string, produces a code object and executes > it. Wether the code-object is bytecode or a chunk of machine code makes > a difference in the runtime but does not alter the high level > behavioural description of eval(). In either way the compile() function > behind eval is a JIT. >
It makes a difference because 1) You depend on a compiler. Especially if you want to optimize the machine code you depend on a big program (no tcc for example) 2) Optimizing machine code, needs a lot of code/time. 3) What about debugging info? Dwarf? 4) What if there's a new architecture? The bytecode compiler is *much* faster to produce the bytecode assembly. Also, for the other part of the thread, I think that bytecode may be in fact faster than machine code JIT. Here is a theory: Suppose that for each algorithm there is the "ideal implementation" which executes at the speed limit where it can't be done any faster. For small algorithms the speed limit may be known but for more complex programs, it's just a theoretical limit. Now for such very big programs bytecode has the advantage that it achieves very good code re-use; everything is those 400kB of the libpython core and that does not increase with the size of the program. In this case, bytecode is the driver that operates the buldozer (the buldozer being C). So the theory is that for very complex programs a bytecode+core-library is closer to the ideal implementation than a JIT which produces/compiles megabytes of machine code. Evidence for that may be that all those JIT efforts don't get any great speed ups (psyco is different as it exposes static-ness). Of course, if we care about speed we'll use Pyrex to convert some heavy routines to C. For example if we need FFT, it's madness to do it in the HLL. Make it part of the buldozer. Stelios -- http://mail.python.org/mailman/listinfo/python-list
