[pypy-dev] array performace?
alex.gaynor at gmail.com
Thu Jul 1 17:40:38 CEST 2010
On Thu, Jul 1, 2010 at 10:35 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> On Thu, Jul 1, 2010 at 9:28 AM, Armin Rigo <arigo at tunes.org> wrote:
>> 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:
>>> for i in xrange(640,640*480):
>> 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,
> 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 at codespeak.net
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.
"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
More information about the Pypy-dev