JuliaSIMD / JuliaSIMD/LoopVectorization.jl

Plot against theoretical peak performance

Aperta
#355 23 commenti 0 reazioni 0 assegnatari Vedi su GitHub
Lingua principale
Julia
Stelle
789
Fork
73
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Descrizione

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.

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Valutazione

Questa issue non Γ¨ ancora stata valutata.

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.