On Thu, Jul 1, 2010 at 1:18 PM, Hakan Ardo <Hakan@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 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.
Are there some docs to get me started at writing interpreter level objects? I've had a look at _rawffi/array.py and am a bit confused about the W_Array.typedef = TypeDef('Array',...) construction. Maybe there is a easier example to start with?
TypeDef is a way to expose interpreter level (RPython) object to app-level (Python). It tells what methods there are what properties and what attributes.
On Thu, Jul 1, 2010 at 5:40 PM, Alex Gaynor <alex.gaynor@gmail.com> wrote:
On Thu, Jul 1, 2010 at 10:35 AM, Maciej Fijalkowski <fijall@gmail.com> wrote:
On Thu, Jul 1, 2010 at 9:28 AM, Armin Rigo <arigo@tunes.org> wrote:
Hi,
On Thu, Jul 01, 2010 at 04:02:30PM +0200, Hakan Ardo wrote:
are there any python construct that the jit will be able to compile into c-type array accesses? Consider the following test:
l=0.0 for i in xrange(640,640*480): l+=img[i] intimg[i]=intimg[i-640]+l
This is still implemented as a list of Python objects (as expected, because the JIT cannot prove that we won't suddenly try to put something else than a float in the same list).
Using _rawffi.Array('d') directly is the best option right now. I'm not sure why the array.array module is 400 times slower, but it's definitely slower given that it's implemented at app-level using a _rawffi.Array('c') and doing the conversion by itself (for some partially stupid reasons like doing the right kind of error checking).
A bientot,
Armin.
The main reason why _rawffi.Array is slow is that JIT does not look into that module, so there is wrapping and unwrapping going on. Relatively easy to fix I suppose, but _rawffi.Array was not meant to be used like that (array.array looks like a better candidate). _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
If array.array performance is important to your work, the array.py module looks like a good target for writing at interp level, and it's not too much code.
Alex
-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
-- Håkan Ardö
Hi, I've got a simple implementation of array now, wrapping lltype.malloc with no error checking yet (cStringIO was great help, thx). How can I test this with the jit? Do I need to translate the entire pypy or is there a quicker way?
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.
Do I need to guard the lltype.malloc call with such hints? What is the syntax? -- Håkan Ardö
On Fri, Jul 2, 2010 at 1:37 AM, Hakan Ardo <hakan@debian.org> wrote:
Hi, I've got a simple implementation of array now, wrapping lltype.malloc with no error checking yet (cStringIO was great help, thx). How can I test this with the jit? Do I need to translate the entire pypy or is there a quicker way?
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.
Do I need to guard the lltype.malloc call with such hints? What is the syntax?
I can see into making raw_malloc just a call from JIT. That shouldn't be a big issue. For now you can either: a) use from pypy.rlib import rgc and use rgc.malloc_nonmovable (not sure if jit'll like it), so you'll get a gc-managed non-movable memory b) just wrap call to malloc in a function with decorator dont_look_inside (from pypy.rlib.jit)
On Fri, Jul 2, 2010 at 08:04, Maciej Fijalkowski <fijall@gmail.com> wrote:
On Thu, Jul 1, 2010 at 1:18 PM, Hakan Ardo <Hakan@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 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/
On Fri, Jul 2, 2010 at 09:47, Paolo Giarrusso <p.giarrusso@gmail.com> wrote:
On Fri, Jul 2, 2010 at 08:04, Maciej Fijalkowski <fijall@gmail.com> wrote:
On Thu, Jul 1, 2010 at 1:18 PM, Hakan Ardo <Hakan@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 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/
On Fri, Jul 2, 2010 at 1:47 AM, Paolo Giarrusso <p.giarrusso@gmail.com> wrote:
On Fri, Jul 2, 2010 at 08:04, Maciej Fijalkowski <fijall@gmail.com> wrote:
On Thu, Jul 1, 2010 at 1:18 PM, Hakan Ardo <Hakan@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 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.
participants (3)
-
Hakan Ardo -
Maciej Fijalkowski -
Paolo Giarrusso