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

[Bengt Richter]

On 10/17/2011 01:26 PM Alex Gaynor wrote:
> On Mon, Oct 17, 2011 at 6:12 AM, Bengt Richter<bokr at oz.net>  wrote:
>
>> 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
>>
>>
>>
>> ______________________________**_________________
>> pypy-dev mailing list
>> pypy-dev at python.org
>> http://mail.python.org/**mailman/listinfo/pypy-dev<http://mail.python.org/mailman/listinfo/pypy-dev>
>>
>
> No, you would never hoist b * c because b * c isn't an operation in that
> loop, the only ops that exist are:
>
> t1 = a * b
> t2 = t1 * c
> z[i] = t2
>
d'oh

> even if we did do arithmetic reassosciation (which we don't, yet), you can't
> do them on floats.

Hm, what if you could statically prove that the fp ops gave bit-wise exactly the same results
when reordered (given you have 53 significant bits to play with)? (Maybe more theoretical question
than practical).

Regards,
Bengt Richter
P.S. What did you mean with the teaser, "(which we don't, yet)" ? When would you?