At the center of any fast parallel code is a fast serial code. Parallelism is made to be a performance multiplier, so if you start from a bad position it won't ever get much better. Thus the first thing that we need to do is understand what makes code slow and how to avoid the pitfalls. This discussion of serial code optimization will also directly motivate why we will be using Julia throughout this course.

To start optimizing code you need a good mental model of a computer.

At the highest level you have a CPU's core memory which directly accesses a L1 cache. The L1 cache has the fastest access, so things which will be needed soon are kept there. However, it is filled from the L2 cache, which itself is filled from the L3 cache, which is filled from the main memory. This bring us to the first idea in optimizing code: using things that are already in a closer cache can help the code run faster because it doesn't have to be queried for and moved up this chain.

When something needs to be pulled directly from main memory this is known as a *cache miss*. To understand the cost of a cache miss vs standard calculations, take a look at this classic chart.

(Cache-aware and cache-oblivious algorithms are methods which change their indexing structure to optimize their use of the cache lines. We will return to this when talking about performance of linear algebra.)

Many algorithms in numerical linear algebra are designed to minimize cache misses. Because of this chain, many modern CPUs try to guess what you will want next in your cache. When dealing with arrays, it will speculate ahead and grab what is known as a *cache line*: the next chunk in the array. Thus, your algorithms will be faster if you iterate along the values that it is grabbing.

The values that it grabs are the next values in the contiguous order of the stored array. There are two common conventions: row major and column major. Row major means that the linear array of memory is formed by stacking the rows one after another, while column major puts the column vectors one after another.

*Julia, MATLAB, and Fortran are column major*. Python's numpy is row-major.

A = rand(100,100) B = rand(100,100) C = rand(100,100) using BenchmarkTools function inner_rows!(C,A,B) for i in 1:100, j in 1:100 C[i,j] = A[i,j] + B[i,j] end end @btime inner_rows!(C,A,B)

10.599 μs (0 allocations: 0 bytes)

function inner_cols!(C,A,B) for j in 1:100, i in 1:100 C[i,j] = A[i,j] + B[i,j] end end @btime inner_cols!(C,A,B)

6.540 μs (0 allocations: 0 bytes)

Locally, the stack is composed of a *stack* and a *heap*. The stack requires a static allocation: it is ordered. Because it's ordered, it is very clear where things are in the stack, and therefore accesses are very quick (think instantanious). However, because this is static, it requires that the size of the variables is known at compile time (to determine all of the variable locations). Since that is not possible with all variables, there exists the heap. The heap is essentially a stack of pointers to objects in memory. When heap variables are needed, their values are pulled up the cache chain and accessed.

Heap allocations are costly because they involve this pointer indirection, so stack allocation should be done when sensible (it's not helpful for really large arrays, but for small values like scalars it's essential!)

function inner_alloc!(C,A,B) for j in 1:100, i in 1:100 val = [A[i,j] + B[i,j]] C[i,j] = val[1] end end @btime inner_alloc!(C,A,B)

208.801 μs (10000 allocations: 937.50 KiB)

function inner_noalloc!(C,A,B) for j in 1:100, i in 1:100 val = A[i,j] + B[i,j] C[i,j] = val[1] end end @btime inner_noalloc!(C,A,B)

6.520 μs (0 allocations: 0 bytes)

Why does the array here get heap-allocated? It isn't able to prove/guerentee at compile-time that the array's size will always be a given value, and thus it allocates it to the heap. `@btime`

tells us this allocation occured and shows us the total heap memory that was taken. Meanwhile, the size of a Float64 number is known at compile-time (64-bits), and so this is stored onto the stack and given a specific location that the compiler will be able to directly address.

Note that one can use the StaticArrays.jl library to get statically-sized arrays and thus arrays which are stack-allocated:

using StaticArrays function static_inner_alloc!(C,A,B) for j in 1:100, i in 1:100 val = @SVector [A[i,j] + B[i,j]] C[i,j] = val[1] end end @btime static_inner_alloc!(C,A,B)

6.500 μs (0 allocations: 0 bytes)

Many times you do need to write into an array, so how can you write into an array without performing a heap allocation? The answer is mutation. Mutation is changing the values of an already existing array. In that case, no free memory has to be found to put the array (and no memory has to be freed by the garbage collector).

In Julia, functions which mutate the first value are conventionally noted by a `!`

. See the difference between these two equivalent functions:

function inner_noalloc!(C,A,B) for j in 1:100, i in 1:100 val = A[i,j] + B[i,j] C[i,j] = val[1] end end @btime inner_noalloc!(C,A,B)

6.540 μs (0 allocations: 0 bytes)

function inner_alloc(A,B) C = similar(A) for j in 1:100, i in 1:100 val = A[i,j] + B[i,j] C[i,j] = val[1] end end @btime inner_alloc(A,B)

10.700 μs (2 allocations: 78.20 KiB)

To use this algorithm effectively, the `!`

algorithm assumes that the caller already has allocated the output array to put as the output argument. If that is not true, then one would need to manually allocate. The goal of that interface is to give the caller control over the allocations to allow them to manually reduce the total number of heap allocations and thus increase the speed.

Wouldn't it be nice to not have to write the loop there? In many high level languages this is simply called *vectorization*. In Julia, we will call it *array vectorization* to distinguish it from the *SIMD vectorization* which is common in lower level languages like C, Fortran, and Julia.

In Julia, if you use `.`

on an operator it will transform it to the broadcasted form. Broadcast is *lazy*: it will build up an entire `.`

'd expression and then call `broadcast!`

on composed expression. This is customizable and documented in detail. However, to a first approximation we can think of the broadcast mechanism as a mechanism for building *fused expressions*. For example, the Julia code:

A .+ B .+ C;

under the hood lowers to something like:

map((a,b,c)->a+b+c,A,B,C);

where `map`

is a function that just loops over the values element-wise.

**Take a quick second to think about why loop fusion may be an optimization.**

This about what would happen if you did not fuse the operations. We can write that out as:

tmp = A .+ B tmp .+ C;

Notice that if we did not fuse the expressions, we would need some place to put the result of `A .+ B`

, and that would have to be an array, which means it would cause a heap allocation. Thus broadcast fusion eliminates the *temporary variable* (colloquially called just a *temporary*).

function unfused(A,B,C) tmp = A .+ B tmp .+ C end @btime unfused(A,B,C);

12.999 μs (4 allocations: 156.41 KiB)

fused(A,B,C) = A .+ B .+ C @btime fused(A,B,C);

5.875 μs (2 allocations: 78.20 KiB)

Note that we can also fuse the output by using `.=`

. This is essentially the vectorized version of a `!`

function:

D = similar(A) fused!(D,A,B,C) = (D .= A .+ B .+ C) @btime fused!(D,A,B,C);

3.775 μs (0 allocations: 0 bytes)

Julia allows for broadcasting the call `()`

operator as well. `.()`

will call the function element-wise on all arguments, so `sin.(A)`

will be the elementwise sine function. This will fuse Julia like the other operators.

In articles on MATLAB, Python, R, etc., this is where you will be told to vectorize your code. Notice from above that this isn't a performance difference between writing loops and using vectorized broadcasts. This is not abnormal! The reason why you are told to vectorize code in these other languages is because they have a high per-operation overhead (which will be discussed further down). This means that every call, like `+`

