8 ms·

No matter which language you use, you will not beat Intel MKL because that code is optimized by Intel specifically for each architecture. Precisely because auto

No matter which language you use, you will not beat Intel MKL because that code is optimized by Intel specifically for each architecture. Precisely because automatic optimization by compilers is not good enough. These comparisons are completely irrelevant. Incidentally, this also shows why pursuing the goal of a "fast" numerical computing language is a waste of time: the speed derives from using the appropriate hardware vendor libraries, not from the language runtime.

egocodedinsol 13y ago
I'm confused: Matlab uses MKL, Armadillo can be configured to work with MKL if you have it, and Julia supports MKL, and NumPy too. So if everything uses the same hardware vendor libraries, I'm not sure if that's where your actual speedup will come from. Also, MKL syntax itself is not particularly fun compared with Matlab/NumPy/Julia/etc.
- rrrrtttt 13y ago
  Once your language allows you to use MKL and its equivalents, your code will use every arithmetic unit of the CPU in almost every cycle and therefore performance-wise there is no difference which language it is. So it's all down to which language offers you better library support and nicer syntax.
  - egocodedinsol 13y ago
    Hmm. If it we're true that speed is independent from language once mkl is installed, wouldn't you expect there to be no observed performance differences? And yet there are large measurable ones for reasonable tasks even with mkl.
jordigh 13y ago
MKL is only optimised for Intel architecture and intentionally pessimised for any non-Intel architecture. Oh, sure they say, "well, we don't know the other architecture, so we can't optimise for it," but you know this is full of lies, as if AMD were some obscure architecture that Intel can't possibly know if it supports SSE or not.
stephencanon 13y ago
MKL is not magic. It doesn't use special secret instructions that no one else can use. The Intel engineers who work on it are not genetically-designed evil super optimization geniuses. Hand-optimizing math libraries does not require information that isn't available in Intel's optimization manuals or determinable from simple experiments. It is absolutely possible to beat MKL. There's just not much reason for most people to bother doing so, when MKL (and other competing libraries) are already available for them to use. All of the "modern" numerical computing environments can use whatever BLAS and FFT (and ...) libraries are available on the host system, including MKL. What new languages offer isn't (usually) better execution speed (though there's still plenty that can be done with optimizing evaluation of linear algebra expressions at a high level), it's faster and more pleasant development of numerical codes.
StefanKarpinski 13y ago
While it's great having fast kernels, there is a huge amount of computing that can't be crammed into a matrix multiply or any other high-performance kernel. If your assertion were even remotely true, there wouldn't be so many Python, Matlab and R extensions written in C, and things like Cython [1] and Numba [2] wouldn't exist. Sometimes you just want to write a for loop or use recursion and not have it be dog slow. Being "allowed" to use iteration and recursion without a performance penalty is one of the things that Julia provides. As to not being able to beat MKL, it isn't even necessarily hands down the best BLAS around. For example, OpenBLAS [3] is about as good as MKL, depending on what you're doing. They each have their strengths and weaknesses: 1. OpenBLAS is faster than MKL in all the level-1 tests for small numbers of threads (1-4). The difference is larger for smaller problems. In small level-2 and level-3 instances, however, MKL does better. Specifically in the case of matrix-vector products, MKL seems to do much better. 2. On various linear algebra tests with LAPACK, MKL is faster for smaller problem sizes, whereas OpenBLAS is faster for larger problems. 3. In general, MKL seems to have better tuning for threads. OpenBLAS, on the other hand, has optimized kernels for LU and Cholesky factorizations, which is what GotoBLAS [4] – on which OpenBLAS is based – did too. Blake Johnson, who is a regular Julia contributor, did an excellent analysis of this, complete with pretty Gadfly-generated graphs, which can be found in the discussion of this issue: https://github.com/JuliaLang/julia/issues/3965 https://github.com/JuliaLang/julia/issues/3965. Interestingly, I believe that Kazushige Goto, who originally created GotoBLAS, now works on MKL at Intel. [1] http://cython.org http://cython.org [2] http://numba.pydata.org http://numba.pydata.org [3] https://github.com/xianyi/OpenBLAS https://github.com/xianyi/OpenBLAS [4] http://en.wikipedia.org/wiki/GotoBLAS http://en.wikipedia.org/wiki/GotoBLAS

