This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug math/15384] One constant fewer in ieee754/dbl-64/wordsize-64/s_finite.c
- From: "ondra at iuuk dot mff.cuni.cz" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sun, 21 Apr 2013 17:27:51 +0000
- Subject: [Bug math/15384] One constant fewer in ieee754/dbl-64/wordsize-64/s_finite.c
- Auto-submitted: auto-generated
- References: <bug-15384-131 at http dot sourceware dot org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=15384
--- Comment #7 from OndrejBilka <ondra at iuuk dot mff.cuni.cz> 2013-04-21 17:27:51 UTC ---
Created attachment 6995
--> http://sourceware.org/bugzilla/attachment.cgi?id=6995
benchmark for inlines
I updated your benchmark. Use
for i in `seq 0 7`; do echo finite$i; gcc test.c -O3 -Wall -W
-fno-builtin-finite -Dfinite=finite$i; for j in `seq 1 8`; do /usr/bin/time -f
"%U" ./a.out; done; done
which works in bash.
> and your new code does not appear to beat the old one in speed (for size, the
> non-null version looks great). Interestingly, __builtin_finite wins this test,
> although you can feed it a denormal if you want to beat it.
This depends on platform and benchmark.
Performance of noninlined function does not make lot of sense because gcc
inlines them all. This was partly reason I optimize for size.
As I bet that 99% of use cases are something like
if (isfinite(x)) stuff() else error();
I added benchmark for testing a branch. Then my modified versions seem to win.
on nehalem
Last implementation correctly computed 1 for infinite values and 0 otherwise.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.