diff options
author | bde <bde@FreeBSD.org> | 2008-02-07 03:17:05 +0000 |
---|---|---|
committer | bde <bde@FreeBSD.org> | 2008-02-07 03:17:05 +0000 |
commit | 22e608f1ceb21dc3bb9bf5cda8f34642cc6e623f (patch) | |
tree | 39de11ac1fa020a02f07f29ebaac4e42ac04c4d5 /lib/libngatm | |
parent | 67c8e0948c3ec70e3bdfebe1cf5c79cf617f726b (diff) | |
download | FreeBSD-src-22e608f1ceb21dc3bb9bf5cda8f34642cc6e623f.zip FreeBSD-src-22e608f1ceb21dc3bb9bf5cda8f34642cc6e623f.tar.gz |
Use a better method of scaling by 2**k. Instead of adding to the
exponent bits of the reduced result, construct 2**k (hopefully in
parallel with the construction of the reduced result) and multiply by
it. This tends to be much faster if the construction of 2**k is
actually in parallel, and might be faster even with no parallelism
since adjustment of the exponent requires a read-modify-wrtite at an
unfortunate time for pipelines.
In some cases involving exp2* on amd64 (A64), this change saves about
40 cycles or 30%. I think it is inherently only about 12 cycles faster
in these cases and the rest of the speedup is from partly-accidentally
avoiding compiler pessimizations (the construction of 2**k is now
manually scheduled for good results, and -O2 doesn't always mess this
up). In most cases on amd64 (A64) and i386 (A64) the speedup is about
20 cycles. The worst case that I found is expf on ia64 where this
change is a pessimization of about 10 cycles or 5%. The manual
scheduling for plain exp[f] is harder and not as tuned.
This change ld128/s_exp2l.c has not been tested.
Diffstat (limited to 'lib/libngatm')
0 files changed, 0 insertions, 0 deletions