Re: Strange performance behaviour
- From: Mike Pall <mike-1208@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Sun, 26 Aug 2012 00:51:08 +0200
David Given wrote:
> Just for your information (not that I think it's happening here): glibc
> contains some *excruciatingly* pathalogical code paths.
I just eliminated a big on: strtod(). Yay!
Dragging in half of GMP is not just an I-cache killer, but that
abomination of code has known,unfixed bugs since six (!) years:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=3479
The last straw that made me write my own replacement was that
[E]GLIBC 2.16 parses "0x3p1023" into NaN and not Inf (WTF?!?).
Of course, MSVCRT has even more bugs and shortcomings (no hex
floats), but nobody's terribly surprised about that, I guess.
Anyway, it's in git HEAD, it's only 3 KB of machine code and it
returns precise results for all inputs on *all* platforms. The
annoying issue with locales where the decimal separator is not
a dot is gone, too. Hooray!
[I can post the test cases, if anyone is interested. Almost all
strtod() implementations are buggy, as I found out.]
> For example, here's a guy discovering that the same number of iterations
> of a simple benchmark with pow() can, if you change the exponent
> slightly, vary from 10 seconds to 21 *hours*.
I have some more war stories, e.g. trying to optimize x=x+(2/3)^k
into t=t*(2/3); x=x+t (strength reduction of pow to mul) and
getting abysmal performance due to denormals. This doesn't happen
for pow, since it uses log/exp instead of a binary accumulating
loop for higher k. Yes, floating-point arithmetic is fun ...
--Mike
Other related posts:
