我有一些代码使用LAPACK例程DPPTRF，DPPTRI和DSPMV执行打包对称矩阵求逆和乘法。 Here是一个较旧的主题，您可以在其中看到我用来调用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将此lib链接到我的C ++应用程序。
然后我尝试使用GotoBLAS2。我是从here得到的。该软件包包含自动编译大量19MB静态库的脚本。通过链接它可以很好地利用我现有的代码：-lgoto2_nehalemp-r1.13。
我觉得这开始很顺利。使用GotoBLAS2，在大型问题集（反转1000x1000或更大的矩阵）上，我看到了大约6倍的性能提升。由于GotoBLAS是我的架构和参考LAPACK的线程是单线程的，我认为这是合理的。系统监视器还显示> 300％的CPU使用率来证实。
这是奇怪的地方。我想，如果我优化参考实现怎么办？
我重新编译我的lapack_lite lib，如下所示：gfortran -c -O3 *.f
即使在3200x3200矩阵反转上，我的lapack_lite lib现在优于GotoBLAS2，仅使用一个线程。它还消耗大约80MB的RAM。
然而，随后的压缩矩阵向量乘法确实更快地发生了GotoBLAS。
这怎么可能远程可能？ GotoBLAS包的make配置是否无法使用gfortran的优化开关？