On Fri, Jul 2, 2010 at 08:04, Maciej Fijalkowski <[email protected]> wrote: > On Thu, Jul 1, 2010 at 1:18 PM, Hakan Ardo <[email protected]> wrote: >> OK, so making an interpreter level implementation of array.array seams >> like a good idea. Would it be possible to get the jit to remove the >> wrapping/unwrapping in that case to get better performance than >> _rawffi.Array('d'), which is already an interpreter level >> implementation? > > it should work mostly out of the box (you can also try this for > _rawffi.array part of module, if you want to). It's probably enough to > enable module in pypy/module/pypyjit/policy.py so JIT can have a look > there. In case of _rawffi, probably a couple of hints for the jit to > not look inside some functions (which do external calls for example) > should also be needed, since for example JIT as of now does not > support raw mallocs (using C malloc and not our GC).
> Still, making an > array module interp-level is probably the sanest approach. That might be a bad sign. For CPython, people recommend to write extensions in C for performance, i.e. to make them less maintainable and understandable for performance. A good JIT should make this unnecessary in as many cases as possible. Of course, the array module might be an exception, if it's a single case. But performance 20x slower than C, with a JIT, is a big warning, since fast interpreters are documented to be (in general) just 10x slower than C. In this case, the JIT should be instructed to look into that module; if the result is still slow, the missing optimizations need to be traced down and added. Also, it seems that at some point in the future, the JIT should in general look into the whole standard library by default _and_ learn to be careful to such external calls. Isn't it? Comments appreciated. Best regards -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/ _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
