[pypy-dev] PyPy Assembler SQRT Patch

[Joe]

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 <qbproger at 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 <arigo at tunes.org> wrote:
>> Hi Alex,
>>
>> On Tue, May 3, 2011 at 6:23 PM, Alex Gaynor <alex.gaynor at 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 at codespeak.net
>> http://codespeak.net/mailman/listinfo/pypy-dev
>>
>