On 10/17/2011 01:26 PM Alex Gaynor wrote:
On Mon, Oct 17, 2011 at 6:12 AM, Bengt Richter<b...@oz.net> wrote:
On 10/17/2011 12:10 AM Armin Rigo wrote:
Hi,
On Sun, Oct 16, 2011 at 23:41, David Cournapeau<courn...@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@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?
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
