Hi Michael, hi all
Michael Foord wrote:
One interesting consequence of this is that the .NET backend for PyPy
(interpreters compiled to run on the .NET framework) can still use the
tracing JIT. Although a PyPy compiled interpreter retains the full
semantics of the language it implements, it can generate specialised
.NET bytecode - using the native .NET types, where it provides a faster
path.
(A very hazy explanation based on my hazy understanding I'm afraid.)
Effectively PyPy compiled interpreters on .NET are double JITTed :-)
Actually, the CLI JIT backend of PyPy is work in progress and it's not
able to handle the full Python interpreter. But indeed, the basic idea
is that, and once the CLI JIT backend will be completed, we will have a
double jitted interpreter.
How fast/slow can it be, we don't know yet; very fast, we hope :-).
Btw, the CLI JIT backend has just reached its first milestone, i.e. to
be able to compile a minimal virtual machine for a simple toy language:
http://morepypy.blogspot.com/2008/05/progresses-on-cli-jit-backend-front.html
ciao,
Anto
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
