On Fri, Jul 2, 2010 at 09:47, Paolo Giarrusso <[email protected]> wrote: > 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.
Here, I forgot to state explicitly that having to rewrite a module at the interpreter level is somehow similar. Imagine that was suggested, the day PyPy will be standard, to application authors. > 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. -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/ _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
