3 ms·

Interesting, but a bit weird that the benchmark doesn't include the standard math functions - the question most potential users would ask is, how much performan

Interesting, but a bit weird that the benchmark doesn't include the standard math functions - the question most potential users would ask is, how much performance could I gain from this? Personally I do a lot of approximations of math functions, which usually give me about a 10x speed increase relative to <math.h>. From the looks of it, this isn't quite that fast.

someguydave 7y ago
This is more for people who need to do specialized DSP math like DFTs using a variety of different cpu arches. Most vendor libraries (like Intel IPP) for vector units fail to support their competitors. So benchmarks might be relatively less important than portability.
kcbanner 7y ago
This library can leverage data parallelism to increase throughout vs the scalar versions. ie. One instruction performs 4 operations instead of one. If the problem you are solving is suited to this parallelism, you could get a significant speedup.
- svantana 7y ago
  Sure, so why is that speedup not measured in the benchmark?
celrod 7y ago
Recent versions of GCC as well as the Intel compilers can autovectorize with the right flags (-ffast-math with GCC, -fast with Intel), and yield better performance with the <math.h> functions than you'll get from SLEEF on x86_64. LLVM doesn't have a vector math library, so SLEEF could help you there. If you're using single precision and AVX512, a >10x speed increase is likely. Otherwise, you'll probably get less than that. These functions are very accurate, most to withing 1 ULP of least precision. That is, if the answer they provide isn't the correctly rounded floating point answer, then it'll be either the next or previous representable floating point number. There is a lot of room for giving up accuracy in the name of speed (eg, using less terms in the polynomials).
- svantana 7y ago
  Do you have a benchmark showing that gcc is faster than sleef? Sorry I wasn't clear, by "10x" I meant 10x faster than the standard library with the fastest compiler options (-O3 -ffast-math -avx512), but I've only tested with clang.

someguydave 7y ago

This is more for people who need to do specialized DSP math like DFTs using a variety of different cpu arches. Most vendor libraries (like Intel IPP) for vector units fail to support their competitors. So benchmarks might be relatively less important than portability.

kcbanner 7y ago

This library can leverage data parallelism to increase throughout vs the scalar versions. ie. One instruction performs 4 operations instead of one. If the problem you are solving is suited to this parallelism, you could get a significant speedup.

svantana 7y ago
Sure, so why is that speedup not measured in the benchmark?

celrod 7y ago

Recent versions of GCC as well as the Intel compilers can autovectorize with the right flags (-ffast-math with GCC, -fast with Intel), and yield better performance with the <math.h> functions than you'll get from SLEEF on x86_64. LLVM doesn't have a vector math library, so SLEEF could help you there. If you're using single precision and AVX512, a >10x speed increase is likely. Otherwise, you'll probably get less than that. These functions are very accurate, most to withing 1 ULP of least precision. That is, if the answer they provide isn't the correctly rounded floating point answer, then it'll be either the next or previous representable floating point number. There is a lot of room for giving up accuracy in the name of speed (eg, using less terms in the polynomials).

svantana 7y ago
Do you have a benchmark showing that gcc is faster than sleef? Sorry I wasn't clear, by "10x" I meant 10x faster than the standard library with the fastest compiler options (-O3 -ffast-math -avx512), but I've only tested with clang.