, is costly in these languages. To get around this issue and make the language usable, someone wrote and compiled the loop for the C/Fortran function that does the broadcasted form (see numpy's Github repo). Thus `A .+ B`

's MATLAB/Python/R equivalents are calling a single C function to generally avoid the cost of function calls and thus are faster.

But this is not an intrinsic property of vectorization. Vectorization isn't "fast" in these languages, it's just close to the correct speed. The reason vectorization is recommended is because looping is slow in these languages. Because looping isn't slow in Julia (or C, C++, Fortran, etc.), loops and vectorization generally have the same speed. So use the one that works best for your code without a care about performance.

(As a small side effect, these high level languages tend to allocate a lot of temporary variables since the individual C kernels are written for specific numbers of inputs and thus don't naturally fuse. Julia's broadcast mechanism is just generating and JIT compiling Julia functions on the fly, and thus it can accomodate the combinatorial explosion in the amount of choices just by only compiling the combinations that are necessary for a specific code)

It's important to note that slices in Julia produce copies instead of views. Thus for example:

A[50,50]

0.1671905216615932

allocates a new output. This is for safety, since if it pointed to the same array then writing to it would change the original array. We can demonstrate this by asking for a *view* instead of a copy.

@show A[1]

A[1] = 0.3898650195131119

E = @view A[1:5,1:5] E[1] = 2.0 @show A[1]

A[1] = 2.0 2.0

However, this means that `@view A[1:5,1:5]`

did not allocate an array (it does allocate a pointer if the escape analysis is unable to prove that it can be elided. This means that in small loops there will be no allocation, while if the view is returned from a function for example it will allocate the pointer, ~80 bytes, but not the memory of the array. This means that it is O(1) in cost but with a relatively small constant).

Heap allocations have to locate and prepare a space in RAM that is proportional to the amount of memory that is calcuated, which means that the cost of a heap allocation for an array is O(n), with a large constant. As RAM begins to fill up, this cost dramatically increases. If you run out of RAM, your computer may begin to use *swap*, which is essentially RAM simulated on your hard drive. Generally when you hit swap your performance is so dead that you may think that your computation froze, but if you check your resource use you will notice that it's actually just filled the RAM and starting to use the swap.

But think of it as O(n) with a large constant factor. This means that for operations which only touch the data once, heap allocations can dominate the computational cost:

using LinearAlgebra, BenchmarkTools function alloc_timer(n) A = rand(n,n) B = rand(n,n) C = rand(n,n) t1 = @belapsed $A .* $B t2 = @belapsed ($C .= $A .* $B) t1,t2 end ns = 2 .^ (2:11) res = [alloc_timer(n) for n in ns] alloc = [x[1] for x in res] noalloc = [x[2] for x in res] using Plots plot(ns,alloc,label="=",xscale=:log10,yscale=:log10,legend=:bottomright, title="Micro-optimizations matter for BLAS1") plot!(ns,noalloc,label=".=")

However, when the computation takes O(n^3), like in matrix multiplications, the high constant factor only comes into play when the matrices are sufficiently small:

using LinearAlgebra, BenchmarkTools function alloc_timer(n) A = rand(n,n) B = rand(n,n) C = rand(n,n) t1 = @belapsed $A*$B t2 = @belapsed mul!($C,$A,$B) t1,t2 end ns = 2 .^ (2:7) res = [alloc_timer(n) for n in ns] alloc = [x[1] for x in res] noalloc = [x[2] for x in res] using Plots plot(ns,alloc,label="*",xscale=:log10,yscale=:log10,legend=:bottomright, title="Micro-optimizations only matter for small matmuls") plot!(ns,noalloc,label="mul!")

Though using a mutating form is never bad and always is a little bit better.

Avoid cache misses by reusing values

Iterate along columns

Avoid heap allocations in inner loops

Heap allocations occur when the size of things is not proven at compile-time

Use fused broadcasts (with mutated outputs) to avoid heap allocations

Array vectorization confers no special benefit in Julia because Julia loops are as fast as C or Fortran

Use views instead of slices when applicable

Avoiding heap allocations is most necessary for O(n) algorithms or algorithms with small arrays

Use StaticArrays.jl to avoid heap allocations of small arrays in inner loops

Many people think Julia is fast because it is JIT compiled. That is simply not true (we've already shown examples where Julia code isn't fast, but it's always JIT compiled!). Instead, the reason why Julia is fast is because the combination of two ideas:

Type inference

Type specialization in functions

These two features naturally give rise to Julia's core design feature: multiple dispatch. Let's break down these pieces.

At the core level of the computer, everything has a type. Some languages are more explicit about said types, while others try to hide the types from the user. A type tells the compiler how to to store and interpret the memory of a value. For example, if the compiled code knows that the value in the register is supposed to be interpreted as a 64-bit floating point number, then it understands that slab of memory like:

Importantly, it will know what to do for function calls. If the code tells it to add two floating point numbers, it will send them as inputs to the Floating Point Unit (FPU) which will give the output.

If the types are not known, then... ? So one cannot actually compute until the types are known, since otherwise it's impossible to interpret the memory. In languages like C, the programmer has to declare the types of variables in the program:

```
void add(double *a, double *b, double *c, size_t n){
size_t i;
for(i = 0; i < n; ++i) {
c[i] = a[i] + b[i];
}
}
```

The types are known at compile time because the programmer set it in stone. In many interpreted languages Python, types are checked at runtime. For example,

```
a = 2
b = 4
a + b
```

when the addition occurs, the Python interpreter will check the object holding the values and ask it for its types, and use those types to know how to compute the + function. For this reason, the add function in Python is rather complex since it needs to decode and have a version for all primitive types!

Not only is there runtime overhead checks in function calls due to to not being explicit about types, there is also a memory overhead since it is impossible to know how much memory a value with take since that's a property of its type. Thus the Python interpreter cannot statically guerentee exact unchanging values for the size that a value would take in the stack, meaning that the variables are not stack-allocated. This means that every number ends up heap-allocated, which hopefully begins to explain why this is not as fast as C.

The solution is Julia is somewhat of a hybrid. The Julia code looks like:

a = 2 b = 4 a + b

6

However, before JIT compilation, Julia runs a type inference algorithm which finds out that `A`

is an `Int`

, and `B`

is an `Int`

. You can then understand that if it can prove that `A+B`

is an `Int`

, then it can propogate all of the types through.

Julia is able to propogate type inference through functions because, even if a function is "untyped", Julia will interpret this as a *generic function* over possible *methods*, where every method has a concrete type. This means that in Julia, the function:

f(x,y) = x+y

f (generic function with 1 method)

is not what you may think of as a "single function", since given inputs of different types it will actually be a different function. We can see this by examining the *LLVM IR* (LLVM is Julia's compiler, the IR is the *Intermediate Representation*, i.e. a platform-independent representation of assembly that lives in LLVM that it knows how to convert into assembly per architecture):

using InteractiveUtils @code_llvm f(2,5)

; @ none:1 within `f' ; Function Attrs: uwtable define i64 @julia_f_15393(i64, i64) #0 { top: ; ┌ @ int.jl:53 within `+' %2 = add i64 %1, %0 ; └ ret i64 %2 }

@code_llvm f(2.0,5.0)

; @ none:1 within `f' ; Function Attrs: uwtable define double @julia_f_15395(double, double) #0 { top: ; ┌ @ float.jl:395 within `+' %2 = fadd double %0, %1 ; └ ret double %2 }

Notice that when `f`

is the function that takes in two `Int`

s, `Int`

s add to give an `Int`

and thus `f`

outputs an `Int`

. When `f`

is the function that takes two `Float64`

s, `f`

returns a `Float64`

. Thus in the code:

function g(x,y) a = 4 b = 2 c = f(x,a) d = f(b,c) f(d,y) end @code_llvm g(2,5)

; @ none:2 within `g' ; Function Attrs: uwtable define i64 @julia_g_15396(i64, i64) #0 { top: ; @ none:5 within `g' ; ┌ @ none:1 within `f' ; │┌ @ int.jl:53 within `+' %2 = add i64 %0, 6 ; └└ ; @ none:6 within `g' ; ┌ @ none:1 within `f' ; │┌ @ int.jl:53 within `+' %3 = add i64 %2, %1 ; └└ ret i64 %3 }

`g`

on two `Int`

inputs is a function that has `Int`

s at every step along the way and spits out an `Int`

. We can use the `@code_warntype`

macro to better see the inference along the steps of the function:

@code_warntype g(2,5)

Body::Int64 1 ─ %1 = π (4, Core.Compiler.Const(4, false)) │ %2 = (Base.add_int)(x, %1)::Int64 │ %3 = π (2, Core.Compiler.Const(2, false)) │ %4 = (Base.add_int)(%3, %2)::Int64 │ %5 = (Base.add_int)(%4, y)::Int64 └── return %5

What happens on mixtures?

@code_llvm f(2.0,5)

; @ none:1 within `f' ; Function Attrs: uwtable define double @julia_f_15487(double, i64) #0 { top: ; ┌ @ promotion.jl:313 within `+' ; │┌ @ promotion.jl:284 within `promote' ; ││┌ @ promotion.jl:261 within `_promote' ; │││┌ @ number.jl:7 within `convert' ; ││││┌ @ float.jl:60 within `Type' %2 = sitofp i64 %1 to double ; │└└└└ ; │ @ promotion.jl:313 within `+' @ float.jl:395 %3 = fadd double %2, %0 ; └ ret double %3 }

When we add an `Int`

to a `Float64`

, we promote the `Int`

to a `Float64`

and then perform the `+`

between two `Float64`

s. When we go to the full function, we see that it can still infer:

@code_warntype g(2.0,5)

Body::Float64 1 ─ %1 = (Base.add_float)(x, 4.0)::Float64 │ %2 = (Base.add_float)(2.0, %1)::Float64 │ %3 = (Base.sitofp)(Float64, y)::Float64 │ %4 = (Base.add_float)(%2, %3)::Float64 └── return %4

and it uses this to build a very efficient assembly code because it knows exactly what the types will be at every step:

@code_llvm g(2.0,5)

; @ none:2 within `g' ; Function Attrs: uwtable define double @julia_g_15496(double, i64) #0 { top: ; @ none:4 within `g' ; ┌ @ none:1 within `f' ; │┌ @ promotion.jl:313 within `+' @ float.jl:395 %2 = fadd double %0, 4.000000e+00 ; └└ ; @ none:5 within `g' ; ┌ @ none:1 within `f' ; │┌ @ promotion.jl:313 within `+' @ float.jl:395 %3 = fadd double %2, 2.000000e+00 ; └└ ; @ none:6 within `g' ; ┌ @ none:1 within `f' ; │┌ @ promotion.jl:313 within `+' ; ││┌ @ promotion.jl:284 within `promote' ; │││┌ @ promotion.jl:261 within `_promote' ; ││││┌ @ number.jl:7 within `convert' ; │││││┌ @ float.jl:60 within `Type' %4 = sitofp i64 %1 to double ; ││└└└└ ; ││ @ promotion.jl:313 within `+' @ float.jl:395 %5 = fadd double %3, %4 ; └└ ret double %5 }

(notice how it handles the constant *literals* 4 and 2: it converted them at compile time to reduce the algorithm to 3 floating point additions).

Why is the inference algorithm able to infer all of the types of `g`

? It's because it knows the types coming out of `f`

at compile time. Given an `Int`

and a `Float64`

, `f`

will always output a `Float64`

, and thus it can continue with inference knowing that `c`

, `d`

, and eventually the output is `Float64`

. Thus in order for this to occur, we need that the type of the output on our function is directly inferred from the type of the input. This property is known as type-stability.

An example of breaking it is as follows:

function h(x,y) out = x + y rand() < 0.5 ? out : Float64(out) end

h (generic function with 1 method)

Here, on an integer input the output's type is randomly either Int or Float64, and thus the output is unknown:

@code_warntype h(2,5)

Body::UNION{FLOAT64, INT64} 1 ── %1 = (Base.add_int)(x, y)::Int64 │ %2 = Random.GLOBAL_RNG::Random.MersenneTwister │ %3 = (Base.getfield)(%2, :idxF)::Int64 │ %4 = Random.MT_CACHE_F::Int64 │ %5 = (%3 === %4)::Bool └─── goto #3 if not %5 2 ── %7 = $(Expr(:gc_preserve_begin, :(%2))) │ %8 = (Base.getfield)(%2, :state)::Random.DSFMT.DSFMT_state │ %9 = (Base.getfield)(%2, :vals)::Array{Float64,1} │ %10 = $(Expr(:foreigncall, :(:jl_array_ptr), Ptr{Float64}, svec(Any), :(:ccall), 1, :(%9)))::Ptr{Float64} │ %11 = (Base.getfield)(%2, :vals)::Array{Float64,1} │ %12 = (Base.arraylen)(%11)::Int64 │ invoke Random.dsfmt_fill_array_close1_open2!(%8::Random.DSFMT.DS FMT_state, %10::Ptr{Float64}, %12::Int64) │ $(Expr(:gc_preserve_end, :(%7))) └─── (Base.setfield!)(%2, :idxF, 0) 3 ┄─ goto #4 4 ── %17 = (Base.getfield)(%2, :vals)::Array{Float64,1} │ %18 = (Base.getfield)(%2, :idxF)::Int64 │ %19 = (Base.add_int)(%18, 1)::Int64 │ (Base.setfield!)(%2, :idxF, %19) │ %21 = (Base.arrayref)(false, %17, %19)::Float64 └─── goto #5 5 ── goto #6 6 ── %24 = (Base.sub_float)(%21, 1.0)::Float64 └─── goto #7 7 ── goto #8 8 ── goto #9 9 ── %28 = (Base.lt_float)(%24, 0.5)::Bool └─── goto #11 if not %28 10 ─ return %1 11 ─ %31 = (Base.sitofp)(Float64, %1)::Float64 └─── return %31

This means that its output type is `Union{Int,Float64}`

(Julia uses union types to keep the types still somewhat constrained). Once there are multiple choices, those need to get propogated through the compiler, and all subsequent calculations are the result of either being an `Int`

or a `Float64`

.

(Note that Julia has small union optimizations, so if this union is of size 4 or less then Julia will still be able to optimize it quite a bit.)

The `+`

function on numbers was implemented in Julia, so how were these rules all written down? The answer is multiple dispatch. In Julia, you can tell a function how to act differently on different types by using type assertions on the input values. For example, let's make a function that computes `2x + y`

on `Int`

and `x/y`

on `Float64`

:

ff(x::Int,y::Int) = 2x + y ff(x::Float64,y::Float64) = x/y @show ff(2,5)

ff(2, 5) = 9

@show ff(2.0,5.0)

ff(2.0, 5.0) = 0.4 0.4

The `+`

function in Julia is just defined as `+(a,b)`

, and we can actually point to that code in the Julia distribution:

@which +(2.0,5)+(x::

To control at a higher level, Julia uses *abstract types*. For example, `Float64 <: AbstractFloat`

, meaning `Float64`

s are a subtype of `AbstractFloat`

. We also have that `Int <: Integer`

, while both `AbstractFloat <: Number`

and `Integer <: Number`

.

Julia allows the user to define dispatches at a higher level, and the version that is called is the most strict version that is correct. For example, right now with `ff`

we will get a `MethodError`

if we call it between a `Int`

and a `Float64`

because no such method exists:

ff(2.0,5)

ERROR: MethodError: no method matching ff(::Float64, ::Int64) Closest candidates are: ff(::Float64, !Matched::Float64) at none:1 ff(!Matched::Int64, ::Int64) at none:1

However, we can add a *fallback method* to the function `ff`

for two numbers:

ff(x::Number,y::Number) = x + y ff(2.0,5)

7.0

Notice that the fallback method still specailizes on the inputs:

@code_llvm ff(2.0,5)

; @ none:1 within `ff' ; Function Attrs: uwtable define double @julia_ff_15565(double, i64) #0 { top: ; ┌ @ promotion.jl:313 within `+' ; │┌ @ promotion.jl:284 within `promote' ; ││┌ @ promotion.jl:261 within `_promote' ; │││┌ @ number.jl:7 within `convert' ; ││││┌ @ float.jl:60 within `Type' %2 = sitofp i64 %1 to double ; │└└└└ ; │ @ promotion.jl:313 within `+' @ float.jl:395 %3 = fadd double %2, %0 ; └ ret double %3 }

It's essentially just a template for what functions to possibly try and create given the types that are seen. When it sees `Float64`

and `Int`

, it knows it should try and create the function that does `x+y`

, and once it knows it's `Float64`

plus a `Int`

, it knows it should create the function that converts the `Int`

to a `Float64`

and then does addition between two `Float64`

s, and that is precisely the generated LLVM IR on this pair of input types.

And that's essentially Julia's secret sauce: since it's always specializing its types on each function, if those functions themselves can infer the output, then the entire function can be inferred and generate optimal code, which is then optimized by the compiler and out comes an efficient function. If types can't be inferred, Julia falls back to a slower "Python" mode (though with optimizations in cases like small unions). Users then get control over this specialization process through multiple dispatch, which is then Julia's core feature since it allows adding new options without any runtime cost.

Note that `f(x,y) = x+y`

is equivalent to `f(x::Any,y::Any) = x+y`

, where `Any`

is the maximal supertype of every Julia type. Thus `f(x,y) = x+y`

is essentially a fallback for all possible input values, telling it what to do in the case that no other dispatches exist. However, note that this dispatch itself is not slow, since it will be specailized on the input types.

The version that is called is the most strict version that is correct. What happens if it's impossible to define "the most strict version"? For example,

ff(x::Float64,y::Number) = 5x + 2y ff(x::Number,y::Int) = x - y

ff (generic function with 5 methods)

What should it call on `f(2.0,5)`

now? `ff(x::Float64,y::Number)`

and `ff(x::Number,y::Int)`

are both more strict than `ff(x::Number,y::Number)`

, so one of them should be called, but neither are more strict than each other, and thus you will end up with an ambiguity error:

ff(2.0,5)

ERROR: MethodError: Main.WeaveSandBox0.ff(::Float64, ::Int64) is ambiguous. Candidates: ff(x::Number, y::Int64) in Main.WeaveSandBox0 at none:1 ff(x::Float64, y::Number) in Main.WeaveSandBox0 at none:1 Possible fix, define ff(::Float64, ::Int64)

One way to ruin inference is to use an untyped container. For example, the array constructors use type inference themselves to know what their container type will be. Therefore,

a = [1.0,2.0,3.0]

3-element Array{Float64,1}: 1.0 2.0 3.0

uses type inference on its inputs to know that it should be something that holds `Float64`

values, and thus it is a 1-dimensional array of `Float64`

values, or `Array{Float64,1}`

. The accesses:

a[1]

1.0

are then inferred, since this is just the function `getindex(a::Array{T},i) where T`

which is a function that will produce something of type `T`

, the element type of the array. However, if we tell Julia to make an array with element type `Any`

:

b = ["1.0",2,2.0]

3-element Array{Any,1}: "1.0" 2 2.0

(here, Julia falls back to `Any`

because it cannot promote the values to the same type), then the best inference can do on the output is to say it could have any type:

function bad_container(a) a[2] end @code_warntype bad_container(a)

Body::Float64 1 ─ %1 = (Base.arrayref)(true, a, 2)::Float64 └── return %1

@code_warntype bad_container(b)

Body::ANY 1 ─ %1 = (Base.arrayref)(true, a, 2)::ANY └── return %1

This is one common way that type inference can breakdown. For example, even if the array is all numbers, we can still break inference:

x = Number[1.0,3] function q(x) a = 4 b = 2 c = f(x[1],a) d = f(b,c) f(d,x[2]) end @code_warntype q(x)

Body::ANY 1 ─ %1 = (Base.arrayref)(true, x, 1)::NUMBER │ %2 = π (4, Core.Compiler.Const(4, false)) │ %3 = (Main.WeaveSandBox0.f)(%1, %2)::ANY │ %4 = π (2, Core.Compiler.Const(2, false)) │ %5 = (Main.WeaveSandBox0.f)(%4, %3)::ANY │ %6 = (Base.arrayref)(true, x, 2)::NUMBER │ %7 = (Main.WeaveSandBox0.f)(%5, %6)::ANY └── return %7

Here the type inference algorithm quickly gives up and infers to `Any`

, losing all specialization and automatically switching to Python-style runtime type checking.

In Julia, types which can fully inferred and which are composed of primitive or `isbits`

types are value types. This means that, inside of an array, their values are the values of the type itself, and not a pointer to the values.

You can check if the type is a value type through `isbits`

:

isbits(1.0)

true

Note that a Julia `struct`

which holds i`sbits`

values is `isbits`

as well, if it's fully inferred:

struct MyComplex real::Float64 imag::Float64 end isbits(MyComplex(1.0,1.0))

true

We can see that the compiler knows how to use this efficiently since it knows that what comes out is always `Float64`

:

Base.:+(a::MyComplex,b::MyComplex) = MyComplex(a.real+b.real,a.imag+b.imag) Base.:+(a::MyComplex,b::Int) = MyComplex(a.real+b,a.imag) Base.:+(b::Int,a::MyComplex) = MyComplex(a.real+b,a.imag) g(MyComplex(1.0,1.0),MyComplex(1.0,1.0))

Main.WeaveSandBox0.MyComplex(8.0, 2.0)

@code_warntype g(MyComplex(1.0,1.0),MyComplex(1.0,1.0))

Body::Main.WeaveSandBox0.MyComplex 1 ─ %1 = (Base.getfield)(x, :real)::Float64 │ %2 = (Base.add_float)(%1, 4.0)::Float64 │ %3 = (Base.getfield)(x, :imag)::Float64 │ %4 = (Base.add_float)(%2, 2.0)::Float64 │ %5 = (Base.getfield)(y, :real)::Float64 │ %6 = (Base.add_float)(%4, %5)::Float64 │ %7 = (Base.getfield)(y, :imag)::Float64 │ %8 = (Base.add_float)(%3, %7)::Float64 │ %9 = %new(Main.WeaveSandBox0.MyComplex, %6, %8)::Main.WeaveSandBox0.MyC omplex └── return %9

@code_llvm g(MyComplex(1.0,1.0),MyComplex(1.0,1.0))

; @ none:2 within `g' ; Function Attrs: uwtable define void @julia_g_15620({ double, double }* noalias nocapture sret, { do uble, double } addrspace(11)* nocapture nonnull readonly dereferenceable(16 ), { double, double } addrspace(11)* nocapture nonnull readonly dereference able(16)) #0 { top: ; @ none:4 within `g' ; ┌ @ none:1 within `f' ; │┌ @ none:1 within `+' ; ││┌ @ sysimg.jl:18 within `getproperty' %3 = getelementptr inbounds { double, double }, { double, double } add rspace(11)* %1, i64 0, i32 0 ; ││└ ; ││ @ none:1 within `+' @ promotion.jl:313 @ float.jl:395 %4 = load double, double addrspace(11)* %3, align 8 %5 = fadd double %4, 4.000000e+00 ; ││ @ none:1 within `+' ; ││┌ @ sysimg.jl:18 within `getproperty' %6 = getelementptr inbounds { double, double }, { double, double } add rspace(11)* %1, i64 0, i32 1 ; └└└ ; @ none:5 within `g' ; ┌ @ none:1 within `f' ; │┌ @ none:1 within `+' @ promotion.jl:313 @ float.jl:395 %7 = fadd double %5, 2.000000e+00 ; └└ ; @ none:6 within `g' ; ┌ @ none:1 within `f' ; │┌ @ none:1 within `+' @ float.jl:395 %8 = load double, double addrspace(11)* %6, align 8 %9 = bitcast { double, double } addrspace(11)* %2 to <2 x double> addrs pace(11)* %10 = load <2 x double>, <2 x double> addrspace(11)* %9, align 8 %11 = insertelement <2 x double> undef, double %7, i32 0 %12 = insertelement <2 x double> %11, double %8, i32 1 %13 = fadd <2 x double> %10, %12 ; └└ %14 = bitcast { double, double }* %0 to <2 x double>* store <2 x double> %13, <2 x double>* %14, align 8 ret void }

Note that the compiled code simply works directly on the `double`

pieces. We can also make this be concrete without pre-specifying that the values always have to be `Float64`

by using a type parameter.

struct MyParameterizedComplex{T} real::T imag::T end isbits(MyParameterizedComplex(1.0,1.0))

true

Note that `MyParameterizedComplex{T}`

is a concrete type for every `T`

: it is a shorthand form for defining a whole family of types.

Base.:+(a::MyParameterizedComplex,b::MyParameterizedComplex) = MyParameterizedComplex(a.real+b.real,a.imag+b.imag) Base.:+(a::MyParameterizedComplex,b::Int) = MyParameterizedComplex(a.real+b,a.imag) Base.:+(b::Int,a::MyParameterizedComplex) = MyParameterizedComplex(a.real+b,a.imag) g(MyParameterizedComplex(1.0,1.0),MyParameterizedComplex(1.0,1.0))

Main.WeaveSandBox0.MyParameterizedComplex{Float64}(8.0, 2.0)

@code_warntype g(MyParameterizedComplex(1.0,1.0),MyParameterizedComplex(1.0,1.0))

Body::Main.WeaveSandBox0.MyParameterizedComplex{Float64} 1 ─ %1 = (Base.getfield)(x, :real)::Float64 │ %2 = (Base.add_float)(%1, 4.0)::Float64 │ %3 = (Base.getfield)(x, :imag)::Float64 │ %4 = (Base.add_float)(%2, 2.0)::Float64 │ %5 = (Base.getfield)(y, :real)::Float64 │ %6 = (Base.add_float)(%4, %5)::Float64 │ %7 = (Base.getfield)(y, :imag)::Float64 │ %8 = (Base.add_float)(%3, %7)::Float64 │ %9 = %new(Main.WeaveSandBox0.MyParameterizedComplex{Float64}, %6, %8):: Main.WeaveSandBox0.MyParameterizedComplex{Float64} └── return %9

See that this code also automatically works and compiles efficiently for `Float32`

as well:

@code_warntype g(MyParameterizedComplex(1.0f0,1.0f0),MyParameterizedComplex(1.0f0,1.0f0))

Body::Main.WeaveSandBox0.MyParameterizedComplex{Float32} 1 ─ %1 = (Base.getfield)(x, :real)::Float32 │ %2 = (Base.add_float)(%1, 4.0f0)::Float32 │ %3 = (Base.getfield)(x, :imag)::Float32 │ %4 = (Base.add_float)(%2, 2.0f0)::Float32 │ %5 = (Base.getfield)(y, :real)::Float32 │ %6 = (Base.add_float)(%4, %5)::Float32 │ %7 = (Base.getfield)(y, :imag)::Float32 │ %8 = (Base.add_float)(%3, %7)::Float32 │ %9 = %new(Main.WeaveSandBox0.MyParameterizedComplex{Float32}, %6, %8):: Main.WeaveSandBox0.MyParameterizedComplex{Float32} └── return %9

@code_llvm g(MyParameterizedComplex(1.0f0,1.0f0),MyParameterizedComplex(1.0f0,1.0f0))

; @ none:2 within `g' ; Function Attrs: uwtable define { float, float } @julia_g_15636({ float, float } addrspace(11)* noca pture nonnull readonly dereferenceable(8), { float, float } addrspace(11)* nocapture nonnull readonly dereferenceable(8)) #0 { top: ; @ none:4 within `g' ; ┌ @ none:1 within `f' ; │┌ @ none:1 within `+' ; ││┌ @ sysimg.jl:18 within `getproperty' %2 = getelementptr inbounds { float, float }, { float, float } addrspa ce(11)* %0, i64 0, i32 0 ; ││└ ; ││ @ none:1 within `+' @ promotion.jl:313 @ float.jl:394 %3 = load float, float addrspace(11)* %2, align 4 %4 = fadd float %3, 4.000000e+00 ; ││ @ none:1 within `+' ; ││┌ @ sysimg.jl:18 within `getproperty' %5 = getelementptr inbounds { float, float }, { float, float } addrspa ce(11)* %0, i64 0, i32 1 ; └└└ ; @ none:5 within `g' ; ┌ @ none:1 within `f' ; │┌ @ none:1 within `+' @ promotion.jl:313 @ float.jl:394 %6 = fadd float %4, 2.000000e+00 ; └└ ; @ none:6 within `g' ; ┌ @ none:1 within `f' ; │┌ @ none:1 within `+' ; ││┌ @ sysimg.jl:18 within `getproperty' %7 = getelementptr inbounds { float, float }, { float, float } addrspa ce(11)* %1, i64 0, i32 0 ; ││└ ; ││ @ none:1 within `+' @ float.jl:394 %8 = load float, float addrspace(11)* %7, align 4 %9 = fadd float %8, %6 ; ││ @ none:1 within `+' ; ││┌ @ sysimg.jl:18 within `getproperty' %10 = getelementptr inbounds { float, float }, { float, float } addrsp ace(11)* %1, i64 0, i32 1 ; ││└ ; ││ @ none:1 within `+' @ float.jl:394 %11 = load float, float addrspace(11)* %5, align 4 %12 = load float, float addrspace(11)* %10, align 4 %13 = fadd float %11, %12 ; └└ %.fca.0.insert = insertvalue { float, float } undef, float %9, 0 %.fca.1.insert = insertvalue { float, float } %.fca.0.insert, float %13, 1 ret { float, float } %.fca.1.insert }

It is important to know that if there is any piece of a type which doesn't contain type information, then it cannot be isbits because then it would have to be compiled in such a way that the size is not known in advance. For example:

struct MySlowComplex real imag end isbits(MySlowComplex(1.0,1.0))

false

Base.:+(a::MySlowComplex,b::MySlowComplex) = MySlowComplex(a.real+b.real,a.imag+b.imag) Base.:+(a::MySlowComplex,b::Int) = MySlowComplex(a.real+b,a.imag) Base.:+(b::Int,a::MySlowComplex) = MySlowComplex(a.real+b,a.imag) g(MySlowComplex(1.0,1.0),MySlowComplex(1.0,1.0))

Main.WeaveSandBox0.MySlowComplex(8.0, 2.0)

@code_warntype g(MySlowComplex(1.0,1.0),MySlowComplex(1.0,1.0))

Body::Main.WeaveSandBox0.MySlowComplex 1 ─ %1 = π (4, Core.Compiler.Const(4, false)) │ %2 = invoke Main.WeaveSandBox0.:+(_2::Main.WeaveSandBox0.MySlowComplex, %1::Int64)::Main.WeaveSandBox0.MySlowComplex │ %3 = π (2, Core.Compiler.Const(2, false)) │ %4 = invoke Main.WeaveSandBox0.:+(%3::Int64, %2::Main.WeaveSandBox0.MyS lowComplex)::Main.WeaveSandBox0.MySlowComplex │ %5 = invoke Main.WeaveSandBox0.:+(%4::Main.WeaveSandBox0.MySlowComplex, _3::Main.WeaveSandBox0.MySlowComplex)::Main.WeaveSandBox0.MySlowComplex └── return %5

@code_llvm g(MySlowComplex(1.0,1.0),MySlowComplex(1.0,1.0))

; @ none:2 within `g' ; Function Attrs: uwtable define nonnull %jl_value_t addrspace(10)* @japi1_g_15638(%jl_value_t addrsp ace(10)*, %jl_value_t addrspace(10)**, i32) #0 { top: %3 = alloca %jl_value_t addrspace(10)*, i32 2 %gcframe = alloca %jl_value_t addrspace(10)*, i32 3 %4 = bitcast %jl_value_t addrspace(10)** %gcframe to i8* call void @llvm.memset.p0i8.i32(i8* %4, i8 0, i32 24, i32 0, i1 false) %5 = alloca %jl_value_t addrspace(10)**, align 8 store volatile %jl_value_t addrspace(10)** %1, %jl_value_t addrspace(10)* ** %5, align 8 %6 = call %jl_value_t*** inttoptr (i64 18155952000 to %jl_value_t*** ()*) () #3 %7 = getelementptr %jl_value_t addrspace(10)*, %jl_value_t addrspace(10)* * %gcframe, i32 0 %8 = bitcast %jl_value_t addrspace(10)** %7 to i64* store i64 2, i64* %8 %9 = getelementptr %jl_value_t**, %jl_value_t*** %6, i32 0 %10 = getelementptr %jl_value_t addrspace(10)*, %jl_value_t addrspace(10) ** %gcframe, i32 1 %11 = bitcast %jl_value_t addrspace(10)** %10 to %jl_value_t*** %12 = load %jl_value_t**, %jl_value_t*** %9 store %jl_value_t** %12, %jl_value_t*** %11 %13 = bitcast %jl_value_t*** %9 to %jl_value_t addrspace(10)*** store %jl_value_t addrspace(10)** %gcframe, %jl_value_t addrspace(10)*** %13 %14 = load %jl_value_t addrspace(10)*, %jl_value_t addrspace(10)** %1, al ign 8 %15 = getelementptr inbounds %jl_value_t addrspace(10)*, %jl_value_t addr space(10)** %1, i64 1 %16 = load %jl_value_t addrspace(10)*, %jl_value_t addrspace(10)** %15, a lign 8 ; @ none:4 within `g' ; ┌ @ none:1 within `f' %17 = call nonnull %jl_value_t addrspace(10)* @"julia_+_15639"(%jl_value _t addrspace(10)* nonnull %14, i64 4) %18 = getelementptr %jl_value_t addrspace(10)*, %jl_value_t addrspace(10 )** %gcframe, i32 2 store %jl_value_t addrspace(10)* %17, %jl_value_t addrspace(10)** %18 ; └ ; @ none:5 within `g' ; ┌ @ none:1 within `f' %19 = call nonnull %jl_value_t addrspace(10)* @"julia_+_15640"(i64 2, %j l_value_t addrspace(10)* nonnull %17) %20 = getelementptr %jl_value_t addrspace(10)*, %jl_value_t addrspace(10 )** %gcframe, i32 2 store %jl_value_t addrspace(10)* %19, %jl_value_t addrspace(10)** %20 ; └ ; @ none:6 within `g' ; ┌ @ none:1 within `f' %21 = getelementptr %jl_value_t addrspace(10)*, %jl_value_t addrspace(10 )** %3, i32 0 store %jl_value_t addrspace(10)* %19, %jl_value_t addrspace(10)** %21 %22 = getelementptr %jl_value_t addrspace(10)*, %jl_value_t addrspace(10 )** %3, i32 1 store %jl_value_t addrspace(10)* %16, %jl_value_t addrspace(10)** %22 %23 = call nonnull %jl_value_t addrspace(10)* @"japi1_+_15641"(%jl_value _t addrspace(10)* addrspacecast (%jl_value_t* inttoptr (i64 21697839088 to %jl_value_t*) to %jl_value_t addrspace(10)*), %jl_value_t addrspace(10)** % 3, i32 2) ; └ %24 = getelementptr %jl_value_t addrspace(10)*, %jl_value_t addrspace(10) ** %gcframe, i32 1 %25 = load %jl_value_t addrspace(10)*, %jl_value_t addrspace(10)** %24 %26 = getelementptr %jl_value_t**, %jl_value_t*** %6, i32 0 %27 = bitcast %jl_value_t*** %26 to %jl_value_t addrspace(10)** store %jl_value_t addrspace(10)* %25, %jl_value_t addrspace(10)** %27 ret %jl_value_t addrspace(10)* %23 }

struct MySlowComplex2 real::AbstractFloat imag::AbstractFloat end isbits(MySlowComplex2(1.0,1.0))

false

Base.:+(a::MySlowComplex2,b::MySlowComplex2) = MySlowComplex2(a.real+b.real,a.imag+b.imag) Base.:+(a::MySlowComplex2,b::Int) = MySlowComplex2(a.real+b,a.imag) Base.:+(b::Int,a::MySlowComplex2) = MySlowComplex2(a.real+b,a.imag) g(MySlowComplex2(1.0,1.0),MySlowComplex2(1.0,1.0))

Main.WeaveSandBox0.MySlowComplex2(8.0, 2.0)

Here's the timings:

a = MyComplex(1.0,1.0) b = MyComplex(2.0,1.0) @btime g(a,b)

17.635 ns (1 allocation: 32 bytes) Main.WeaveSandBox0.MyComplex(9.0, 2.0)

a = MyParameterizedComplex(1.0,1.0) b = MyParameterizedComplex(2.0,1.0) @btime g(a,b)

19.257 ns (1 allocation: 32 bytes) Main.WeaveSandBox0.MyParameterizedComplex{Float64}(9.0, 2.0)

a = MySlowComplex(1.0,1.0) b = MySlowComplex(2.0,1.0) @btime g(a,b)

92.976 ns (7 allocations: 160 bytes) Main.WeaveSandBox0.MySlowComplex(9.0, 2.0)

a = MySlowComplex2(1.0,1.0) b = MySlowComplex2(2.0,1.0) @btime g(a,b)

434.843 ns (13 allocations: 256 bytes) Main.WeaveSandBox0.MySlowComplex2(9.0, 2.0)

Note that, because of these type specialization, value types, etc. properties, the number types, even ones such as `Int`

, `Float64`

, and `Complex`

, are all themselves implemented in pure Julia! Thus even basic pieces can be implemented in Julia with full performance, given one uses the features correctly.

Note that a type which is `mutable struct`

will not be isbits. This means that mutable structs will be a pointer to a heap allocated object, unless it's shortlived and the compiler can erase its construction. Also, note that `isbits`

compiles down to bit operations from pure Julia, which means that these types can directly compile to GPU kernels through CUDAnative without modification.

Since functions automatically specialize on their input types in Julia, we can use this to our advantage in order to make an inner loop fully inferred. For example, take the code from above but with a loop:

function r(x) a = 4 b = 2 for i in 1:100 c = f(x[1],a) d = f(b,c) a = f(d,x[2]) end a end @btime r(x)

4.186 μs (300 allocations: 4.69 KiB) 604.0

In here, the loop variables are not inferred and thus this is really slow. However, we can force a function call in the middle to end up with specialization and in the inner loop be stable:

s(x) = _s(x[1],x[2]) function _s(x1,x2) a = 4 b = 2 for i in 1:100 c = f(x1,a) d = f(b,c) a = f(d,x2) end a end @btime s(x)

306.611 ns (1 allocation: 16 bytes) 604.0

Notice that this algorithm still doesn't infer:

@code_warntype s(x)

Body::ANY 1 ─ %1 = (Base.arrayref)(true, x, 1)::NUMBER │ %2 = (Base.arrayref)(true, x, 2)::NUMBER │ %3 = (Main.WeaveSandBox0._s)(%1, %2)::ANY └── return %3

since the output of `_s`

isn't inferred, but while it's in `_s`

it will have specialized on the fact that `x[1]`

is a `Float64`

while `x[2]`

is a `Int`

, making that inner loop fast. In fact, it will only need to pay one *dynamic dispatch*, i.e. a multiple dispatch determination that happens at runtime. Notice that whenever functions are inferred, the dispatching is static since the choice of the dispatch is already made and compiled into the LLVM IR.

Julia code will specialize at compile time if it can prove something about the result. For example:

function fff(x) if x isa Int y = 2 else y = 4.0 end x + y end

fff (generic function with 1 method)

You might think this function has a branch, but in reality Julia can determine whether `x`

is an `Int`

or not at compile time, so it will actually compile it away and just turn it into the function `x+2`

or `x+4.0`

:

@code_llvm fff(5)

; @ none:2 within `fff' ; Function Attrs: uwtable define i64 @julia_fff_15764(i64) #0 { top: ; @ none:7 within `fff' ; ┌ @ int.jl:53 within `+' %1 = add i64 %0, 2 ; └ ret i64 %1 }

@code_llvm fff(2.0)

; @ none:2 within `fff' ; Function Attrs: uwtable define double @julia_fff_15765(double) #0 { top: ; @ none:7 within `fff' ; ┌ @ float.jl:395 within `+' %1 = fadd double %0, 4.000000e+00 ; └ ret double %1 }

