JuliaSIMD / JuliaSIMD/LoopVectorization.jl

Plot against theoretical peak performance

Open
#355 23 comments 0 reactions 0 assignees View on GitHub
Dominant language
Julia
Stars
789
Forks
73
PR merge metrics
No merged PRs in 30d

Description

I started with these plots:

https://juliasimd.github.io/LoopVectorization.jl/stable/examples/matrix_vector_ops/

The issue is that I can't tell from the plot if the performance is already the best you can do, or if there is still room for improvement. To answer that question, I like to plot clock cycles (per loop body / array element) on the vertical axis, and also plot the theoretical performance peak into the same graph. Let's do that for the very first benchmark:
```console
julia> function jgemvavx!(𝐲, 𝐀, 𝐱)
@turbo for i ∈ eachindex(𝐲)
𝐲i = zero(eltype(𝐲))
for j ∈ eachindex(𝐱)
𝐲i += 𝐀[i,j] * 𝐱[j]
end
𝐲[i] = 𝐲i
end
end
jgemvavx! (generic function with 1 method)

julia> N = 64
64

julia> y = rand(N);

julia> A = rand(N, N);

julia> x = rand(N);

julia> @benchmark jgemvavx!(y, A, x)
BenchmarkTools.Trial: 10000 samples with 199 evaluations.
Range (min … max): 427.970 ns … 610.970 ns β”Š GC (min … max): 0.00% … 0.00%
Time (median): 428.603 ns β”Š GC (median): 0.00%
Time (mean Β± Οƒ): 430.210 ns Β± 9.385 ns β”Š GC (mean Β± Οƒ): 0.00% Β± 0.00%

β–‡β–ˆβ–…β– β–ƒ β–‚
β–ˆβ–ˆβ–ˆβ–ˆβ–…β–„β–„β–„β–ƒβ–„β–…β–„β–…β–…β–…β–…β–†β–„β–…β–„β–ƒβ–β–ƒβ–ˆβ–ˆβ–ˆβ–‡β–†β–„β–β–„β–β–„β–β–„β–„β–„β–…β–…β–…β–†β–‡β–…β–ƒβ–„β–β–β–ƒβ–β–β–β–β–β–β–β–ƒβ–β–…β–…β–…β–… β–ˆ
428 ns Histogram: log(frequency) by time 463 ns <

Memory estimate: 0 bytes, allocs estimate: 0.

julia> cpu_freq = 3.2e9 # Ghz
3.2e9

julia> 427.136e-9 * cpu_freq / N^2
0.3337
```

So for `N=64`, using double precision, it seems the body of the loop takes 0.333 clock cycles.

I use Apple M1. I installed the macOS Julia, I assume that is Intel based? Somehow it works for me.

Regarding the theoretical peak, the loop body is just:
```julia
𝐲i += 𝐀[i,j] * 𝐱[j]
```
Everything else I think gets amortized. So it is two memory reads from L1 cache, each takes 0.1665 clock cycles (`ldr q0, [x1]` takes 0.333). And one fma, which takes 0.125 (`fmla.2d v0, v0, v0` takes 0.25). The bottleneck in this case is the memory read, total of 0.333 clock cycles. The fma runs at the same time, so we do not include it.

So according to my analysis, the code runs at 100% of the theoretical peak. Which sounds too good to be true. I am worried I made some mistake in my analysis somewhere. But I am posting what I have so far.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.