# Help with optimising a simple function

**URL:** <https://discourse.julialang.org/t/help-with-optimising-a-simple-function/131459>\
**Category:** Performance\
**Created:** [August 7, 2025, 5:06pm UTC](https://discourse.julialang.org/t/help-with-optimising-a-simple-function/131459 "2025-08-07T17:06:57Z")\
**Posts on this page:** 2\
**Page:** 2

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [August 8, 2025, 6:51pm UTC](https://discourse.julialang.org/t/help-with-optimising-a-simple-function/131459/21 "2025-08-08T18:51:52Z")

</div>

> [@Tbl](#):
>
> Maybe compiler has problems with inlining functions which depend on external parameters?
> 
> Anyway, it is somewhat disappointing that Julia compiler cannot deal with such stuff itself…But, it’s not like numba is better with this.

Broadly speaking, compilers do reorganize and remove redundancies (LLVM would do most of it for both Julia and Numba), but they avoid doing it if it would noticeably change results. For a simpler term-cancelling example:

```julia-auto
julia> f(a::Number, b::Number) = a + b - a
f (generic function with 1 method)

```

Elementary arithmetic over common number sets taught us `a+b-a` cancels to `b` unconditionally. So what actually happens in Julia, or rather the LLVM optimizations?

```julia-auto
julia> @code_llvm f(1, 2)
; Function Signature: f(Int64, Int64)
; @ REPL[38]:1 within `f`
; Function Attrs: uwtable
define i64 @julia_f_9606(i64 signext %"a::Int64", i64 signext %"b::Int64") #0 {
top:
; ┌ @ int.jl:86 within `-`
   ret i64 %"b::Int64"
; └
}

```

Clear evidence of automatic cancelling. Let’s try another primitive type:

```julia-auto
julia> @code_llvm f(1.0, 2.0)
; Function Signature: f(Float64, Float64)
; @ REPL[70]:1 within `f`
; Function Attrs: uwtable
define double @julia_f_9688(double %"a::Float64", double %"b::Float64") #0 {
top:
; ┌ @ float.jl:491 within `+`
   %0 = fadd double %"a::Float64", %"b::Float64"
; └
; ┌ @ float.jl:492 within `-`
   %1 = fsub double %0, %"a::Float64"
   ret double %1
; └
}

```

No cancelling there. Floating point operations are not generally associative due to precision limits, so simplifying the expression would actually change results. Even when the change is better for us, the compiler is too objective to know that:

```julia-auto
julia> 1e16 + 1.0 - 1e16 # uh oh, floating point precision is too low for +1.0
0.0

```

So generally, the compiler alone cannot optimize arbitrary algorithms to the extreme because only we can decide whether some optimizations are acceptable, even if it’s as simple as cancelling terms.

---

<div class="post-metadata">

**Author:** ![Tbl](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tbl/32/5984_2.png) [@Tbl](https://discourse.julialang.org/u/Tbl)\
**Post date:** [August 8, 2025, 6:56pm UTC](https://discourse.julialang.org/t/help-with-optimising-a-simple-function/131459/22 "2025-08-08T18:56:18Z")

</div>

Yes I did. Much faster than the initial attempt, still twice slower than numba.

[Previous page](https://discourse.julialang.org/t/help-with-optimising-a-simple-function/131459.md?page=1)