Thus one does not need to worry about over-optimizing since in the obvious cases the compiler will actually remove all of the extra pieces when it can!

This discussion shows how Julia's optimizations all apply during function specialization times. Thus calling Julia functions is fast. But what about when doing something outside of the function, like directly in a module or in the REPL?

@btime for j in 1:100, i in 1:100 global A,B,C C[i,j] = A[i,j] + B[i,j] end

748.800 μs (30000 allocations: 468.75 KiB)

This is very slow because the types of `A`

, `B`

, and `C`

cannot be inferred. Why can't they be inferred? Well, at any time in the dynamic REPL scope I can do something like `C = "haha now a string!"`

, and thus it cannot specialize on the types currently existing in the REPL (since asynchronous changes could also occur), and therefore it defaults back to doing a type check at every single function which slows it down. Moral of the story, Julia functions are fast but its global scope is too dynamic to be optimized.

Julia is not fast because of its JIT, it's fast because of function specialization and type inference

Type stable functions allow inference to fully occur

Multiple dispatch works within the function specialization mechanism to create overhead-free compile time controls

Julia will specialize the generic functions

Making sure values are concretely typed in inner loops is essential for performance

Now let's dig even a little deeper. Everything the processor does has a cost. A great chart to keep in mind is this classic one. A few things should immediately jump out to you:

