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

[Alex Gaynor]

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

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

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20111017/98c1dd47/attachment.html>