All the different implementations are compared on the same condition: same n, same compiler and same machine.
> are you aware that Blas uses Fortran
Wrong. uBLAS and Eigen are written purely in C++. OpenBLAS is a mixture of C and ASM. They have nothing to do with Fortran.
> you have also added debugging flags to the compilers further slowing the BLAS routines with more debugging cruft!?
By debugging flags, you mean "-g"? No, -g should not affect the performance (maybe a tiny bit on loading the executable, but that is negligible). Get rid of -g, and you will get essentially the same result.
> you dare use the word "primitive"
Yes, I dare, because uBLAS is just that bad and should be trashed. Prove me wrong with your benchmarks. Let number speak for itself.
1. too many indepedent variables: comparing two different compilers on two different platforms on two different architectures?!!
2. and then you compare performances without equal consideration of the problem size for n!
your conclusions are premature, sir, your analysis is conjecture and yet you dare use the word "primitive". for instance, are you aware that Blas uses Fortran whose lack of pointer aliasing effects in memory could be causing the disparity here? have you considered that certain interprocedural optimizations have been affected by not having seperate translation units for your tests?! you have also added debugging flags to the compilers further slowing the BLAS routines with more debugging cruft!?! gah!
for these reasons above and the flaunted use of architecture specific intrinsics, your post stands accused! make revisions and then also see how blas performs using a better algorithm with possibly fewer aliasing effects
see http://m.mathnet.ru/php/archive.phtml?wshow=paper&jrnid=zvmm...
begone from this thread! use proper profiling tools. learn c! fix this violence to science and injustice!!!