Simple arithmetic, like floating point additions, are super cheap. ~1 clock cycle, or a few nanoseconds.

Processors do

*branch prediction*on`if`

statements. If the code goes down the predicted route, the`if`

statement costs ~1-2 clock cycles. If it goes down the wrong route, then it will take ~10-20 clock cycles. This means that predictable branches, like ones with clear patterns or usually the same output, are much cheaper (almost free) than unpredictable branches.Function calls are expensive: 15-60 clock cycles!

RAM reads are very expensive, with lower caches less expensive.

Let's check the LLVM IR on one of our earlier loops:

function inner_noalloc!(C,A,B) for j in 1:100, i in 1:100 val = A[i,j] + B[i,j] C[i,j] = val[1] end end @code_llvm inner_noalloc!(C,A,B)

; @ none:2 within `inner_noalloc!' ; Function Attrs: uwtable define nonnull %jl_value_t addrspace(10)* @"japi1_inner_noalloc!_15782"(%jl _value_t addrspace(10)*, %jl_value_t addrspace(10)**, i32) #0 { top: %3 = alloca %jl_value_t addrspace(10)**, align 8 store volatile %jl_value_t addrspace(10)** %1, %jl_value_t addrspace(10)* ** %3, align 8 %4 = getelementptr inbounds %jl_value_t addrspace(10)*, %jl_value_t addrs pace(10)** %1, i64 1 %5 = load %jl_value_t addrspace(10)*, %jl_value_t addrspace(10)** %4, ali gn 8 ; @ none:3 within `inner_noalloc!' ; ┌ @ array.jl:730 within `getindex' %6 = addrspacecast %jl_value_t addrspace(10)* %5 to %jl_value_t addrspac e(11)* %7 = bitcast %jl_value_t addrspace(11)* %6 to %jl_value_t addrspace(10)* addrspace(11)* %8 = getelementptr inbounds %jl_value_t addrspace(10)*, %jl_value_t addr space(10)* addrspace(11)* %7, i64 3 %9 = bitcast %jl_value_t addrspace(10)* addrspace(11)* %8 to i64 addrspa ce(11)* %10 = load i64, i64 addrspace(11)* %9, align 8 %11 = icmp eq i64 %10, 0 br i1 %11, label %oob, label %ib.lr.ph.lr.ph.split.us ib.lr.ph.lr.ph.split.us: ; preds = %top %12 = load %jl_value_t addrspace(10)*, %jl_value_t addrspace(10)** %1, a lign 8 %13 = getelementptr inbounds %jl_value_t addrspace(10)*, %jl_value_t add rspace(10)** %1, i64 2 %14 = load %jl_value_t addrspace(10)*, %jl_value_t addrspace(10)** %13, align 8 %15 = getelementptr inbounds %jl_value_t addrspace(10)*, %jl_value_t add rspace(10)* addrspace(11)* %7, i64 4 %16 = bitcast %jl_value_t addrspace(10)* addrspace(11)* %15 to i64 addrs pace(11)* %17 = load i64, i64 addrspace(11)* %16, align 8 %18 = bitcast %jl_value_t addrspace(11)* %6 to double addrspace(13)* add rspace(11)* %19 = load double addrspace(13)*, double addrspace(13)* addrspace(11)* % 18, align 8 %20 = addrspacecast %jl_value_t addrspace(10)* %14 to %jl_value_t addrsp ace(11)* %21 = bitcast %jl_value_t addrspace(11)* %20 to %jl_value_t addrspace(10 )* addrspace(11)* %22 = getelementptr inbounds %jl_value_t addrspace(10)*, %jl_value_t add rspace(10)* addrspace(11)* %21, i64 3 %23 = bitcast %jl_value_t addrspace(10)* addrspace(11)* %22 to i64 addrs pace(11)* %24 = load i64, i64 addrspace(11)* %23, align 8 %25 = getelementptr inbounds %jl_value_t addrspace(10)*, %jl_value_t add rspace(10)* addrspace(11)* %21, i64 4 %26 = bitcast %jl_value_t addrspace(10)* addrspace(11)* %25 to i64 addrs pace(11)* %27 = load i64, i64 addrspace(11)* %26, align 8 %28 = bitcast %jl_value_t addrspace(11)* %20 to double addrspace(13)* ad drspace(11)* %29 = load double addrspace(13)*, double addrspace(13)* addrspace(11)* % 28, align 8 %30 = addrspacecast %jl_value_t addrspace(10)* %12 to %jl_value_t addrsp ace(11)* %31 = bitcast %jl_value_t addrspace(11)* %30 to %jl_value_t addrspace(10 )* addrspace(11)* %32 = getelementptr inbounds %jl_value_t addrspace(10)*, %jl_value_t add rspace(10)* addrspace(11)* %31, i64 3 %33 = bitcast %jl_value_t addrspace(10)* addrspace(11)* %32 to i64 addrs pace(11)* %34 = load i64, i64 addrspace(11)* %33, align 8 %35 = getelementptr inbounds %jl_value_t addrspace(10)*, %jl_value_t add rspace(10)* addrspace(11)* %31, i64 4 %36 = bitcast %jl_value_t addrspace(10)* addrspace(11)* %35 to i64 addrs pace(11)* %37 = load i64, i64 addrspace(11)* %36, align 8 %38 = bitcast %jl_value_t addrspace(11)* %30 to double addrspace(13)* ad drspace(11)* %39 = load double addrspace(13)*, double addrspace(13)* addrspace(11)* % 38, align 8 br label %ib.lr.ph.us ib.lr.ph.us: ; preds = %L35.us, %ib.lr .ph.lr.ph.split.us %value_phi30.us = phi i64 [ 1, %ib.lr.ph.lr.ph.split.us ], [ %44, %L35.u s ] %40 = add i64 %value_phi30.us, -1 %41 = icmp ult i64 %40, %17 %42 = icmp ult i64 %40, %37 br i1 %41, label %ib.lr.ph.split.us.us, label %oob L25.us: ; preds = %idxend9.us.us. us.us ; └ ; @ none:4 within `inner_noalloc!' ; ┌ @ range.jl:594 within `iterate' ; │┌ @ promotion.jl:403 within `==' %43 = icmp eq i64 %value_phi30.us, 100 ; └└ br i1 %43, label %L36, label %L35.us L35.us: ; preds = %L25.us ; ┌ @ range.jl:595 within `iterate' ; │┌ @ int.jl:53 within `+' %44 = add i64 %value_phi30.us, 1 ; └└ ; @ none:3 within `inner_noalloc!' ; ┌ @ array.jl:730 within `getindex' br label %ib.lr.ph.us ib.lr.ph.split.us.us: ; preds = %ib.lr.ph.us %45 = icmp ult i64 %40, %27 br i1 %45, label %ib.lr.ph.split.us.split.us.us, label %oob5 idxend.us.us.us: ; preds = %ib.lr.ph.split .us.split.us.us %46 = icmp eq i64 %24, 0 br i1 %46, label %oob5, label %oob8 ib.lr.ph.split.us.split.us.us: ; preds = %ib.lr.ph.split .us.us br i1 %42, label %ib.lr.ph.split.us.split.us.us.split.us, label %idxend. us.us.us ib.lr.ph.split.us.split.us.us.split.us: ; preds = %ib.lr.ph.split .us.split.us.us %47 = mul i64 %24, %40 %48 = mul i64 %34, %40 br label %idxend.us.us.us.us idxend.us.us.us.us: ; preds = %ib.lr.ph.split .us.split.us.us.split.us, %L24.us.us.us.us %49 = phi i64 [ 0, %ib.lr.ph.split.us.split.us.us.split.us ], [ %value_p hi224.us.us.us.us, %L24.us.us.us.us ] %value_phi224.us.us.us.us = phi i64 [ 1, %ib.lr.ph.split.us.split.us.us. split.us ], [ %63, %L24.us.us.us.us ] %50 = icmp ult i64 %49, %24 br i1 %50, label %idxend6.us.us.us.us, label %oob5 idxend6.us.us.us.us: ; preds = %idxend.us.us.u s.us ; └ ; @ none:4 within `inner_noalloc!' ; ┌ @ array.jl:769 within `setindex!' %51 = icmp ult i64 %49, %34 br i1 %51, label %idxend9.us.us.us.us, label %oob8 idxend9.us.us.us.us: ; preds = %idxend6.us.us. us.us ; └ ; @ none:3 within `inner_noalloc!' ; ┌ @ array.jl:730 within `getindex' %52 = mul i64 %10, %40 %53 = add i64 %49, %52 %54 = getelementptr inbounds double, double addrspace(13)* %19, i64 %53 %55 = load double, double addrspace(13)* %54, align 8 %56 = add i64 %49, %47 %57 = getelementptr inbounds double, double addrspace(13)* %29, i64 %56 %58 = load double, double addrspace(13)* %57, align 8 ; └ ; ┌ @ float.jl:395 within `+' %59 = fadd double %55, %58 ; └ ; @ none:4 within `inner_noalloc!' ; ┌ @ array.jl:769 within `setindex!' %60 = add i64 %49, %48 %61 = getelementptr inbounds double, double addrspace(13)* %39, i64 %60 store double %59, double addrspace(13)* %61, align 8 ; └ ; ┌ @ range.jl:594 within `iterate' ; │┌ @ promotion.jl:403 within `==' %62 = icmp eq i64 %value_phi224.us.us.us.us, 100 ; └└ br i1 %62, label %L25.us, label %L24.us.us.us.us L24.us.us.us.us: ; preds = %idxend9.us.us. us.us ; ┌ @ range.jl:595 within `iterate' ; │┌ @ int.jl:53 within `+' %63 = add nuw nsw i64 %value_phi224.us.us.us.us, 1 ; └└ ; @ none:3 within `inner_noalloc!' ; ┌ @ array.jl:730 within `getindex' %64 = icmp ult i64 %value_phi224.us.us.us.us, %10 br i1 %64, label %idxend.us.us.us.us, label %oob L36: ; preds = %L25.us ; └ ; @ none:4 within `inner_noalloc!' ret %jl_value_t addrspace(10)* addrspacecast (%jl_value_t* inttoptr (i64 87752712 to %jl_value_t*) to %jl_value_t addrspace(10)*) oob: ; preds = %ib.lr.ph.us, % L24.us.us.us.us, %top %value_phi.lcssa = phi i64 [ 1, %top ], [ %value_phi30.us, %L24.us.us.us. us ], [ %value_phi30.us, %ib.lr.ph.us ] %value_phi2.lcssa = phi i64 [ 1, %top ], [ %63, %L24.us.us.us.us ], [ 1, %ib.lr.ph.us ] ; @ none:3 within `inner_noalloc!' ; ┌ @ array.jl:730 within `getindex' %65 = alloca [2 x i64], align 8 %.sub = getelementptr inbounds [2 x i64], [2 x i64]* %65, i64 0, i64 0 store i64 %value_phi2.lcssa, i64* %.sub, align 8 %66 = getelementptr inbounds [2 x i64], [2 x i64]* %65, i64 0, i64 1 store i64 %value_phi.lcssa, i64* %66, align 8 %67 = addrspacecast %jl_value_t addrspace(10)* %5 to %jl_value_t addrspa ce(12)* call void @jl_bounds_error_ints(%jl_value_t addrspace(12)* %67, i64* non null %.sub, i64 2) unreachable oob5: ; preds = %ib.lr.ph.split .us.us, %idxend.us.us.us.us, %idxend.us.us.us %value_phi2.lcssa18.ph.us = phi i64 [ 1, %idxend.us.us.us ], [ %value_ph i224.us.us.us.us, %idxend.us.us.us.us ], [ 1, %ib.lr.ph.split.us.us ] %68 = alloca [2 x i64], align 8 %.sub16 = getelementptr inbounds [2 x i64], [2 x i64]* %68, i64 0, i64 0 store i64 %value_phi2.lcssa18.ph.us, i64* %.sub16, align 8 %69 = getelementptr inbounds [2 x i64], [2 x i64]* %68, i64 0, i64 1 store i64 %value_phi30.us, i64* %69, align 8 %70 = addrspacecast %jl_value_t addrspace(10)* %14 to %jl_value_t addrsp ace(12)* call void @jl_bounds_error_ints(%jl_value_t addrspace(12)* %70, i64* non null %.sub16, i64 2) unreachable oob8: ; preds = %idxend6.us.us. us.us, %idxend.us.us.us %value_phi2.lcssa19.ph.us.ph.us.ph.us = phi i64 [ 1, %idxend.us.us.us ], [ %value_phi224.us.us.us.us, %idxend6.us.us.us.us ] ; └ ; @ none:4 within `inner_noalloc!' ; ┌ @ array.jl:769 within `setindex!' %71 = alloca [2 x i64], align 8 %.sub17 = getelementptr inbounds [2 x i64], [2 x i64]* %71, i64 0, i64 0 store i64 %value_phi2.lcssa19.ph.us.ph.us.ph.us, i64* %.sub17, align 8 %72 = getelementptr inbounds [2 x i64], [2 x i64]* %71, i64 0, i64 1 store i64 %value_phi30.us, i64* %72, align 8 %73 = addrspacecast %jl_value_t addrspace(10)* %12 to %jl_value_t addrsp ace(12)* call void @jl_bounds_error_ints(%jl_value_t addrspace(12)* %73, i64* non null %.sub17, i64 2) unreachable ; └ }

Notice that this `getelementptr inbounds`

stuff is bounds checking. Julia, like all other high level languages, enables bounds checking by default in order to not allow the user to index outside of an array. Indexing outside of an array is dangerous: it can quite easily segfault your system if you change some memory that is unknown beyond your actual array. Thus Julia throws an error:

A[101,1]

ERROR: BoundsError: attempt to access 100×100 Array{Float64,2} at index [101, 1]

In tight inner loops, we can remove this bounds checking process using the `@inbounds`

macro:

function inner_noalloc_ib!(C,A,B) @inbounds for j in 1:100, i in 1:100 val = A[i,j] + B[i,j] C[i,j] = val[1] end end @btime inner_noalloc!(C,A,B)

6.520 μs (0 allocations: 0 bytes)

@btime inner_noalloc_ib!(C,A,B)

2.156 μs (0 allocations: 0 bytes)

Now let's inspect the LLVM IR again:

@code_llvm inner_noalloc_ib!(C,A,B)

; @ none:2 within `inner_noalloc_ib!' ; Function Attrs: uwtable define nonnull %jl_value_t addrspace(10)* @"japi1_inner_noalloc_ib!_15814"( %jl_value_t addrspace(10)*, %jl_value_t addrspace(10)**, i32) #0 { top: %3 = alloca %jl_value_t addrspace(10)**, align 8 store volatile %jl_value_t addrspace(10)** %1, %jl_value_t addrspace(10)* ** %3, align 8 %4 = load %jl_value_t addrspace(10)*, %jl_value_t addrspace(10)** %1, ali gn 8 %5 = getelementptr inbounds %jl_value_t addrspace(10)*, %jl_value_t addrs pace(10)** %1, i64 1 %6 = load %jl_value_t addrspace(10)*, %jl_value_t addrspace(10)** %5, ali gn 8 %7 = getelementptr inbounds %jl_value_t addrspace(10)*, %jl_value_t addrs pace(10)** %1, i64 2 %8 = load %jl_value_t addrspace(10)*, %jl_value_t addrspace(10)** %7, ali gn 8 %9 = addrspacecast %jl_value_t addrspace(10)* %6 to %jl_value_t addrspace (11)* %10 = bitcast %jl_value_t addrspace(11)* %9 to %jl_value_t addrspace(10)* addrspace(11)* %11 = getelementptr inbounds %jl_value_t addrspace(10)*, %jl_value_t addr space(10)* addrspace(11)* %10, i64 3 %12 = bitcast %jl_value_t addrspace(10)* addrspace(11)* %11 to i64 addrsp ace(11)* %13 = load i64, i64 addrspace(11)* %12, align 8 %14 = bitcast %jl_value_t addrspace(11)* %9 to double addrspace(13)* addr space(11)* %15 = load double addrspace(13)*, double addrspace(13)* addrspace(11)* %1 4, align 8 %16 = addrspacecast %jl_value_t addrspace(10)* %8 to %jl_value_t addrspac e(11)* %17 = bitcast %jl_value_t addrspace(11)* %16 to %jl_value_t addrspace(10) * addrspace(11)* %18 = getelementptr inbounds %jl_value_t addrspace(10)*, %jl_value_t addr space(10)* addrspace(11)* %17, i64 3 %19 = bitcast %jl_value_t addrspace(10)* addrspace(11)* %18 to i64 addrsp ace(11)* %20 = load i64, i64 addrspace(11)* %19, align 8 %21 = bitcast %jl_value_t addrspace(11)* %16 to double addrspace(13)* add rspace(11)* %22 = load double addrspace(13)*, double addrspace(13)* addrspace(11)* %2 1, align 8 %23 = addrspacecast %jl_value_t addrspace(10)* %4 to %jl_value_t addrspac e(11)* %24 = bitcast %jl_value_t addrspace(11)* %23 to %jl_value_t addrspace(10) * addrspace(11)* %25 = getelementptr inbounds %jl_value_t addrspace(10)*, %jl_value_t addr space(10)* addrspace(11)* %24, i64 3 %26 = bitcast %jl_value_t addrspace(10)* addrspace(11)* %25 to i64 addrsp ace(11)* %27 = load i64, i64 addrspace(11)* %26, align 8 %28 = bitcast %jl_value_t addrspace(11)* %23 to double addrspace(13)* add rspace(11)* %29 = load double addrspace(13)*, double addrspace(13)* addrspace(11)* %2 8, align 8 br label %L2 L2: ; preds = %L25, %top %indvar = phi i64 [ %indvar.next, %L25 ], [ 0, %top ] %value_phi = phi i64 [ %65, %L25 ], [ 1, %top ] %30 = mul i64 %27, %indvar %scevgep = getelementptr double, double addrspace(13)* %29, i64 %30 %31 = add i64 %30, 100 %scevgep11 = getelementptr double, double addrspace(13)* %29, i64 %31 %32 = mul i64 %13, %indvar %33 = mul i64 %20, %indvar %34 = add nsw i64 %value_phi, -1 %35 = mul i64 %13, %34 %36 = mul i64 %20, %34 %37 = mul i64 %27, %34 %38 = add i64 %33, 100 %scevgep19 = getelementptr double, double addrspace(13)* %22, i64 %38 %scevgep17 = getelementptr double, double addrspace(13)* %22, i64 %33 %39 = add i64 %32, 100 %scevgep15 = getelementptr double, double addrspace(13)* %15, i64 %39 %scevgep13 = getelementptr double, double addrspace(13)* %15, i64 %32 %bound0 = icmp ult double addrspace(13)* %scevgep, %scevgep15 %bound1 = icmp ult double addrspace(13)* %scevgep13, %scevgep11 %found.conflict = and i1 %bound0, %bound1 %bound021 = icmp ult double addrspace(13)* %scevgep, %scevgep19 %bound122 = icmp ult double addrspace(13)* %scevgep17, %scevgep11 %found.conflict23 = and i1 %bound021, %bound122 %conflict.rdx = or i1 %found.conflict, %found.conflict23 br i1 %conflict.rdx, label %scalar.ph, label %vector.ph vector.ph: ; preds = %L2 br label %vector.body vector.body: ; preds = %vector.body, % vector.ph %index = phi i64 [ 0, %vector.ph ], [ %index.next, %vector.body ] %offset.idx = or i64 %index, 1 ; @ none:3 within `inner_noalloc_ib!' ; ┌ @ array.jl:730 within `getindex' %40 = add nsw i64 %offset.idx, -1 %41 = add i64 %40, %35 %42 = getelementptr inbounds double, double addrspace(13)* %15, i64 %41 %43 = bitcast double addrspace(13)* %42 to <4 x double> addrspace(13)* %wide.load = load <4 x double>, <4 x double> addrspace(13)* %43, align 8 %44 = add i64 %40, %36 %45 = getelementptr inbounds double, double addrspace(13)* %22, i64 %44 %46 = bitcast double addrspace(13)* %45 to <4 x double> addrspace(13)* %wide.load24 = load <4 x double>, <4 x double> addrspace(13)* %46, align 8 ; └ ; ┌ @ float.jl:395 within `+' %47 = fadd <4 x double> %wide.load, %wide.load24 ; └ ; @ none:4 within `inner_noalloc_ib!' ; ┌ @ array.jl:769 within `setindex!' %48 = add i64 %40, %37 %49 = getelementptr inbounds double, double addrspace(13)* %29, i64 %48 %50 = bitcast double addrspace(13)* %49 to <4 x double> addrspace(13)* store <4 x double> %47, <4 x double> addrspace(13)* %50, align 8 %index.next = add i64 %index, 4 %51 = icmp eq i64 %index.next, 100 br i1 %51, label %L25, label %vector.body scalar.ph: ; preds = %L2 ; └ ; @ none:2 within `inner_noalloc_ib!' br label %L5 L5: ; preds = %L5, %scalar.ph %value_phi2 = phi i64 [ 1, %scalar.ph ], [ %63, %L5 ] ; @ none:3 within `inner_noalloc_ib!' ; ┌ @ array.jl:730 within `getindex' %52 = add nsw i64 %value_phi2, -1 %53 = add i64 %52, %35 %54 = getelementptr inbounds double, double addrspace(13)* %15, i64 %53 %55 = load double, double addrspace(13)* %54, align 8 %56 = add i64 %52, %36 %57 = getelementptr inbounds double, double addrspace(13)* %22, i64 %56 %58 = load double, double addrspace(13)* %57, align 8 ; └ ; ┌ @ float.jl:395 within `+' %59 = fadd double %55, %58 ; └ ; @ none:4 within `inner_noalloc_ib!' ; ┌ @ array.jl:769 within `setindex!' %60 = add i64 %52, %37 %61 = getelementptr inbounds double, double addrspace(13)* %29, i64 %60 store double %59, double addrspace(13)* %61, align 8 ; └ ; ┌ @ range.jl:594 within `iterate' ; │┌ @ promotion.jl:403 within `==' %62 = icmp eq i64 %value_phi2, 100 ; │└ ; │ @ range.jl:595 within `iterate' ; │┌ @ int.jl:53 within `+' %63 = add nuw nsw i64 %value_phi2, 1 ; └└ br i1 %62, label %L25, label %L5 L25: ; preds = %vector.body, % L5 ; ┌ @ range.jl:594 within `iterate' ; │┌ @ promotion.jl:403 within `==' %64 = icmp eq i64 %value_phi, 100 ; │└ ; │ @ range.jl:595 within `iterate' ; │┌ @ int.jl:53 within `+' %65 = add nuw nsw i64 %value_phi, 1 ; └└ %indvar.next = add i64 %indvar, 1 br i1 %64, label %L36, label %L2 L36: ; preds = %L25 ret %jl_value_t addrspace(10)* addrspacecast (%jl_value_t* inttoptr (i64 87752712 to %jl_value_t*) to %jl_value_t addrspace(10)*) }

