[pypy-dev] array performace?
fijall at gmail.com
Fri Jul 2 10:14:36 CEST 2010
On Fri, Jul 2, 2010 at 1:47 AM, Paolo Giarrusso <p.giarrusso at gmail.com> wrote:
> On Fri, Jul 2, 2010 at 08:04, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> On Thu, Jul 1, 2010 at 1:18 PM, Hakan Ardo <Hakan at ardoe.net> 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
>> 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
> 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.
More information about the Pypy-dev