Funnily enough, it took me a while to determine it was definitely Brazilian Portuguese, given I'm a native Portuguese speaker, because the whole thing is written in a stiff academic-ish style that hides some the differences between European and Brazilian Portuguese.
A common pattern in the readme is the use of "em um" ("in/on a" in English), which is idiomatic in Brazilian, but not in European Portuguese, where the contraction "num" would be standard. It's one of the cases that could be attributed to overly stiff academic writing, though.
0. https://en.wikipedia.org/wiki/Portuguese-Language_Orthograph...
Try selecting some text in the README, and right-clicking then "Translate to ..." and the autodetect might do a bit better to identify the language.
It is likely that a similar optimization strategy would work for a modern Zen 5, though some of the parameters for the optimum variant would probably have double values, because Zen 5 has twice more registers, each double in size, and it can process and transfer a double number of FP32 per clock cycle.
The value given by the author of 63.5% of the theoretical maximum throughput, is likely to be pessimistic, because when doing heavy computations the clock frequency of the CPU will drop, so the actual efficiency might be higher, e.g. perhaps of 70% to 80% of the theoretical maximum throughput at that clock frequency.
The ATLAS BLAS-compatible library attempted to perform automatically such an optimization for its host computer, but I have not studied it to see whether its optimization methods would still work on modern CPUs with AVX+FMA or with AVX-512.
It would also be very interesting to see someone like Fabien Giesen / ryg do a maxed out AVX512 version for Zen5. His code's so fast it makes Intel 13900k's self destruct.
I don't read Portuguese, but the tables of results seem to imply they are tuning block sizes that leverage the L3 cache. They also talk about prefetch, which tends to matter more as you are approaching a streaming pattern.
So, a single core result may not scale linearly for multicore, given that there will be some cache contention, right? It's a very different tuning problem to optimize each of N cores to use its 1/N fraction of cache while sharing the available bandwidth for cache misses.
A modern Zen 5 should reach a throughput more than twice this value per core, with a total over 3 TFLOP/s for the complete CPU.
That 100 TFLOP/s for FP32 is for a GPU that might cost from 30 to 100 times more than a desktop CPU, so it is not certain that its performance per dollar is any better than for the desktop CPU.
This is very different from 7 to 10 years ago, when GPUs had a far higher performance per dollar than any CPUs. Since then, the performance per dollar of the desktop CPUs has increased, mainly because their prices have not increased much, while the performance per dollar of the GPUs has decreased, mainly because of a great increase in their prices, especially for the "datacenter" GPUs, which now may be more than 10 times more expensive than they were 7 years ago.