3 ms·

Getting the theoretical peak performance requires either extensive manual tuning on each architecture or exhaustive search. To read on the former see http://www

Getting the theoretical peak performance requires either extensive manual tuning on each architecture or exhaustive search. To read on the former see http://www.nytimes.com/2005/11/28/technology/28super.html?pagewanted=all http://www.nytimes.com/2005/11/28/technology/28super.html?pa..., and the latter is done for example in the ATLAS BLAS. It is important to note that the SO discussion is focused on achieving peak flops when the data is already in the XMM registers. The real bottleneck is pushing the data quickly through the levels of the memory hierarchy.

iskander 14y ago
>extensive manual tuning I was surprised by how little low-level knowledge it took to get within a stone's throw of the theoretical peak. The general rule seems to be: - keep data in packed registers (use YMM instead of XMM if you have them) - interleave addition and multiplication - unroll the loop sufficiently to avoid stalls I wonder if how close to ATLAS you could get if you wrote a matrix multiply following these principles and additionally structured the row/column iterations into cache-sized tiles.
montecarl 14y ago
Its worth noting that ATLAS is actually pretty terrible compared to hand written BLAS. Figure 2 and 3 in this paper (http://cran.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf http://cran.r-project.org/web/packages/gcbd/vignettes/gcbd.p...) show atlas is only better than an unoptimized ("reference") BLAS implementation and that it is many times slower than the winner GotoBLAS (now OpenBLAS http://xianyi.github.com/OpenBLAS/ http://xianyi.github.com/OpenBLAS/), which is written assembly by Kazushige Goto while he worked at the Texas Advanced Computing Center. Edit: Article in the NY Times about Mr. Goto http://www.nytimes.com/2005/11/28/technology/28super.html?scp=1&sq=Kazushige%20Goto&st=cse&_r=0 http://www.nytimes.com/2005/11/28/technology/28super.html?sc...

iskander 14y ago

>extensive manual tuning I was surprised by how little low-level knowledge it took to get within a stone's throw of the theoretical peak. The general rule seems to be: - keep data in packed registers (use YMM instead of XMM if you have them) - interleave addition and multiplication - unroll the loop sufficiently to avoid stalls I wonder if how close to ATLAS you could get if you wrote a matrix multiply following these principles and additionally structured the row/column iterations into cache-sized tiles.

montecarl 14y ago

Its worth noting that ATLAS is actually pretty terrible compared to hand written BLAS. Figure 2 and 3 in this paper (http://cran.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf http://cran.r-project.org/web/packages/gcbd/vignettes/gcbd.p...) show atlas is only better than an unoptimized ("reference") BLAS implementation and that it is many times slower than the winner GotoBLAS (now OpenBLAS http://xianyi.github.com/OpenBLAS/ http://xianyi.github.com/OpenBLAS/), which is written assembly by Kazushige Goto while he worked at the Texas Advanced Computing Center. Edit: Article in the NY Times about Mr. Goto http://www.nytimes.com/2005/11/28/technology/28super.html?scp=1&sq=Kazushige%20Goto&st=cse&_r=0 http://www.nytimes.com/2005/11/28/technology/28super.html?sc...