[pypy-dev] The first JITing pypy-c!
Richard Emslie
rxe at ukshells.co.uk
Thu Dec 14 19:02:34 CET 2006
Hi Armin!
Wow! So at risk of coming across really stupid, I am going to hazard a
guess at what is going on. :-)
As timeshifting is a translation time thing, we can handle mutiple or
recursive merge points as a one off atomic operation before we run. So
now when we run we have two modes of execution - 'compile mode' and
'normal mode'. (i hope at least this part is right!)
So now we are running our timeshifted translated code, where the original
rpython code defined a recursive interpreter, which in turn defined a
recursive function with a mergepoint. When we hit a flexiswitch (the
merge point?), we go from normal mode to compile mode and may promote /
partially evaluate run time variables for each new instance of a run time
variable (the promotion hinted ones). So what if a 'promotion' in compile
mode triggers another promotion down the line (ie during the timeshifted
residualizing code) and we go into a infinite loop of promoting?
Ok - so more questions than statements - and a high probabilty that
it made no sense to all - and maybe I should just wait for the docs! :-)
Cheers,
Richard
On Thu, 14 Dec 2006, Armin Rigo wrote:
> Hi Richard,
>
> On Thu, Dec 14, 2006 at 01:22:15AM +0000, Richard Emslie wrote:
>>> Fixed now. Jitting execution seems to work as well as the normal one.
>>> We tried various things, including stuff not supported by Psyco
>>> (generators, nested scopes...), with success.
>>
>> Very cool! But do recursive intepreters work now? :-)
>
> Yes, everything works :-) Except the bytecode trace hook. The machine
> code is really terrible at all points of view, but you can JIT whatever
> piece of Python code you like - generators, nested scopes, class:
> statement bodies, all these cases where Psyco give up. That's the point
> of the approach, really :-)
>
> We have a minor detail to solve before it can be tested on larger
> examples, though - it exhausts the 32-bit address space far too early
> (without actually consuming much of the reserved pages) and then we get
> a MemoryError. It's a back-end problem; Arre started working on that
> today.
>
>
> A bientot,
>
> Armin.
>
More information about the Pypy-dev
mailing list