On Thu, Jul 1, 2010 at 10:35 AM, Maciej Fijalkowski <[email protected]> wrote: > On Thu, Jul 1, 2010 at 9:28 AM, Armin Rigo <[email protected]> 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). > _______________________________________________ > [email protected] > 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 _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
