My mistake. There was a bug so it appeared as though SQRTSD wasn't being used while running the tests. It turns out the first patch I posted probably worked. After benchmarking, SQRTSD is definitely the cause of the speedup. Sorry for the confusion.
Joe On Fri, May 6, 2011 at 1:29 PM, Joe <qbpro...@gmail.com> wrote: > 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 >> > _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
