# Operation yields different results on other machine

**URL:** <https://discourse.julialang.org/t/operation-yields-different-results-on-other-machine/59442>\
**Category:** General Usage\
**Created:** [April 16, 2021, 9:31pm UTC](https://discourse.julialang.org/t/operation-yields-different-results-on-other-machine/59442 "2021-04-16T21:31:04Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![cstjean](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cstjean/32/1444_2.png) [@cstjean](https://discourse.julialang.org/u/cstjean)\
**Post date:** [April 16, 2021, 9:31pm UTC](https://discourse.julialang.org/t/operation-yields-different-results-on-other-machine/59442/1 "2021-04-16T21:31:04Z")

</div>

We’re running the same code on machine A and machine B (same Manifest file), and the results are not the same. We’re doing fairly straight-forward linear algebra on StaticArrays. Is that a bug, or is it generally accepted that the implementation of these algorithms (LAPACK etc.) can vary from one machine to the next?

---

<div class="post-metadata">

**Author:** ![jzr](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@jzr](https://discourse.julialang.org/u/jzr)\
**Post date:** [April 16, 2021, 11:26pm UTC](https://discourse.julialang.org/t/operation-yields-different-results-on-other-machine/59442/2 "2021-04-16T23:26:40Z")

</div>

What kind of machines are they?

- OS
- CPU architecture
- Julia version
- …

---

<div class="post-metadata">

**Author:** ![cstjean](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cstjean/32/1444_2.png) [@cstjean](https://discourse.julialang.org/u/cstjean)\
**Post date:** [April 17, 2021, 1:22am UTC](https://discourse.julialang.org/t/operation-yields-different-results-on-other-machine/59442/3 "2021-04-17T01:22:33Z")

</div>

I’m not sure; I’m asking more from a point of principle, to figure out if I want to spend time looking for the difference. Is julia generally guaranteeing that `f(x)` will return exactly the same value across architecture/OS, for its floating point operations? Is there any function in Base where that’s not true? There is the `Int = Int32/Int64` split which can cause a difference, and obviously multithreading can vary if we didn’t write our code right, but for single-thread code is there anything else?

EDIT: to be clear, I’m talking about a 1e-8 difference in the final result of a calculation. It is probably a very small floating point difference, that was compounded over the large number of operations we perform.

---

<div class="post-metadata">

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\
**Post date:** [April 17, 2021, 4:31am UTC](https://discourse.julialang.org/t/operation-yields-different-results-on-other-machine/59442/4 "2021-04-17T04:31:48Z")

</div>

It won’t generally be true if you have `@simd` or `@fastmath`.  
Optimal performance for some operations (e.g. reductions) will require different orderings on different machines, and this can change rounding.

For example, on a machine with AVX512, starting Julia normally (this will use 256 bit vectors, as preferring them is the default):

```julia
julia> using Random; Random.seed!(2);

julia> sum(rand(128))
59.893130742026266

```

Starting Julia with `-C"native,-prefer-256-bit"` (this means “do not prefer 256 bit vectors”, which will cause it to use 512 bit vectors):

```julia
julia> using Random; Random.seed!(2);

julia> sum(rand(128))
59.89313074202627

```

Starting with `-C"native,prefer-128-bit"` (do prefer 128 bit vectors):

```julia
julia> using Random; Random.seed!(2);

julia> sum(rand(128))
59.89313074202625

```

Aside from vector width, the presence/absence of fused multiply add instructions will also make a difference. These instructions return the correctly rounded answer (i.e., not rounding the intermediate product and then rounding again after adding).  
`muladd(a,b,c)` will normally (but not always) use fma instructions when available, and when unavailable will instead compute the less accurate `a * b + c`.  
`Base.exp` is much less accurate on systems without FMA instructions. As an aside, VectorizationBase/LoopVectorization’s should be similarly accurate whether or not FMA is available, as it switches to double-double arithmetic in that case to compensate; this means that in practice FMA instructions can sometimes provide a far larger performance than just the 2x implied by just combining an addition and subtraction. This would be even more extreme if using `Base.fma` instead of double-double arithmetic, as `Base.fma` imposes an even larger performance penalty.