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

Alex Gaynor alex.gaynor at gmail.com
Mon Oct 17 13:26:04 CEST 2011

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.


"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>

More information about the pypy-dev mailing list