5 ms·

Aren't these implemented in hardware on most CPU's? Or is this floating point emulation for CPU's that don't have built-in floating point?

by csense 12y ago

CurtHagenlocher 12y ago
I believe on x86/x64 CPUs there's an advantage to doing these operations via SSE rather than using the old x87 opcodes. For instance, you don't need to move data into the x87 registers.
- Narishma 12y ago
  Right, you have to move it instead into the SSE registers.
  - FeepingCreature 12y ago
    Where it should be living anyways.
gsg 12y ago
The hardware implementations often have problems: http://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/ http://randomascii.wordpress.com/2014/10/09/intel-underestim...
derf_ 12y ago
There's an x87 asm implementation for x86-32 in sysdeps/i386/fpu/e_exp.S [1]. For x86-64, it falls back to the generic C code for exp(), in sysdeps/ieee754/dbl-64/e_exp.c. The sad part is that there is x86-64 asm for a few variants (exp10l, exp2l, expf, expl), but since these are not C90, people tend to avoid them for more portable versions. So, ironically, it can be orders of magnitude faster to compute a long-double expl() than a double-precision exp(). [1] Even the asm contains a lot of extra code to handle edge cases that Intel screwed up, like returning NaN for exp(+/- Inf).
- pascal_cuoq 12y ago
  The 387 instructions for elementary functions do not have the reputation of having a good accuracy/time ratio compared to, say, state-of-the-art implementations using polynomial approximations. Do you have actual measurements that reveal some actual irony, or is it only superficial irony in that expl() is computed using the (microcoded, slow) hardware instruction and exp() isn't? Note: For most functions, you can actually make a pretty accurate double-precision implementation by calling the corresponding 387 instruction and then rounding the result to double-precision. Not a correctly rounded implementation (that would require a wider intermediate result than 80-bit) but pretty good nonetheless.
  - derf_ 12y ago
    We didn't measure average case performance, but for worst-case performance the "orders of magnitude" comment is absolutely backed by measurement. See also my comment at https://news.ycombinator.com/item?id=8830667 https://news.ycombinator.com/item?id=8830667 In our case, we only needed about 12 bits of accuracy anyway, so we wound up writing our own implementation using polynomial approximations (which have the benefit of predictable running times regardless of the quality of your C library). The fact that you need to do this in any context where worst-case performance is a concern might be surprising to some people. It was to me before I read glibc's code.
    - derf_ 12y ago
      I take it back, we did measure average case performance of expf() (though not expl()), and it was slower than exp(): 16:12:48 < gmaxwell> ha. So, completely eliminating all the doubles made celt slower. 16:13:23 < gmaxwell> I'm guessing that this is because I used the C99 float versions of the math functions and they suck. 16:13:57 < gmaxwell> looks like 3% slower or so. 16:14:05 < gmaxwell> <3 GLIBC. 16:26:02 < gmaxwell> with float approx the no-doubles is .9% faster. Whoohoo. ;) 17:24:06 < derf> Yes. Don't use the float versions of libc functions, at least not on x86-64. 17:24:24 < Dark_Shikari> what the heck did they do ? 17:24:53 < derf> They reset the rounding modes on entrance and exit of expf(), for example, regardless of whether or not they're already correctly set up. 17:25:07 < derf> Apparently this is really slow. 17:25:32 < gmaxwell> derf: I was hoping that they'd be fixed by now. "Float approx" refers to our custom polynomial approximation of exp(). Given that, I think it's safe to infer that expl() would also have been slower than exp() in the average case. That was in 2010, though. This appears to have been fixed for expf() in 2012 (which now uses SSE/AVX instead of x87 asm on x86-64), but not for expl().

Aren't these implemented in hardware on most CPU's? Or is this floating point emulation for CPU's that don't have built-in floating point?

by csense 12y ago

Aren't these implemented in hardware on most CPU's? Or is this floating point emulation for CPU's that don't have built-in floating point?

CurtHagenlocher 12y ago

I believe on x86/x64 CPUs there's an advantage to doing these operations via SSE rather than using the old x87 opcodes. For instance, you don't need to move data into the x87 registers.

Narishma 12y ago
Right, you have to move it instead into the SSE registers.
- FeepingCreature 12y ago
  Where it should be living anyways.

gsg 12y ago

The hardware implementations often have problems: http://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/ http://randomascii.wordpress.com/2014/10/09/intel-underestim...

derf_ 12y ago

There's an x87 asm implementation for x86-32 in sysdeps/i386/fpu/e_exp.S [1]. For x86-64, it falls back to the generic C code for exp(), in sysdeps/ieee754/dbl-64/e_exp.c. The sad part is that there is x86-64 asm for a few variants (exp10l, exp2l, expf, expl), but since these are not C90, people tend to avoid them for more portable versions. So, ironically, it can be orders of magnitude faster to compute a long-double expl() than a double-precision exp(). [1] Even the asm contains a lot of extra code to handle edge cases that Intel screwed up, like returning NaN for exp(+/- Inf).

pascal_cuoq 12y ago
The 387 instructions for elementary functions do not have the reputation of having a good accuracy/time ratio compared to, say, state-of-the-art implementations using polynomial approximations. Do you have actual measurements that reveal some actual irony, or is it only superficial irony in that expl() is computed using the (microcoded, slow) hardware instruction and exp() isn't? Note: For most functions, you can actually make a pretty accurate double-precision implementation by calling the corresponding 387 instruction and then rounding the result to double-precision. Not a correctly rounded implementation (that would require a wider intermediate result than 80-bit) but pretty good nonetheless.
- derf_ 12y ago
  We didn't measure average case performance, but for worst-case performance the "orders of magnitude" comment is absolutely backed by measurement. See also my comment at https://news.ycombinator.com/item?id=8830667 https://news.ycombinator.com/item?id=8830667 In our case, we only needed about 12 bits of accuracy anyway, so we wound up writing our own implementation using polynomial approximations (which have the benefit of predictable running times regardless of the quality of your C library). The fact that you need to do this in any context where worst-case performance is a concern might be surprising to some people. It was to me before I read glibc's code.
  - derf_ 12y ago
    I take it back, we did measure average case performance of expf() (though not expl()), and it was slower than exp(): 16:12:48 < gmaxwell> ha. So, completely eliminating all the doubles made celt slower. 16:13:23 < gmaxwell> I'm guessing that this is because I used the C99 float versions of the math functions and they suck. 16:13:57 < gmaxwell> looks like 3% slower or so. 16:14:05 < gmaxwell> <3 GLIBC. 16:26:02 < gmaxwell> with float approx the no-doubles is .9% faster. Whoohoo. ;) 17:24:06 < derf> Yes. Don't use the float versions of libc functions, at least not on x86-64. 17:24:24 < Dark_Shikari> what the heck did they do ? 17:24:53 < derf> They reset the rounding modes on entrance and exit of expf(), for example, regardless of whether or not they're already correctly set up. 17:25:07 < derf> Apparently this is really slow. 17:25:32 < gmaxwell> derf: I was hoping that they'd be fixed by now. "Float approx" refers to our custom polynomial approximation of exp(). Given that, I think it's safe to infer that expl() would also have been slower than exp() in the average case. That was in 2010, though. This appears to have been fixed for expf() in 2012 (which now uses SSE/AVX instead of x87 asm on x86-64), but not for expl().