|
d****2
发帖数: 6250 | 2
yes. why? you need experts in compiler optimization to make it faster. gcc does
have best front end though.
intel's mkl has a russian team working on it and use some techniques very
specific to x86. |
|
|
l******e
发帖数: 12192 | 4 因为MKL是用来卖钱的，不是用来tweak了show benchmark的。呵呵 |
|
l*****z
发帖数: 2305 | 5 intel mkl (under linux, free) |
|
w***g
发帖数: 5958 | 6 gsl_cblas sucks. you need to replace that with atlas or intel MKL for
serious matrix computations. Otherwise gsl is probably good. |
|
G*****7
发帖数: 1759 | 7 opencv和boost ublas（或者Armadillo )蛮好的，一方面本身比较模板化， Cpp-ish，
另一方
面提供了ipp和mkl的c函数的binding，在性能方面不输太多。 |
|
t*****n
发帖数: 4908 | 8 Eigen c++的矩阵库，效率还不错。跟MKL有的一比。纯头文件，即编即用。 |
|
t*****z
发帖数: 812 | 9 看应用吧。
试试16G大小的矩阵的乘法，光copy来copy去就够你受的
或者试试10000次调用Cublas算32X32的（不同）小矩阵运算，看看cublas快还是mkl快 |
|
L***n
发帖数: 6727 | 10 建议本版搞个不限规则竞赛，java和cpp都允许在源代码上任何级别优化，然后比比运
算速度
mkl快 |
|
t*****n
发帖数: 4908 | 11 没人试一试我写的程序？看来大家都不愿意看代码。我以前给商业软件写slover的时候
，就是用的blas库。MKL也用过。
JAVA就不用提了。目前为止商用有限元软件没有一个是用JAVA写的。Fortran/C/C++是
主流。 |
|
p**o
发帖数: 3409 | 12 Matlab links against MKL (for dense matrices),
which is written in Fortran. |
|
p**o
发帖数: 3409 | 13
表达观点要有论据或论证。我不是做体系结构这块的，说错话、甚至
讲外行话的可能性也有。我在这里把我的依据以及理解稍微展开一下，
希望你反驳的时候言之有据，无论对错大家都能受益。
“广大cpu/memory/cache设计者几个decades以来的努力”，的确为
上层提供了一些必要的intrinsics，但各级I/O策略是具体依赖上层
软件来控制实现的，硬件没有聪明到能自动优化这些。
不要说硬件，就连编译器都很难识别上层的语义做优化。比如GCC，
就连对矩阵indexing的处理都非常笨拙；Intel的ICC/IFC可以向量化
内循环，从而更方便用SSE指令集做优化，但是没有专门对矩阵相关
的各级I/O做优化——这些优化是Intel放在MKL数值库里做的。
我的根据之一是这篇科普文章（文章虽长，但值得每个程序员一读）：
Ulrich Drepper, "What Every Programmer Should Know About Memory"
http://people.freebsd.org/~lstewart/articles/cpumemory.pdf
文章前部讲RAM/cac... 阅读全帖 |
|
L***n
发帖数: 6727 | 14 概念98年就有了，成熟的写到库里这几年才逐渐出现，我知道的有eigen3, mtl4
还有blaze1.0，还有几个小的，都没人维护了
Edit: 错了一点，其实ublas和blitz++应用ET更早，不过这俩一向在各种benchmark
里以路人甲的身份出现。主要起陪衬被吹嘘的各路主角的作用，近一点的这几个库
优化的好一些了。eigen在自己的主页上吹嘘AxA^T能干过mkl，不过搞计算的还没
多少人理他们，现在还属于在自娱自乐的阶段。
c |
|
G*****7
发帖数: 1759 | 15
怀疑
quality varies. boost ublas amasses fanciful template gimmicks but is
sloooow. eigen on the other hand is more performant, because a lot attention
was given to vectorization. however it is still not perfect for the lack of
the kind of openmp multi-threading that an optimized library such as intel
mkl would provide. |
|
G*****7
发帖数: 1759 | 16
*blitz++
hardly surprising. they lack sse vectorization.
read the small print. it's single-threaded iirc.
and i guess that's why hi-perf computing is not picking up eigen and why
eigen 311 incorperated an mkl back-end.
not quite. eigen is still popular and suits a huge niche: if you wanna write
expressive linear algebra code with matlab-like syntax and get decent
performance, few is better than eigen. some might find blas-wrapper such as
Armadillo more compelling, performance-wise. |
|
L***n
发帖数: 6727 | 17 Yes, that's one problem, of course they can leave the vectorization to the
compiler but it's not comparable to the hand coded vectorization.
It would still be impressive even if they only beat mkl in the single
threaded case, on the other hand, I'm not sure how real these benchmarks are.
write
I agree, actually I myself was interested in Eigen because I would like to
use it in my project but finally end up with my own much simpler code. The
main reason is in many cases I would like to define my... 阅读全帖 |
|
m********5
发帖数: 17667 | 18 来自主题: Programming版 - 好热闹啊 准确性？？矩阵都是用MKL能有啥差异？boost不差吧？numpy 不差吧?
符号运算MATLAB烂得一屁...
MATLAB也就是东西全，手册全, 统计，优化，系统分析什么东西都可以直接拿来用，其
他的太慢了，还有可能有bug. |
|
m********8
发帖数: 36 | 19 搞了好久都连不上library， 请牛人指点一下。 谢谢了。 |
|
|
t*****n
发帖数: 4908 | 21 写paper的东东吧。没见过哪个公司正经用过。simulink的东四我是不懂。但是就我知
道的
比符号运算，matlab不如mathemaica/maple。这两个做公式推导非常顺手；
比数值计算，matlab速度太慢，和gsl/mkl的之类没法比，不如自己写
比数据处理，excel都有优势
比图表，gnuplot等等都不差
比易用性，mathcad好用多了，公式直接变程序
matlab可能就工具箱有点优势。但是license费用在那里。除了教育/科研有免费版用用
，真不知道谁会掏腰包买它。 |
|
N******K
发帖数: 10202 | 22 你多少年没用过matlab了？
intel mkl 被matlab调用 |
|
s***e
发帖数: 403 | 23 那个是MKL
科学计算要是用java脑子必须进水。那性能烂的一塌糊涂，我当年用g++ -O0就能跑过
别人的java程序。 |
|
|
n******7
发帖数: 12463 | 25 屌丝就用免费的先撑着，老板又不给钱买
反正算的东西也不是太大，最多几天
自己各种东西熟悉了就够本了，我一边干一边学
不过收费的是好啊，看了一眼你说的anaconda，有GPU加速和MKL优化，应该快不少 |
|
G**Y
发帖数: 33224 | 26 自己瞎编了一次openblas，没快多少似乎还有bug （运算结果不对）
决定放弃了。Intel的MKL有免费的吗？
我比了一天，根据binary的情况：
小矩阵运算（20x20之类的），base往往最快。矩阵大了以后atlas和openblas就快很多
了。
但是openblas的multi thread很慢。（我用R测试的，我的R可能是单线程的）。
我的程序刚好是大量的小矩阵，似乎这些NB的blas也没用。
另外我在virtualbox里面跑，不支持AVX。
这东西折腾起来太费劲了。我还是再等等算了。 |
|
|
h*******u
发帖数: 15326 | 28 我开了200个线程，按理说应该自动offload到mic上，但是计算速度没有任何变化，还
不如单线程openblas快。
用xeon phi 还需要对原程序修改吗？ |
|
a*****e
发帖数: 1700 | 29 编译的时候用 -mmic 了吗? 最简单是编译 knc binary 拷贝到卡上然后运行。
如果你用 offload 模式，至少需要修改源码加入几个 pragma |
|
h*******u
发帖数: 15326 | 30 -Mmic不是在native mode采用吗？
我原程序是x64的，就是不想改动，因为是别人维护的，现在改以后还要改。怎么才能
利用上mic?
还是我必须用lib/mic下面的库编译到native mode?但是用mic库编译不兼容怎么办？ |
|
a*****e
发帖数: 1700 | 31 我的意思是，最简单的方法就是 native mode 编译后拷贝到 mic 执行，这样基本上不
需要修改源码，但前提是编译中用到的相关库，也要有 mic native 的版本，才能链接
成功。
如果你用 offload 方式，则需要修改代码。OpenMP 有 offload 和 parallel 相关的
pragma，但有些 tricky 的地方，具体我没用过，也不知道更多了。 |
|
L***n
发帖数: 6727 | 32 多大矩阵啊？我很感兴趣这个问题，几千行数的矩阵两个数值解确实很一致，
其实公平的说不是scipy的问题，是底下调用库的问题，我用的是MKL，按说
还行... |
|
L***n
发帖数: 6727 | 33 恩，我的python数值解在5万这个数量级开始有奇怪的现象，我用mkl是因为
ananconda缺省配置，我自己不会设置python怎么链接底层的库，你是怎么
在python里用arpack的? |
|
P**H
发帖数: 1897 | 34 matlab和scipy解sparse eigen都是用的arpack。目前我没发现例外的。
我就是用的numpy/scipy/matplot。至于dense的，对我没有多大用。linux下底层用的
gotoblas/openblas，win下用mkl。 |
|
L***n
发帖数: 6727 | 35 哦，anaconda可以用mkl作选项，matlab我不知道，你安装scipy的时候
自动装arpack吗？还是要链接到自己编译的库? |
|
L***n
发帖数: 6727 | 36 哪个distribution啊？我用anaconda，印象中好像让我选，我没多想就选了
mkl |
|
L***n
发帖数: 6727 | 37 靠，我们一般用户哪干的了这个，anyway, interesting，我有时间了
当个不用mkl的distribution再实验一下，完了报告一下结果 |
|
M**L
发帖数: 8 | 38 fftw是通用的fft库，有2和3两个接口不一样的版本。
其他的数学库像MKL等都有自己的实现，但接口规范都和fftw一致（可能是2、3之一，
也可能都有）。
虽然是成熟的库，但需要注意FFT的输入参数有很多trick，要小心。 |
|
|
D***n
发帖数: 6804 | 40 愚蠢之至的思路，除了显示你对计算一无所知还能说明啥？
你知道netlib，Lapack, Atlas是什么江湖地位么？你知道这些库花了多少人多少精力
和银子么？还短期无法完成代码，哈哈哈！
Scipy里面也用同样的库，所以你拿SPARK去比，只能比出同样的速度来。
Before building, you will also need to install packages that NumPy and SciPy
depend on
BLAS and LAPACK libraries (optional but strongly recommended for NumPy,
required for SciPy): typically ATLAS + LAPACK, or MKL, or ACML
C and Fortran compilers (typically gcc and gfortran). |
|
a*****e
发帖数: 1700 | 41 就是用 BLAS 库，和语言没关系，Python 一样可以调用 BLAS
BLAS 库好多种实现，CPU 选 MKL，GPU 根据你用的是 CUDA 还是 OpenCL 选不同的库
。基本上多核/线程/SIMD/cache/优化都已经做到极致了，你自己写肯定不如人家写好
的。
如果一定要再进一步优化，CPU+GPU，或者做 fusion，搞起来可以发 HPC 论文了。如
非专业搞这行，还是老老实实一个一个 BLAS call 调用下来就好了。 |
|
S****8
发帖数: 401 | 42 恩,多谢哈, 我也是身边没k40这种GPU所以想折腾下CPU的效率
你是说其实performance还是差在没能利用mkl或者atlas这种blas库上面是吧,
回头我试试, blas/lapack这块有很多c++ template library 挺高效的用起来也方便
, 看看能不能搞到 caffe里面去, 比如FLENS |
|
S****8
发帖数: 401 | 43 恩, FLENS可以用mkl或者atlas作为blas |
|
S****8
发帖数: 401 | 44 恩,多谢哈, 我也是身边没k40这种GPU所以想折腾下CPU的效率
你是说其实performance还是差在没能利用mkl或者atlas这种blas库上面是吧,
回头我试试, blas/lapack这块有很多c++ template library 挺高效的用起来也方便
, 看看能不能搞到 caffe里面去, 比如FLENS |
|
S****8
发帖数: 401 | 45 有啊, Intel里面调MKL这种的马工肯定天天汇编啊 |
|
r*g
发帖数: 3159 | 46 Matlab自带mkl.其它两个，得单独配置。 |
|
p*******e
发帖数: 125 | 47 我用conda,觉得python比r快。有了conda,装numpy这些就超级简单了。你为什么觉得r
快？几年前我在r和python之间选了r就是因为numpy这些安装优化太麻烦。现在
anaconda缺
省装intel mkl,很好 |
|
p*******e
发帖数: 125 | 48 对于我来说，如果pip可以像conda那样迅速安装scikit-learn和它的dependency
libraries,快速装好intel mkl,我可以随时跳船。 |
|
w***g
发帖数: 5958 | 49 连的就是MKL, 肯定用了。刚刚还跟牙膏厂的人打了半天电话，
想让我加入他们的innovator program给他们做广告，我说我要
hardware，对方唧唧歪歪半天，说可能能给我搞到remote
access。我说我要做benchmark，对方说呵呵我们现在不要做
benchmark。 |
|
|
