Hi, On Tue, Nov 22, 2011 at 09:47, Maciej Fijalkowski <[email protected]> wrote: > Everything works, but every instruction that can cause a switch (so > pretty much using *any* of stackless features) will disable jitting > for this loop. this is unideal, and I don't quite recall the exact > reasons why, other than "more work is needed". Armin, can you > elaborate?
It's actually only a switch() that disables JITting. The code for that is in pypy/module/_continuation/interp_continuation.py, workaround_disable_jit(). Read the comment. You may also try to comment out that function's body and rebuild pypy: you would get a pypy that is fast including on loops that use switch(), but that may crash if you use anywhere frame inspection (e.g. sys._getframe()). The fix needs to be done in the JIT, but it's not very clear how to fix it without an additional (small) overhead also in cases that don't use stackless at all. Anyway I suppose the first step is to do it in a branch, and worry about the small overhead later. Grep for FORCE_TOKEN in pypy/jit/metainterp: this is a resoperation that returns the address of the current assembler frame; in other words a pointer to the stack. But the stack may now move with _continuations. More precisely, the stacks are copied around in such a way that the currently running stack is always at the same location as it used to be; but the point is that when doing e.g. sys._getframe(bignum), we need to access a stack that may not be running at all right now. So we need a way to track such moves. For example it could be complemented with another operation (or some load of a global field) that would return some handle that changes when we switch(). The idea is that later, if and when we need to track down the saved stack, we can use the handle to know (maybe indirectly --- speed does not matter there) where the saved stack was copied to. A bientôt, Armin. _______________________________________________ pypy-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