If you look closely, you will see things like:

```
%wide.load24 = load <4 x double>, <4 x double> addrspac(13)* %46, align 8
; └
; ┌ @ float.jl:395 within `+'
%47 = fadd <4 x double> %wide.load, %wide.load24
```

What this is saying is that it's loading and adding 4 `Float64`

s at a time! This feature of the processor is known as SIMD: single input multiple data. If certain primitive floating point operations, like `+`

and `*`

, are done in succession (i.e. no inbounds checks between them!), then the processor can lump them together and do multiples at once. Since clock cycles have stopped improving while transistors have gotten smaller, this "lumping" has been a big source of speedups in computational mathematics even though the actual `+`

and `*`

hasn't gotten faster. Thus to get full speed we want to make sure this is utilized whenever possible, which essentially just amounts to doing type inferred loops with no branches or bounds checks in the way.

Modern processors have a single operation that fuses the multiplication and the addition in the operation `x*y+z`

, known as a *fused multiply-add* or FMA. Note that FMA has less floating point roundoff error than the two operation form. We can see this intrinsic in the resulting LLVM IR:

@code_llvm fma(2.0,5.0,3.0)

; @ floatfuncs.jl:319 within `fma' ; Function Attrs: uwtable define double @julia_fma_15823(double, double, double) #0 { top: ; ┌ @ floatfuncs.jl:308 within `fma_llvm' %3 = call double @llvm.fma.f64(double %0, double %1, double %2) ; └ ret double %3 }

