1

2

如果是 intel 平台，可以考虑使用 Intel Intrinsics Library ，会比 OpenBLAS 快不少。

5

@elfive #2 什么库不重要, 主要是想自己优化 gemm 来学习一下. 实际项目中会都测试一边选性能最好的用的.

6

@nagisaushio 这个确实有一些帮助, 不过只能提升一点点大概 0.1GFLOPS 吧, 还是和 openblas, blis 这些有断档的差距. 感觉更多还是算法设计方面的问题, 这部分不知道该怎么做了.

7

@AirCrusher 谢谢分享, 这个有点猛汇编都用上了, 我回头看下. 其实后面我看过类似的就是 flame 的教程, 基本上里面的技术都应用到了已经.

8

歪个楼，请问你 README 的矩阵图是用什么画的？

11

可以看看这篇文章 里面讲了 cpu 矩阵乘的优化 https://justine.lol/matmul/

12

@WonderfulRush
刚看完这篇文章然后看到你的评论...
那个文章挺好的, 但是技术部分讲得有点简略, 而且其实很多提到的技术我已经用了, 比如 blocking, simd 等等.

14

我感觉你取 index 就做了不少乘法，不确定编译器能不能帮你优化掉，你自己把 index 改成累加的方式试试

16

@tankeco
是的, 这点我也觉得要花时间想下怎么减少 index.
其实已经优化过一次 index 了, 现在保留的都是为了分块和区分多线程访问空间的, 后面个人感觉这不是影响速度的最大的因素就没继续花心思了.

18

对比 openblas 中 cblas_sgemm 也是 4 并行度的吗？

19

几个小建议和疑问：
1 先大致理论分析下最大能够达到的 GFLOS 是多少（考虑 CPU 多 port 都可以执行运算）；
2 先用单线程跑到最高速率，排除多线程调度或资源竞争导致的劣化；
3 尝试加上预取指令，perf 看看瓶颈在哪里
4 测试多次，取最优值，看你测试了一次，都会有“冷启动”的问题。
5 omp parallel for schedule(static) 是在编译时就确定代码位于哪个线程了吗，会导致 cache 相关问题吗（ false sharing ）

21

@foool #19
非常感谢你的回复.
1. 最大 GFLOPS 这个我没算, 是以 openblas 的为目标优化的 (试过别的库, 有比 openblas 更快的).
2. 3. 很好的建议, 我回头再优化测试看看.
4. 我是脚本跑 100 次取最优值的.
5. 使用 schedule(static)是因为 for 循环中每次计算量近似才用的, 不过我试过去掉这个, 其实性能基本没区别.

22

@dingyaguang117
你是说它们不是传统的 C=AB, 而是用了 Strassen/Winograd 之类的方法减少了复杂度吗?

23

@Avafly 不确定 openblas 是否用到了 Strassen/Winograd 算法，感觉想要追求更显著突破可能是需要换算法的

25

@Avafly 不熟悉你这个问题的背景，但是矩阵乘法本身现在已经能做到 O(n^2.37)左右了。比较实用、常数没那么大的也有 O(n^2.8)左右的算法。

26

@Avafly 就是你说的 Strassen/Winograd