PATCH: optimized libm single precision routines: erfcf, erff, expf for x86_64.
Dmitrieva Liubov
liubov.dmitrieva@gmail.com
Mon Feb 27 19:16:00 GMT 2012
Thanks for your changes.
About j: no sense to treat it as signed. Here is updated algorithm
with table of 2^(j/K) for j=[0;K-1]. Please, see new attached patch.
About the benchmark: this is just perfomance in cycles for main
interval [-87.0; 87.0].
Results:
Istanbul/Atom/Nehalem/AVX
Attached version: 51.63 97.23 31.12 25.34 (__AVX__
enabling gives 24.98 cycles on AVX.)
About stability: We used "make check". Also we used proprietary test
system that tests on many intervals with different steps, checks for
special values (from ISO C) and corner cases.
--
Liubov Dmitrieva
Intel Corporation
2012/2/22 Ulrich Drepper <drepper@gmail.com>:
> This time with attachment.
>
> On Wed, Feb 22, 2012 at 10:14, Ulrich Drepper <drepper@gmail.com> wrote:
>> On Tue, Feb 21, 2012 at 15:32, Dmitrieva Liubov
>> <liubov.dmitrieva@gmail.com> wrote:
>>> The updated attached version is significantly hand-tuned assembler code.
>>> We are looking forward to accepting and releasing this change.
>>
>> At least the changes made to the attached version should be made.
>> They are small but save another cycle or two.
>>
>> I don't see why the computation of j has to be that complicated. 6
>> bits are taken from the mantissa. These are then interpreted as a
>> signed value. Why? I know it works but is there really a reason?
>>
>> If the bits are considered are unsigned that computation for the
>> access of the array DP_T as well as the computation of n*k are
>> simpler (only AND, no shifting and subtracting). The algo has to be
>> adapted but this should be possible. I think nobody really paid
>> attention to that since the DP_T table was too large (it had 65
>> entries!).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: exp.patch
Type: application/octet-stream
Size: 11381 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20120227/7a65e995/attachment.obj>
More information about the Libc-alpha
mailing list