# Fast math in NASA benchmark
**URL:** https://discourse.julialang.org/t/fast-math-in-nasa-benchmark/43580
**Category:** General Usage
**Created:** [July 23, 2020, 7:28pm UTC](https://discourse.julialang.org/t/fast-math-in-nasa-benchmark/43580 "2020-07-23T19:28:45Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)
#### Post date: [July 23, 2020, 7:28pm UTC](https://discourse.julialang.org/t/fast-math-in-nasa-benchmark/43580/1 "2020-07-23T19:28:45Z")
I noticed in this [benchmark](https://discourse.julialang.org/t/interesting-nasa-language-comparison-repository/31356/29) that the `--fast-math` GCC option was far more effective in reducing the runtime then the `--math-mode=fast` Julia option. What do you think is the reason for that?
---
### Author:  [@simonbyrne](https://discourse.julialang.org/u/simonbyrne)
#### Post date: [July 23, 2020, 7:41pm UTC](https://discourse.julialang.org/t/fast-math-in-nasa-benchmark/43580/2 "2020-07-23T19:41:21Z")
I think it comes down to being fundamentally bad idea, hence:
[https://github.com/JuliaLang/julia/issues/36246](https://github.com/JuliaLang/julia/issues/36246)
---
### Author:  [@simonbyrne](https://discourse.julialang.org/u/simonbyrne)
#### Post date: [July 23, 2020, 7:48pm UTC](https://discourse.julialang.org/t/fast-math-in-nasa-benchmark/43580/3 "2020-07-23T19:48:06Z")
But to give you a better answer: the biggest speed-up in gcc is in the matrix multiplication benchmark: using -Ofast here would let them reassociate arithmetic operations (to exploit SIMD instructions), and use FMA instructions if they’re available. Julia’s `@simd` macro and `muladd` functions will do something similar, without the blatant unsafe-ness of fastmath.
---
### Author:  [@evanfields](https://discourse.julialang.org/u/evanfields)
#### Post date: [July 23, 2020, 8:41pm UTC](https://discourse.julialang.org/t/fast-math-in-nasa-benchmark/43580/4 "2020-07-23T20:41:27Z")
Is there a “reader’s digest” version of why `@fastmath` is bad?
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [July 23, 2020, 8:45pm UTC](https://discourse.julialang.org/t/fast-math-in-nasa-benchmark/43580/5 "2020-07-23T20:45:04Z")
It’s an under-specified grab-bag of math-breaking the compiler can do _everywhere_. Some algorithms actually depend upon math working correctly.
---
### Author:  [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [July 23, 2020, 8:47pm UTC](https://discourse.julialang.org/t/fast-math-in-nasa-benchmark/43580/6 "2020-07-23T20:47:45Z")
One specific problem with it is that it’s recursive. While at first this feels like a good thing (I want all my code fast), the problem is it can end up applying to stuff in `Base` or other libraries where it is specifically broken.
---
### Author:  [@tbeason](https://discourse.julialang.org/u/tbeason)
#### Post date: [July 23, 2020, 8:48pm UTC](https://discourse.julialang.org/t/fast-math-in-nasa-benchmark/43580/7 "2020-07-23T20:48:02Z")
Relevant issue [https://github.com/JuliaLang/julia/issues/36246](https://github.com/JuliaLang/julia/issues/36246) [oops… this was already linked]
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [July 23, 2020, 8:55pm UTC](https://discourse.julialang.org/t/fast-math-in-nasa-benchmark/43580/8 "2020-07-23T20:55:55Z")
There was once a very long (non-readers-digest) discussion about this, but this post is fairly self-contained:
> [@Accurate summation algorithm](https://discourse.julialang.org/t/accurate-summation-algorithm/7163/9):
>
> A point I’ve made several times previously is the following: Mathematically, since + is associative and commutative, all correct summation algorithms are algebraically equivalent to each other, in particular they are all equivalent to left-to-right summation. The -ffast-math option gives the compiler license to transform any algorithm into any algebraically equivalent one in the mathematical sense. Therefore -ffast-math gives the compiler license to transform any summation algorithm int…
Especially if you combine it with the fact that you can pick a collection of 2046 numbers that can sum to just about _any_ number depending upon their ordering:
> [@Array ordering and naive summation](https://discourse.julialang.org/t/array-ordering-and-naive-summation/1929):
>
> One of the first things you learn in numerical analysis is that floating-point operations are not associative. A classic example is this: julia\> (0.1 + 0.2) + 0.3 0.6000000000000001 julia\> 0.1 + (0.2 + 0.3) 0.6 I was thinking of ways to make floating-point summation independent of the order of the summands without making the performance much worse (this is a hobby of mine). Julia currently uses a pairwise summation algorithm, which is much better than naive left-to-right reduction while havin…
Base’s code actually depends upon smartly re-ordering summations to improve precision that fast math might break.
---
### Author:  [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)
#### Post date: [July 23, 2020, 9:16pm UTC](https://discourse.julialang.org/t/fast-math-in-nasa-benchmark/43580/9 "2020-07-23T21:16:53Z")
I filed an issue to alert developers responsible for the NASA software comparison benchmark suite to the inappropriateness of including fast math in the results.
[https://github.com/JulesKouatchou/basic\_language\_comparison/issues/9](https://github.com/JulesKouatchou/basic_language_comparison/issues/9)
When fast math option is not used, in the Jacobi iteration benchmark
Julia is faster than the C-language implementation. 6.96 s versus 7.51 s.
Tested with WSL 2, Julia 1.6, generic Linux.