我有一些代码使用 LAPACK 例程DPPTRF、DPPTRI和DSPMV. 这是一个较旧的主题，您可以在其中看到我用来调用 LAPACK 例程的 C++ 代码。
我的代码目前组装了一个对称矩阵，该矩阵主要沿对角线填充。
我正在测试不同的 BLAS 和 LAPACK 实现，并将 GotoBLAS2 与 netlib 中的参考 LAPACK 实现进行比较。
下面是我如何编译 netlib LAPACK 代码。我.f从源代码中选择代码文件，并将它们全部编译成一个紧凑的静态库，如下所示：
$ ls
ddot.f dpptrf.f dscal.f dspr.f dtpsv.f lsame.f
dgemm.f dpptri.f dspmv.f dtpmv.f dtptri.f xerbla.f
$ gfortran -c *.f
$ ar rcs liblapack_lite.a *.o
然后我可以使用-llapack_lite -lgfortran.
然后我尝试使用 GotoBLAS2。我从这里得到的。该软件包包含自动编译大量 19MB 静态库的脚本。通过链接它可以很好地与我现有的代码配合使用：-lgoto2_nehalemp-r1.13 .
一开始我觉得这很顺利。使用 GotoBLAS2，在大型问题集（反转 1000x1000 或更大的矩阵）上，我看到了大约 6 倍的性能提升。由于 GotoBLAS 是针对我的架构进行线程化的，并且参考 LAPACK 是单线程的，我认为这是合理的。系统监视器还显示 > 300% 的 CPU 使用率来证实。
这就是它变得奇怪的地方。我想，如果我优化参考实现呢？
我像这样重新编译我的 lapack_lite 库：gfortran -c -O3 *.f
即使在 3200x3200 矩阵反转上，我的 lapack_lite 库现在也优于 GotoBLAS2，仅使用一个线程。它还消耗约 80MB 的 RAM。
然而，使用 GotoBLAS 之后的压缩矩阵向量乘法确实发生得更快。
这怎么可能？GotoBLAS 包的 make 配置是否未能使用 gfortran 的优化开关？