[Python-Dev] A new JIT compiler for a faster CPython?
solipsis at pitrou.net
Sat Jul 21 12:56:29 CEST 2012
On Sat, 21 Jul 2012 11:45:21 +0100
Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> On 20 Jul 2012, at 17:50, Maciej Fijalkowski wrote:
> > On Fri, Jul 20, 2012 at 2:55 PM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> > On 17 Jul 2012, at 23:04, martin at v.loewis.de wrote:
> > >> [snip...]
> > >
> > >> I would like to use a JIT to generate specialized functions for a
> > >> combinaison of arguments types.
> > >
> > > I think history has moved past specializing JITs. Tracing JITs are the
> > > status quo; they provide specialization as a side effect.
> > >
> > Mozilla implemented a method-JIT (compile whole methods) on top of their tracing JIT because a tracing JIT only optimises part of your code (only in loops and only if executed more times than the threshold) and there are further performance improvements to be had. So tracing JITs are not the *whole* of the state of the art.
> > Michael
> > I'm sorry michael but you're like a 100th person I have to explain this to. The pure reason that mozilla did not make a tracing JIT work does not mean the entire approach is horribly doomed as many people would like to assume. The reasons are multiple, but a lot of them are connected to poor engineering (for example the part inherited from adobe is notoriously bad, have a look if you want).
> Well, that isn't how they describe it. If it is the case, it's *still* interesting
> that rather than putting their efforts into improving the tracing JIT they put them
> into adding a method-JIT *as well*.
Honestly I'm not sure that's a very interesting discussion. First,
performance: for the former, startup time is key. Second, whether
method-based or tracing-based, a well-written JIT would certainly bring
significant performance improvements over a bytecode interpreter anyway.
Software development and contracting: http://pro.pitrou.net
More information about the Python-Dev