The Julia function `muladd`

will automatically choose between FMA and the original form depending on the availability of the routine in the processor. The MuladdMacro.jl package has a macro `@muladd`

which pulls apart statements to add `muladd`

expressions. For example, `x1*y1 + x2*y2 + x3*y3`

can be rewritten as:

`muladd(x1,y1,muladd(x2,y2,x3*y3))`

Which reduces the linear combination to just 3 arithmetic operations. FMA operations can be SIMD'd.

All of this would go to waste if function call costs of 50 clock cycles were interrupting every single `+`

. Fortunately these function calls disappear during the compilation process due to what's known as inlining. Essentially, if the function call is determined to be "cheap enough", the actual function call is removed and the code is basically pasted into the function caller. We can force a function call to occur by teling it to not inline:

@noinline fnoinline(x,y) = x + y finline(x,y) = x + y # Can add @inline, but this is automatic here function qinline(x,y) a = 4 b = 2 c = finline(x,a) d = finline(b,c) finline(d,y) end function qnoinline(x,y) a = 4 b = 2 c = fnoinline(x,a) d = fnoinline(b,c) fnoinline(d,y) end

qnoinline (generic function with 1 method)

@code_llvm qinline(1.0,2.0)

; @ none:2 within `qinline' ; Function Attrs: uwtable define double @julia_qinline_15824(double, double) #0 { top: ; @ none:4 within `qinline' ; ┌ @ none:1 within `finline' ; │┌ @ promotion.jl:313 within `+' @ float.jl:395 %2 = fadd double %0, 4.000000e+00 ; └└ ; @ none:5 within `qinline' ; ┌ @ none:1 within `finline' ; │┌ @ promotion.jl:313 within `+' @ float.jl:395 %3 = fadd double %2, 2.000000e+00 ; └└ ; @ none:6 within `qinline' ; ┌ @ none:1 within `finline' ; │┌ @ float.jl:395 within `+' %4 = fadd double %3, %1 ; └└ ret double %4 }

@code_llvm qnoinline(1.0,2.0)

; @ none:2 within `qnoinline' ; Function Attrs: uwtable define double @julia_qnoinline_15825(double, double) #0 { top: ; @ none:4 within `qnoinline' %2 = call double @julia_fnoinline_15826(double %0, i64 4) ; @ none:5 within `qnoinline' %3 = call double @julia_fnoinline_15827(i64 2, double %2) ; @ none:6 within `qnoinline' %4 = call double @julia_fnoinline_15828(double %3, double %1) ret double %4 }

