On Fri, Jul 2, 2010 at 1:47 AM, 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. > 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.
There is a lot of unsupported claims in your sentences, however, that's not my point. array module is the main source in Python for single-type arrays (including C types which are not available under Python). The other would be numpy. That makes sense to write in C/RPython, since it's lower-level than Python has. _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
