# Performance of findmax vs. raw loop

**URL:** <https://discourse.julialang.org/t/performance-of-findmax-vs-raw-loop/43305>\
**Category:** General Usage\
**Created:** [July 18, 2020, 7:19pm UTC](https://discourse.julialang.org/t/performance-of-findmax-vs-raw-loop/43305 "2020-07-18T19:19:03Z")\
**Posts on this page:** 1\
**Showing post:** 12

<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:** [July 19, 2020, 12:57am UTC](https://discourse.julialang.org/t/performance-of-findmax-vs-raw-loop/43305/12 "2020-07-19T00:57:58Z")

</div>

Note that starting Julia with `--math-mode=fast` is playing with fire:

```julia
> julia -O3 --math-mode=ieee -E "sinpi(0.15)"
0.45399049973954675
> julia -O3 --math-mode=fast -E "sinpi(0.15)"
0.0

```

From the definition of `f6`:

```julia
  for i in eachindex(p)
    v = abs(det([p[i] d0]) + det0)

    if v > vmax
      vmax = abs(det([p[i] d0]) + det0)
      imax = i
    end
  end

```

You didn’t actually reduce how often you’re calling `det`.

> [@pauljurczak](#):
>
> Good point, but somehow the compiler didn’t take this possibility into account in my example. Is there an option to state that explicitly, e.g. from now on this container is read only?

If you want to use `LLVM.jl`, you can. But it helps in situations like when you’re writing to one array and loading from another, it can tell the compiler that the write isn’t changing the load. That could allow it to reorder these reads and writes, and (for example) take advantage SIMD.

I would be very surprised if it helps in your example, however.  
The array allocations are not inlined:

```julia
julia> @code_native debuginfo=:none syntax=:intel Array{Float64}(undef, 3)
        .text
        push rax
        movabs rdi, offset jl_system_image_data
        movabs rax, offset jl_alloc_array_1d
        call rax
        pop rcx
        ret
        nop dword ptr [rax]

julia> @code_native debuginfo=:none syntax=:intel Array{Float64}(undef, 3, 4)
        .text
        push rax
        movabs rdi, offset jl_system_image_data
        movabs rax, offset jl_alloc_array_2d
        call rax
        pop rcx
        ret
        nop dword ptr [rax]

julia> @code_native debuginfo=:none syntax=:intel Array{Float64}(undef, 3, 4, 5)
        .text
        push rax
        movabs rdi, 139781825231120
        movabs rax, offset jl_alloc_array_3d
        call rax
        pop rcx
        ret
        nop dword ptr [rax]

```

So what is actually going on is opaque to the compiler.

This may change some day. [Keno said](https://discourse.julialang.org/t/why-is-julias-generated-assembly-more-complicated-than-swifts-for-a-simple-function/35549/13):

> [@Why is Julia's generated assembly more complicated than Swift's for a simple function?](https://discourse.julialang.org/t/why-is-julias-generated-assembly-more-complicated-than-swifts-for-a-simple-function/35549/13):
>
> Adding constant prop for arrays like this would be quite easy, but would have significant compile time cost, so we don’t do that. If you want to manually opt into that kind of thing you can use StaticArrays (or tuples as was previously mentioned). We are planning a bit of an Array overhaul for 2.0, at which point Array may be closer to StaticArrays and this kind of optimization may happen, but for now, `Array` is just the wrong data structure for what you’re looking for here.

---

_[View the full topic](https://discourse.julialang.org/t/performance-of-findmax-vs-raw-loop/43305)._