[IronPython] Tracing JIT for the DLR

[Dino Viehland]

I think we get similar gains from our DynamicSite objects that we store at each call site.  These remember the types which were used (where type can be a .NET type or a Python type or a Ruby type or a ...) and then perform the same action if the "test" (we have the same type) passes.  We combine that w/ .NET generics so that if we have a statically known type at a call site (e.g. "a + 1") we can do things like flow the int through in it's unboxed form and not have to provide any tests for the int.  Finally the call sites are all computed at runtime so they're Just In Time as well :).  Now that's certainly not as sophisticated as a tracing JIT but it's a start.  We also have other optimizations which we layer on top of these and there's probably some small improvements to come here before 2.x is done.

The results of these call site optimizations can easily be seen when you run Pystone.  If you run it w/ the default number of iterations we're around the same as we were w/ 1.x.  But if you keep cranking up the number of iterations we keep getting faster and faster.  In 1.x we just stayed the same speed.

Finally we're looking at doing some more advanced optimizations - for example we might start inlining Python functions into the call sites as well as combining what are logically multiple call sites into a single call site with the combined operations.  But I wouldn't necessarily expect much more advancement here until 3.x.  I would assume the tracing here is some sort of "global", or above the call site, view of the program and we should definitely consider that when we get back to these sophisticated optimizations.



-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Sunday, May 25, 2008 12:17 PM
To: Discussion of IronPython
Subject: [IronPython] Tracing JIT for the DLR

Hello guys,

Just throwing a wild idea out. :-)

PyPy (an interpreter compiler toolchain written in Python) has a tracing
JIT that is gradually gaining in capabilities.

Similar to the tracing JIT in Tamarin (I believe) it traces types
through common code paths and generates specialised code for the common
paths and types. This is a great technique for optimising dynamic
languages, as although code paths can be taken with different types this
is fairly rare. If it does happen, dynamic dispatch can still happen.

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 :-)

I wonder if at some point in the future a similar technique could be
used to optimise DLR languages.

Michael Foord

--
http://www.ironpythoninaction.com/
http://www.theotherdelia.co.uk/
http://www.voidspace.org.uk/
http://www.ironpython.info/

_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com