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.
I grew up in Spain close to the border with Portugal, so even though I don't speak the language (something which I really regret) I am familiar with it. What are the major differences between European and Brazilian Portuguese? I only know that Brazilians use the gerund like us Spanish speakers, whereas European Portuguese uses "estar a" + infinitive.
Spelling used to be a big one. E.g. in the opening sentence of the article, the word "otimização" would've been an obvious sign it was Brazilian, because the usual European Portuguese spelling was "optimização" — we had a bunch of silent consonants like that all over the place, but most of those got removed once Portugal started adopting the 1990 orthographic agreement[0]. Speaking of spelling differences, now that I'm re-reading, I could've noticed it was Brazilian from "ingênua" in the first section (would've been "ingénua" in European 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.
What is interesting here is that this is an optimization study, whose goal was to determine the optimum implementation variant for matrix multiplication on a Zen 3 CPU.
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.
Zen3 isn't the best performing CPU today, though of course it'll never approach GPU level (which is pretty much ASIC level for matrix muls with special units). CPUs are getting dedicated "AI accelerators" too so it'd be interesting to compare per watt. The real limit is almost certainly memory bandwidth, not flops.
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.
Matrix multiplication is one of the few operations that isn't regularly limited by memory bandwidth. BLAS implementations come with several heavily optimized, architecture-specific versions of sgemm.
Well, it does rely on decomposing the problem to optimize cache efficiency.
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.
The throughput quoted here is for a single core, and it is not reported any attempt to measure how well this scales to all cores.
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.
Pushing the Limits of AMD Zen 3: Achieving 85.3 GFLOPS on a Single Core! I recently took on the challenge of squeezing every drop of performance out of a single AMD Zen 3 core, successfully reaching a blazing-fast 85.3 GFLOPS in FP32 matrix multiplication. By diving deep into low-level software optimization—focusing on advanced SIMD vectorization, strict cache management, and instruction pipelining—I managed to maximize CPU efficiency without relying on multi-threading. This project serves as a powerful proof of concept for high-performance computing (HPC) enthusiasts, proving that deeply optimized code can still unlock incredible hidden potential in modern silicon.
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.