Fix performance plot in README.md

[sloede]

I was reading up on Octavian.jl in the README.md, being happy about the great performance this package delivers. However, I was taken aback when I looked at the performance plot, specifically the red graph:

😱 According to this, Octavian has by far the worst performance for any matrix size. However, I assume that this is due to a random documentation/plotting snafu, thus this issue.

[chriselrod]

Ha ha, yes, I uploaded the wrong plot!
#88

Once upon a time, that plot was correct:
#24 (comment)

I improved PaddedMatrice's implementation a lot since then (particularly for smaller matrices), and ultimately moved it here, to Octavian.

Note that the benchmark code I ran said logspace(10, 1000, 200), i.e. 200 sizes from 10 to 1000.
But I accidentally copied the above plot from 10 to 10_000.

[sloede]

What happened to the results up to 10,000? Why are those not shown anymore? IIRC, there were some interesting performance degradations visible for some implementations for larger sizes.

[chriselrod]

I can run it through 10_000 next time I go to bed.

Although I'm also working on a tilemajor PR that should theoretically improve performance at large sizes.
I'm not confident it will, but I'll merge it if it does and then run larger-size benchmarks.

Here is a benchmark from January 20th going from 100-10_000:

It'd be great if I could match MKL, at least on (7-10)980XEs. The above was done with a 7980XE, while the README plot was done with a 10980XE. The chips are more or less the same, except the 10980XE has a higher clock speed (and supports some deep learning instructions that don't get used here).

[sloede]

OK, thanks! I was just wondering because I thought it was interesting to see how the behavior is qualitatively different in different size regimes.

[chriselrod]

True, I really should extend it to 10_000.

Octavian switches what it does based on the sizes of the matrices. On these computers, the last change in algorithm is around the 1700 x 1700 IIRC, so it'd be good to show that asymptotic performance.

It's around that point where the matrix B in C = A * B no longer fits in the L3 cache, which is why Octavian switches its approach.
Gaius, Tullio, and LoopVectorization do not, which is why their performance begins to suffer. LoopVectorization doesn't change its approach / handle caching at all (yet), which is why it starts to suffer much sooner than the others. It'd hit rock bottom by 10_000 x 10_000.

Proper BLAS libraries like OpenBLAS, MKL, and BLIS of course do the right thing, so they maintain/gain performance asymptotically.

You'll see the performance degradation much sooner on computers with smaller caches and fewer cores.