We can see now that it keeps the function calls:

`%4 = call double @julia_fnoinline_21538(double %3, double %1)`

and this is slower in comparison to what we had before (but it still infers).

x = 1.0 y = 2.0 @btime qinline(x,y)

16.015 ns (1 allocation: 16 bytes) 9.0

@btime qnoinline(x,y)

19.338 ns (1 allocation: 16 bytes) 9.0

Note that if we ever want to go the other direction and tell Julia to inline as much as possible, one can use the macro `@inline`

.

Scalar operations are super cheap, and if they are cache-aligned then more than one will occur in a clock cycle.

Inlining a function will remove the high function call overhead.

Branch prediction is pretty good these days, so keep them out of super tight inner loops but don't worry all too much about them.

Cache misses are quite expensive the futher out it goes.

Julia's compiler is smart. This means that if you don't try hard enough, Julia's compiler might get rid of your issues. For example, it can delete branches and directly compute the result if all of the values are known at compile time. So be very careful when benchmarking: your tests may have just compiled away!

Notice the following:

@btime qinline(1.0,2.0)

0.001 ns (0 allocations: 0 bytes) 9.0

Dang, that's much faster! But if you look into it, Julia's compiler is actually "cheating" on this benchmark:

cheat() = qinline(1.0,2.0) @code_llvm cheat()

; @ none:1 within `cheat' ; Function Attrs: uwtable define double @julia_cheat_15878() #0 { top: ret double 9.000000e+00 }

It realized that `1.0`

and `2.0`

are constants, so it did what's known as *constant propogation*, and then used those constants inside of the function. It realized that the solution is always `9`

, so it compiled the function that... spits out `9`

! So it's fast because it's not computing anything. So be very careful about propogation of constants and literals. In general this is a very helpful feature, but when benchmarking this can cause some weird behavior. If a micro benchmark is taking less than a nanosecond, check and see if the compiler "fixed" your code!

Optimize your serial code before you parallelize. There's a lot to think about.

Here's a few discussion questions to think about performance engineering in scientific tasks:

What are the advantages of a

`Vector{Array}`

vs a`Matrix`

? What are the disadvantage? (What's different?)What is a good way to implement a data frame?

What are some good things that come out of generic functions for free? What are some things you should watch out for with generic functions?