Attached an updated patch. It actually generates the assembly now to use SQRTSD. It provides about the same performance as the previous patch. Because of that, I feel as though the performance gain can be attributed to the change in error checking.
It might be worth splitting out the other math functions and slimming down the error checking. Right now in the new_unary_math_function it generates a math function that does 3 C library calls 2 errno calls and the math function itself. The patch takes this down to the minimal number of checks necessary for math.sqrt, making only an isfinite() call in addition to the sqrt() call best case. Previously it'd call "_error_reset(); c_func(); rposix.get_errno()" and then at least 1 call to isnan() and a call to either isnan() or isinf(). Does this seem like something worth looking into for the other math functions? It wouldn't be as hard as getting the whole assembly instruction working, and seems like it provides the majority of the performance gain. Joe On Tue, May 3, 2011 at 12:28 PM, Armin Rigo <ar...@tunes.org> wrote: > Hi Alex, > > On Tue, May 3, 2011 at 6:23 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: >> Another thing is it would be useful to test that the SQRTSD is generated, I >> don't know a good way to do that though. > > In the test, you can hack genop_math_sqrt() in-place to set a flag, > and test that the flag is set... > > And another place it should also be tested is in test_pypy_c_new.py > (pypy.module.pypyjit.test_pypy_c), i.e. you should write a test that > checks that in a full translated pypy-c, the code corresponding to the > Python source "math.sqrt(x)" indeed ends up being a CALL(sqrt_wrapper) > and not a CALL(ll_math_sqrt). > > > A bientôt, > > Armin. > _______________________________________________ > pypy-dev@codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev >
sqrtsd.patch
Description: Binary data
_______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