egocodedinsol 13y ago

I'm confused: Matlab uses MKL, Armadillo can be configured to work with MKL if you have it, and Julia supports MKL, and NumPy too. So if everything uses the same hardware vendor libraries, I'm not sure if that's where your actual speedup will come from. Also, MKL syntax itself is not particularly fun compared with Matlab/NumPy/Julia/etc.

rrrrtttt 13y ago
Once your language allows you to use MKL and its equivalents, your code will use every arithmetic unit of the CPU in almost every cycle and therefore performance-wise there is no difference which language it is. So it's all down to which language offers you better library support and nicer syntax.
- egocodedinsol 13y ago
  Hmm. If it we're true that speed is independent from language once mkl is installed, wouldn't you expect there to be no observed performance differences? And yet there are large measurable ones for reasonable tasks even with mkl.

jordigh 13y ago

MKL is only optimised for Intel architecture and intentionally pessimised for any non-Intel architecture. Oh, sure they say, "well, we don't know the other architecture, so we can't optimise for it," but you know this is full of lies, as if AMD were some obscure architecture that Intel can't possibly know if it supports SSE or not.

stephencanon 13y ago

MKL is not magic. It doesn't use special secret instructions that no one else can use. The Intel engineers who work on it are not genetically-designed evil super optimization geniuses. Hand-optimizing math libraries does not require information that isn't available in Intel's optimization manuals or determinable from simple experiments. It is absolutely possible to beat MKL. There's just not much reason for most people to bother doing so, when MKL (and other competing libraries) are already available for them to use. All of the "modern" numerical computing environments can use whatever BLAS and FFT (and ...) libraries are available on the host system, including MKL. What new languages offer isn't (usually) better execution speed (though there's still plenty that can be done with optimizing evaluation of linear algebra expressions at a high level), it's faster and more pleasant development of numerical codes.

StefanKarpinski 13y ago

While it's great having fast kernels, there is a huge amount of computing that can't be crammed into a matrix multiply or any other high-performance kernel. If your assertion were even remotely true, there wouldn't be so many Python, Matlab and R extensions written in C, and things like Cython [1] and Numba [2] wouldn't exist. Sometimes you just want to write a for loop or use recursion and not have it be dog slow. Being "allowed" to use iteration and recursion without a performance penalty is one of the things that Julia provides. As to not being able to beat MKL, it isn't even necessarily hands down the best BLAS around. For example, OpenBLAS [3] is about as good as MKL, depending on what you're doing. They each have their strengths and weaknesses: 1. OpenBLAS is faster than MKL in all the level-1 tests for small numbers of threads (1-4). The difference is larger for smaller problems. In small level-2 and level-3 instances, however, MKL does better. Specifically in the case of matrix-vector products, MKL seems to do much better. 2. On various linear algebra tests with LAPACK, MKL is faster for smaller problem sizes, whereas OpenBLAS is faster for larger problems. 3. In general, MKL seems to have better tuning for threads. OpenBLAS, on the other hand, has optimized kernels for LU and Cholesky factorizations, which is what GotoBLAS [4] – on which OpenBLAS is based – did too. Blake Johnson, who is a regular Julia contributor, did an excellent analysis of this, complete with pretty Gadfly-generated graphs, which can be found in the discussion of this issue: https://github.com/JuliaLang/julia/issues/3965 https://github.com/JuliaLang/julia/issues/3965. Interestingly, I believe that Kazushige Goto, who originally created GotoBLAS, now works on MKL at Intel. [1] http://cython.org http://cython.org [2] http://numba.pydata.org http://numba.pydata.org [3] https://github.com/xianyi/OpenBLAS https://github.com/xianyi/OpenBLAS [4] http://en.wikipedia.org/wiki/GotoBLAS http://en.wikipedia.org/wiki/GotoBLAS