3 ms·

If you use the LLVM D compiler you can opt in or out of these individually on a per-function basis. I don't trust them globally.

by mhh__ 5y ago

p0nce 5y ago
+1 Every time I tried --fast-math made things a bit slower. It's not that valuable with LLVM.
gpderetta 5y ago
with gcc you can also use #pragma gcc optimize or __attribute__(optimize(...)) for a similar effect. It is not 100% bug free (at least it didn't use to) and often it prevents inlining a function into another having different optimization levels (so in practice its use has to be coarse grained).
- nly 5y ago
  This pragma doesn't quite work for -ffast-math https://gcc.godbolt.org/z/voMK7x7hG https://gcc.godbolt.org/z/voMK7x7hG Try it with and without the pragma, and adding -ffast-math to the compiler command line. It seems that with the pragma sqrt(x) * sqrt(x) becomes sqrt(x*x), but with the command line version it is simplified to just x.
  - gpderetta 5y ago
    That's very interesting. The pragma does indeed do a lot of optimizations compared to no-pragma (for example it doesn't call sqrtf at all), but the last simplification is only done with the global flag set. I wonder if it is a missed optimization or if there is a reason for that. edit: well with pragma fast-math it appears it is simply assuming finite math and x>0 thus skipping the call to the sqrtf as there are not going to be any errors, basically only saving a jmp. Using pragma finite-math-only and an explicit check are enough to trigger the optimization (but passing finite-math as a command line is not). Generally it seems that the various math flags behave slightly differently in the pragma/attribute.
stabbles 5y ago
In Julia you can do `@fastmath ...`, which is basically just a find-and-replace of math operations and does not propagate into functions called in that code block, even when they are ultimately inlined. So what it does is: julia> @macroexpand @fastmath x + y :(Base.FastMath.add_fast(x, y)) And maybe that's a good thing, because the scope of @fastmath is as limited as it gets.
- celrod 5y ago
  Yeah, I really like that Julia and LLVM allow applying it on a per-operation basis. Because most of LLVM's backends don't allow for the same level of granularity, they do end up propagating some information more than I would like. For example, marking an operation as fast lets LLVM assume that it does not result in NaNs, letting nan checks get compiled away even though they themselves are not marked fast: julia> add_isnan(a,b) = isnan(@fastmath(a+b)) add_isnan (generic function with 1 method) julia> @code_llvm debuginfo=:none add_isnan(1.2,2.3) define i8 @julia_add_isnan_597(double %0, double %1) #0 { top: ret i8 0 } meaning it remains more dangerous to use than it IMO should be. For this reason, LoopVectorization.jl does not apply "nonans".

If you use the LLVM D compiler you can opt in or out of these individually on a per-function basis. I don't trust them globally.

by mhh__ 5y ago

If you use the LLVM D compiler you can opt in or out of these individually on a per-function basis. I don't trust them globally.

p0nce 5y ago

+1 Every time I tried --fast-math made things a bit slower. It's not that valuable with LLVM.

gpderetta 5y ago

with gcc you can also use #pragma gcc optimize or __attribute__(optimize(...)) for a similar effect. It is not 100% bug free (at least it didn't use to) and often it prevents inlining a function into another having different optimization levels (so in practice its use has to be coarse grained).

nly 5y ago
This pragma doesn't quite work for -ffast-math https://gcc.godbolt.org/z/voMK7x7hG https://gcc.godbolt.org/z/voMK7x7hG Try it with and without the pragma, and adding -ffast-math to the compiler command line. It seems that with the pragma sqrt(x) * sqrt(x) becomes sqrt(x*x), but with the command line version it is simplified to just x.
- gpderetta 5y ago
  That's very interesting. The pragma does indeed do a lot of optimizations compared to no-pragma (for example it doesn't call sqrtf at all), but the last simplification is only done with the global flag set. I wonder if it is a missed optimization or if there is a reason for that. edit: well with pragma fast-math it appears it is simply assuming finite math and x>0 thus skipping the call to the sqrtf as there are not going to be any errors, basically only saving a jmp. Using pragma finite-math-only and an explicit check are enough to trigger the optimization (but passing finite-math as a command line is not). Generally it seems that the various math flags behave slightly differently in the pragma/attribute.

stabbles 5y ago

In Julia you can do `@fastmath ...`, which is basically just a find-and-replace of math operations and does not propagate into functions called in that code block, even when they are ultimately inlined. So what it does is: julia> @macroexpand @fastmath x + y :(Base.FastMath.add_fast(x, y)) And maybe that's a good thing, because the scope of @fastmath is as limited as it gets.

celrod 5y ago
Yeah, I really like that Julia and LLVM allow applying it on a per-operation basis. Because most of LLVM's backends don't allow for the same level of granularity, they do end up propagating some information more than I would like. For example, marking an operation as fast lets LLVM assume that it does not result in NaNs, letting nan checks get compiled away even though they themselves are not marked fast: julia> add_isnan(a,b) = isnan(@fastmath(a+b)) add_isnan (generic function with 1 method) julia> @code_llvm debuginfo=:none add_isnan(1.2,2.3) define i8 @julia_add_isnan_597(double %0, double %1) #0 { top: ret i8 0 } meaning it remains more dangerous to use than it IMO should be. For this reason, LoopVectorization.jl does not apply "nonans".