[pypy-dev] Contributing to pypy [especially numpy]

[Bengt Richter]

On 10/17/2011 12:10 AM Armin Rigo wrote:
> Hi,
>
> On Sun, Oct 16, 2011 at 23:41, David Cournapeau<cournape at gmail.com>  wrote:
>> Interesting to know. But then, wouldn't this limit the speed gains to
>> be expected from the JIT ?
>
> Yes, to some extent.  It cannot give you the last bit of performance
> improvements you could expect from arithmetic optimizations, but (as
> usual) you get already the several-times improvements of e.g. removing
> the boxing and unboxing of float objects.  Personally I'm wary of
> going down that path, because it means that the results we get could
> suddenly change their least significant digit(s) when the JIT kicks
> in.  At least there are multiple tests in the standard Python test
> suite that would fail because of that.
>
>> And I am not sure I understand how you can "not go there" if you want
>> to vectorize code to use SIMD instruction sets ?
>
> I'll leave fijal to answer this question in detail :-)  I suppose that
> the goal is first to use SIMD when explicitly requested in the RPython
> source, in the numpy code that operate on matrices; and not do the
> harder job of automatically unrolling and SIMD-ing loops containing
> Python float operations.  But even the later could be done without
> giving up on the idea that all Python operations should be present in
> a bit-exact way (e.g. by using SIMD on 64-bit floats, not on 32-bit
> floats).
>
>
> A bientôt,
>
> Armin.
I'm wondering how you handle high level loop optimizations vs
floating point order-sensitive calculations. E.g., if a source loop
has z[i]=a*b*c, might you hoist b*c without considering that
assert a*b*c == a*(b*c) might fail, as in

 >>> a=b=1e-200; c=1e200
 >>> assert a*b*c == a*(b*c)
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
AssertionError
 >>> a*b*c, a*(b*c)
(0.0, 1e-200)

Regards,
Bengt  Richter