[pypy-dev] testing floating point

Paolo Giarrusso pgiarrusso at mathematik.uni-marburg.de
Thu Feb 3 00:28:41 CET 2011


On Thu, Feb 3, 2011 at 00:10, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
> 2011/2/3 Fredrik Johansson <fredrik.johansson at gmail.com>:
>> Indeed (that user was me, and it was nice to see the problem fixed so
>> quickly!). There is one incompatibility left between CPython and PyPy
>> that breaks some functions in mpmath. In CPython, round() and
>> functions in the math module accept (and convert) inputs of any custom
>> type with a __float__ method, whereas they trigger a TypeError in PyPy
>> (1.4).
>
> It seems corrected today; the script below indeed fails with pypy-1.4.
According to Fredik, the script is supposed to pass. By "corrected"
you mean it's fixed on the trunk?
>>>>> class C:
> ....   def __float__(self): return 42.0
> ....
>>>>> x = C()
>>>>> import math
>>>>> math.sqrt(x)
> 6.48074069840786

>>> I don't remember how fast is was, though.
>>
>> On win32, PyPy 1.4 is about 40% slower than CPython 2.6 for running
>> the entire set of tests. This is probably mostly due to the slowness
>> of longs in PyPy. However, much of the regular floating point code
>> seems to be slower in PyPy as well.
>
> The standard operations, or the math module?

> It seems that every function in the math module releases the GIL.
Does that module live in pypy/module/math/? Reading the source doesn't
show obvious interactions with the GIL, so I guess that for many other
modules the GIL is released automatically, potentially even for other
fast functions.

> This may explain some slowness.
In other words, a simple call to sin()/cos()/ceil() triggers a cache
flush (costing around ~100 cycles) because of releasing a lock, if not
a system call (costing thousands of cycles), say if the lock was
contended? If those functions were lifted to operate on lists they
should release the lock for long lists, otherwise it seems a bad idea.

In other words, I'd propose to remove the unlocking/relocking if
possible. Can that affect correctness for some weird reason? I'd guess
not, but I'm not familiar with the code enough to get fully what
happens.

Best regards
-- 
Paolo Giarrusso - Ph.D. Student
http://www.informatik.uni-marburg.de/~pgiarrusso/



More information about the Pypy-dev mailing list