intel knights landing 72core CPU 谁用过？# Programming - 葵花宝典
p*y
1 楼
What occasions should we give gifts to the daycare teachers? And how much ah
?
Thx~~~~
?
Thx~~~~
D*D
2 楼
He opened the door in the storm, then the water can gush into the ship
causing the whole ship to sink.
causing the whole ship to sink.
s*l
3 楼
我想在TV版作广告，请问，如何交费，要多少，怎么交?
要作的广告就是这个：
http://www.mitbbs.com/article_t2/NorthEast/31328957.html
要求版务人员viamedia， 或者newanew, 或者 marsmission 公开正面回答。
不要简单地指向viamedia置顶的关于交费的帖子，因为那里面没有说如何交易的任何具
体操作细节。
这个帖子已经送往board版和投诉版，防止本贴被无故删贴。
要作的广告就是这个：
http://www.mitbbs.com/article_t2/NorthEast/31328957.html
要求版务人员viamedia， 或者newanew, 或者 marsmission 公开正面回答。
不要简单地指向viamedia置顶的关于交费的帖子，因为那里面没有说如何交易的任何具
体操作细节。
这个帖子已经送往board版和投诉版，防止本贴被无故删贴。
L*8
4 楼
貌似不错啊 可以拼 GUP了
写 GPU code 太麻烦了
写 GPU code 太麻烦了
p*5
5 楼
christmas，学期结束，数额自己觉得合适就可以了，gift card挺好，
ah
【在 p******y 的大作中提到】
: What occasions should we give gifts to the daycare teachers? And how much ah
: ?
: Thx~~~~
ah
【在 p******y 的大作中提到】
: What occasions should we give gifts to the daycare teachers? And how much ah
: ?
: Thx~~~~
t*g
6 楼
Nope. It's not a submarine.
s*l
7 楼
我想在TV版作广告，请问，如何交费，要多少，怎么交?
要作的广告就是这个：
http://www.mitbbs.com/article_t2/NorthEast/31328957.html
要求版务人员viamedia， 或者newanew, 或者 marsmission 公开正面回答。
不要简单地指向viamedia置顶的关于交费的帖子，因为那里面没有说如何交易的任何具
体操作细节。
这个帖子已经送往board版和投诉版，防止本贴被无故删贴。
要作的广告就是这个：
http://www.mitbbs.com/article_t2/NorthEast/31328957.html
要求版务人员viamedia， 或者newanew, 或者 marsmission 公开正面回答。
不要简单地指向viamedia置顶的关于交费的帖子，因为那里面没有说如何交易的任何具
体操作细节。
这个帖子已经送往board版和投诉版，防止本贴被无故删贴。
k*f
8 楼
gpu已经有很多轮子了，比cpu好用多
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
t*f
9 楼
labor day要不要给卡呢
D*D
10 楼
Ship and submarine use the same physical principle. If the water got into
the cabinet, any metal will sink in the ocean.
【在 t******g 的大作中提到】
: Nope. It's not a submarine.
the cabinet, any metal will sink in the ocean.
【在 t******g 的大作中提到】
: Nope. It's not a submarine.
v*a
11 楼
哟，你还把东北的版主位置给篡了，也学聪明了嘛，没缴费就先贴广告链接
既然是给东北籍的，你贴这不是脱裤子放屁？！
不清楚就发信给版务问清楚，交了广告费再做你的广告。
你在本版上窜下跳，公然分裂本版，挖墙角不是一次两次了，还敢气势汹汹，是不是以
为钻风在呻吟版纵容你PA老夫，有钻风给你撑腰老夫就不敢砍你？什么玩意儿。
要求版务人员viamedia， 或者newanew, 或者 marsmission 公开正面回答。
【在 s**l 的大作中提到】
: 我想在TV版作广告，请问，如何交费，要多少，怎么交?
: 要作的广告就是这个：
: http://www.mitbbs.com/article_t2/NorthEast/31328957.html
: 要求版务人员viamedia， 或者newanew, 或者 marsmission 公开正面回答。
: 不要简单地指向viamedia置顶的关于交费的帖子，因为那里面没有说如何交易的任何具
: 体操作细节。
: 这个帖子已经送往board版和投诉版，防止本贴被无故删贴。
既然是给东北籍的，你贴这不是脱裤子放屁？！
不清楚就发信给版务问清楚，交了广告费再做你的广告。
你在本版上窜下跳，公然分裂本版，挖墙角不是一次两次了，还敢气势汹汹，是不是以
为钻风在呻吟版纵容你PA老夫，有钻风给你撑腰老夫就不敢砍你？什么玩意儿。
要求版务人员viamedia， 或者newanew, 或者 marsmission 公开正面回答。
【在 s**l 的大作中提到】
: 我想在TV版作广告，请问，如何交费，要多少，怎么交?
: 要作的广告就是这个：
: http://www.mitbbs.com/article_t2/NorthEast/31328957.html
: 要求版务人员viamedia， 或者newanew, 或者 marsmission 公开正面回答。
: 不要简单地指向viamedia置顶的关于交费的帖子，因为那里面没有说如何交易的任何具
: 体操作细节。
: 这个帖子已经送往board版和投诉版，防止本贴被无故删贴。
w*g
12 楼
价钱拼得过吗? 我是CPU党.
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
r*n
13 楼
没必要
【在 t**f 的大作中提到】
: labor day要不要给卡呢
【在 t**f 的大作中提到】
: labor day要不要给卡呢
l*m
14 楼
性能和amd估计差不多，价格比nvidia的企业级便宜些
【在 w***g 的大作中提到】
: 价钱拼得过吗? 我是CPU党.
【在 w***g 的大作中提到】
: 价钱拼得过吗? 我是CPU党.
N*m
15 楼
larrabee重生？
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
l*m
16 楼
cuda, nvcc都是binary. 如果cpu速度快些，轮子马上就多了。nvidia的优势是gamers
gpus价格低，一般人都能入手
【在 k****f 的大作中提到】
: gpu已经有很多轮子了，比cpu好用多
gpus价格低，一般人都能入手
【在 k****f 的大作中提到】
: gpu已经有很多轮子了，比cpu好用多
s*u
17 楼
烂。OpenMP的scaling明显有问题，72核心280线程但是scaling能到50-60x就很不错了
。总而言之，OpenMP对海量线程的优化还是不行，sweet spot停留在8-32线程并行。也
许是kernel thread的模型决定了OpenMP thread的overhead太高，不像GPU那么
lightweight。MPI倒是能做的不错，但是要这么多的进程内存又不够。最大的优点是可
以直接用现有的x86代码（绝大多数已经支持MPI＋OpenMP了），不用像GPU需要重新
fork出来写CUDA，然后maintain两套codebase
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
。总而言之，OpenMP对海量线程的优化还是不行，sweet spot停留在8-32线程并行。也
许是kernel thread的模型决定了OpenMP thread的overhead太高，不像GPU那么
lightweight。MPI倒是能做的不错，但是要这么多的进程内存又不够。最大的优点是可
以直接用现有的x86代码（绝大多数已经支持MPI＋OpenMP了），不用像GPU需要重新
fork出来写CUDA，然后maintain两套codebase
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
L*8
18 楼
50-60x 是跟谁比较？
【在 s******u 的大作中提到】
: 烂。OpenMP的scaling明显有问题，72核心280线程但是scaling能到50-60x就很不错了
: 。总而言之，OpenMP对海量线程的优化还是不行，sweet spot停留在8-32线程并行。也
: 许是kernel thread的模型决定了OpenMP thread的overhead太高，不像GPU那么
: lightweight。MPI倒是能做的不错，但是要这么多的进程内存又不够。最大的优点是可
: 以直接用现有的x86代码（绝大多数已经支持MPI＋OpenMP了），不用像GPU需要重新
: fork出来写CUDA，然后maintain两套codebase
【在 s******u 的大作中提到】
: 烂。OpenMP的scaling明显有问题，72核心280线程但是scaling能到50-60x就很不错了
: 。总而言之，OpenMP对海量线程的优化还是不行，sweet spot停留在8-32线程并行。也
: 许是kernel thread的模型决定了OpenMP thread的overhead太高，不像GPU那么
: lightweight。MPI倒是能做的不错，但是要这么多的进程内存又不够。最大的优点是可
: 以直接用现有的x86代码（绝大多数已经支持MPI＋OpenMP了），不用像GPU需要重新
: fork出来写CUDA，然后maintain两套codebase
c*9
19 楼
72个远远不够呀。
gamers
【在 l*******m 的大作中提到】
: cuda, nvcc都是binary. 如果cpu速度快些，轮子马上就多了。nvidia的优势是gamers
: gpus价格低，一般人都能入手
gamers
【在 l*******m 的大作中提到】
: cuda, nvcc都是binary. 如果cpu速度快些，轮子马上就多了。nvidia的优势是gamers
: gpus价格低，一般人都能入手
w*g
20 楼
为啥openmp还不如mpi? 单机上面做MPI不合常理啊.
其实只要把blas和fft优化好了就行.
【在 s******u 的大作中提到】
: 烂。OpenMP的scaling明显有问题，72核心280线程但是scaling能到50-60x就很不错了
: 。总而言之，OpenMP对海量线程的优化还是不行，sweet spot停留在8-32线程并行。也
: 许是kernel thread的模型决定了OpenMP thread的overhead太高，不像GPU那么
: lightweight。MPI倒是能做的不错，但是要这么多的进程内存又不够。最大的优点是可
: 以直接用现有的x86代码（绝大多数已经支持MPI＋OpenMP了），不用像GPU需要重新
: fork出来写CUDA，然后maintain两套codebase
其实只要把blas和fft优化好了就行.
【在 s******u 的大作中提到】
: 烂。OpenMP的scaling明显有问题，72核心280线程但是scaling能到50-60x就很不错了
: 。总而言之，OpenMP对海量线程的优化还是不行，sweet spot停留在8-32线程并行。也
: 许是kernel thread的模型决定了OpenMP thread的overhead太高，不像GPU那么
: lightweight。MPI倒是能做的不错，但是要这么多的进程内存又不够。最大的优点是可
: 以直接用现有的x86代码（绝大多数已经支持MPI＋OpenMP了），不用像GPU需要重新
: fork出来写CUDA，然后maintain两套codebase
m*0
21 楼
Intel自己的TBB怎么样？
【在 s******u 的大作中提到】
: 烂。OpenMP的scaling明显有问题，72核心280线程但是scaling能到50-60x就很不错了
: 。总而言之，OpenMP对海量线程的优化还是不行，sweet spot停留在8-32线程并行。也
: 许是kernel thread的模型决定了OpenMP thread的overhead太高，不像GPU那么
: lightweight。MPI倒是能做的不错，但是要这么多的进程内存又不够。最大的优点是可
: 以直接用现有的x86代码（绝大多数已经支持MPI＋OpenMP了），不用像GPU需要重新
: fork出来写CUDA，然后maintain两套codebase
【在 s******u 的大作中提到】
: 烂。OpenMP的scaling明显有问题，72核心280线程但是scaling能到50-60x就很不错了
: 。总而言之，OpenMP对海量线程的优化还是不行，sweet spot停留在8-32线程并行。也
: 许是kernel thread的模型决定了OpenMP thread的overhead太高，不像GPU那么
: lightweight。MPI倒是能做的不错，但是要这么多的进程内存又不够。最大的优点是可
: 以直接用现有的x86代码（绝大多数已经支持MPI＋OpenMP了），不用像GPU需要重新
: fork出来写CUDA，然后maintain两套codebase
w*g
22 楼
转apache license了, 可以跟进下. 就是写的code太难看, 只适合做比较底层的东西.
【在 m****0 的大作中提到】
: Intel自己的TBB怎么样？
【在 m****0 的大作中提到】
: Intel自己的TBB怎么样？
L*8
23 楼
用c++11的thread 就可以 临时开个72线程
每个负责图像的一块区域
自己写 很简单
【在 w***g 的大作中提到】
: 转apache license了, 可以跟进下. 就是写的code太难看, 只适合做比较底层的东西.
每个负责图像的一块区域
自己写 很简单
【在 w***g 的大作中提到】
: 转apache license了, 可以跟进下. 就是写的code太难看, 只适合做比较底层的东西.
m*0
24 楼
居然是这样
没用过没有概念
James自己还把CUDA,OpenCL,OpenMP鄙视一番
我还以为TBB写出来会比较high level
原来也没有好多少啊
【在 w***g 的大作中提到】
: 转apache license了, 可以跟进下. 就是写的code太难看, 只适合做比较底层的东西.
没用过没有概念
James自己还把CUDA,OpenCL,OpenMP鄙视一番
我还以为TBB写出来会比较high level
原来也没有好多少啊
【在 w***g 的大作中提到】
: 转apache license了, 可以跟进下. 就是写的code太难看, 只适合做比较底层的东西.
m*0
25 楼
scaling如何？
【在 L****8 的大作中提到】
: 用c++11的thread 就可以 临时开个72线程
: 每个负责图像的一块区域
: 自己写 很简单
【在 L****8 的大作中提到】
: 用c++11的thread 就可以 临时开个72线程
: 每个负责图像的一块区域
: 自己写 很简单
L*8
26 楼
我只试过12核cpu
【在 m****0 的大作中提到】
: scaling如何？
【在 m****0 的大作中提到】
: scaling如何？
w*g
27 楼
现在也有lambda了. 但即便这样简洁性也还是比openmp差太远.
以前没有lambda时, 为了parallelize一点东西费老了劲了, 而那时
就有omp parallel for了. 所以我一直不用tbb.
为了一点点性能牺牲代码的优美性不值得.
我知道opencv是用tbb的.
【在 m****0 的大作中提到】
: 居然是这样
: 没用过没有概念
: James自己还把CUDA,OpenCL,OpenMP鄙视一番
: 我还以为TBB写出来会比较high level
: 原来也没有好多少啊
以前没有lambda时, 为了parallelize一点东西费老了劲了, 而那时
就有omp parallel for了. 所以我一直不用tbb.
为了一点点性能牺牲代码的优美性不值得.
我知道opencv是用tbb的.
【在 m****0 的大作中提到】
: 居然是这样
: 没用过没有概念
: James自己还把CUDA,OpenCL,OpenMP鄙视一番
: 我还以为TBB写出来会比较high level
: 原来也没有好多少啊
L*8
28 楼
是不是每个thread不能绑定到一个cpu core上？
【在 s******u 的大作中提到】
: 烂。OpenMP的scaling明显有问题，72核心280线程但是scaling能到50-60x就很不错了
: 。总而言之，OpenMP对海量线程的优化还是不行，sweet spot停留在8-32线程并行。也
: 许是kernel thread的模型决定了OpenMP thread的overhead太高，不像GPU那么
: lightweight。MPI倒是能做的不错，但是要这么多的进程内存又不够。最大的优点是可
: 以直接用现有的x86代码（绝大多数已经支持MPI＋OpenMP了），不用像GPU需要重新
: fork出来写CUDA，然后maintain两套codebase
【在 s******u 的大作中提到】
: 烂。OpenMP的scaling明显有问题，72核心280线程但是scaling能到50-60x就很不错了
: 。总而言之，OpenMP对海量线程的优化还是不行，sweet spot停留在8-32线程并行。也
: 许是kernel thread的模型决定了OpenMP thread的overhead太高，不像GPU那么
: lightweight。MPI倒是能做的不错，但是要这么多的进程内存又不够。最大的优点是可
: 以直接用现有的x86代码（绝大多数已经支持MPI＋OpenMP了），不用像GPU需要重新
: fork出来写CUDA，然后maintain两套codebase
m*0
29 楼
又看了一遍，72核心，50-60x其实还行啊（是不是我要求太低了。。。）
我好奇的是你的MPI能scale到什么程度？
【在 s******u 的大作中提到】
: 烂。OpenMP的scaling明显有问题，72核心280线程但是scaling能到50-60x就很不错了
: 。总而言之，OpenMP对海量线程的优化还是不行，sweet spot停留在8-32线程并行。也
: 许是kernel thread的模型决定了OpenMP thread的overhead太高，不像GPU那么
: lightweight。MPI倒是能做的不错，但是要这么多的进程内存又不够。最大的优点是可
: 以直接用现有的x86代码（绝大多数已经支持MPI＋OpenMP了），不用像GPU需要重新
: fork出来写CUDA，然后maintain两套codebase
我好奇的是你的MPI能scale到什么程度？
【在 s******u 的大作中提到】
: 烂。OpenMP的scaling明显有问题，72核心280线程但是scaling能到50-60x就很不错了
: 。总而言之，OpenMP对海量线程的优化还是不行，sweet spot停留在8-32线程并行。也
: 许是kernel thread的模型决定了OpenMP thread的overhead太高，不像GPU那么
: lightweight。MPI倒是能做的不错，但是要这么多的进程内存又不够。最大的优点是可
: 以直接用现有的x86代码（绝大多数已经支持MPI＋OpenMP了），不用像GPU需要重新
: fork出来写CUDA，然后maintain两套codebase
k*i
30 楼
nvda撕intc phi - no free-lunch for recompile & run
http://www.nvidia.com/object/justthefacts.html
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
http://www.nvidia.com/object/justthefacts.html
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
k*i
31 楼
clang在做cuda编译，用的sdk，driver还是closed的。
http://llvm.org/docs/CompileCudaWithLLVM.html
gamers
【在 l*******m 的大作中提到】
: cuda, nvcc都是binary. 如果cpu速度快些，轮子马上就多了。nvidia的优势是gamers
: gpus价格低，一般人都能入手
http://llvm.org/docs/CompileCudaWithLLVM.html
gamers
【在 l*******m 的大作中提到】
: cuda, nvcc都是binary. 如果cpu速度快些，轮子马上就多了。nvidia的优势是gamers
: gpus价格低，一般人都能入手
s*u
32 楼
跟单线程运行比较，280个线程也就只有50-60x的speedup
【在 L****8 的大作中提到】
: 50-60x 是跟谁比较？
【在 L****8 的大作中提到】
: 50-60x 是跟谁比较？
s*u
33 楼
OpenMP不如MPI确实是很奇怪，而且测试的程序是基本完全数据独立，不需要共享和加
锁的那种理想算法，横竖应该跟MPI差不多，但是实际上效率只有MPI的一半到三分之二
左右。从Intel和AMD的CPU，到knights corner, knights landing都是这样子。要说是
memory access的问题，但是multisock的CPU都是NUMA，而MIC还是UMA，按说更好才是
。最后不光是我们自己，去那些HPC的workshop，大家都是一样的说法。结果就是平常
那种常见的32核心的机器，通常都是跑4MPIx8OpenMP或者8MPIx4OpenMP
【在 w***g 的大作中提到】
: 为啥openmp还不如mpi? 单机上面做MPI不合常理啊.
: 其实只要把blas和fft优化好了就行.
锁的那种理想算法，横竖应该跟MPI差不多，但是实际上效率只有MPI的一半到三分之二
左右。从Intel和AMD的CPU，到knights corner, knights landing都是这样子。要说是
memory access的问题，但是multisock的CPU都是NUMA，而MIC还是UMA，按说更好才是
。最后不光是我们自己，去那些HPC的workshop，大家都是一样的说法。结果就是平常
那种常见的32核心的机器，通常都是跑4MPIx8OpenMP或者8MPIx4OpenMP
【在 w***g 的大作中提到】
: 为啥openmp还不如mpi? 单机上面做MPI不合常理啊.
: 其实只要把blas和fft优化好了就行.
s*u
34 楼
没拿TBB写过并行程序，所以不敢说。我听说的是TBB更适合task并行，而不是data并行
，所以也许并不适合通常的数值计算。当然只是听说，不负责任，呵呵
【在 m****0 的大作中提到】
: Intel自己的TBB怎么样？
，所以也许并不适合通常的数值计算。当然只是听说，不负责任，呵呵
【在 m****0 的大作中提到】
: Intel自己的TBB怎么样？
s*u
35 楼
MIC有各种的绑定方法，比方说先每个核心塞一个线程，塞满之后再往每个核心赛第二
个线程，或者是每个核心先塞满四个线程，再接着塞下一个核心等等。我说50-60x已经
是最好的情况下了
【在 L****8 的大作中提到】
: 是不是每个thread不能绑定到一个cpu core上？
个线程，或者是每个核心先塞满四个线程，再接着塞下一个核心等等。我说50-60x已经
是最好的情况下了
【在 L****8 的大作中提到】
: 是不是每个thread不能绑定到一个cpu core上？
p*o
36 楼
真诡异
【在 s******u 的大作中提到】
: OpenMP不如MPI确实是很奇怪，而且测试的程序是基本完全数据独立，不需要共享和加
: 锁的那种理想算法，横竖应该跟MPI差不多，但是实际上效率只有MPI的一半到三分之二
: 左右。从Intel和AMD的CPU，到knights corner, knights landing都是这样子。要说是
: memory access的问题，但是multisock的CPU都是NUMA，而MIC还是UMA，按说更好才是
: 。最后不光是我们自己，去那些HPC的workshop，大家都是一样的说法。结果就是平常
: 那种常见的32核心的机器，通常都是跑4MPIx8OpenMP或者8MPIx4OpenMP
【在 s******u 的大作中提到】
: OpenMP不如MPI确实是很奇怪，而且测试的程序是基本完全数据独立，不需要共享和加
: 锁的那种理想算法，横竖应该跟MPI差不多，但是实际上效率只有MPI的一半到三分之二
: 左右。从Intel和AMD的CPU，到knights corner, knights landing都是这样子。要说是
: memory access的问题，但是multisock的CPU都是NUMA，而MIC还是UMA，按说更好才是
: 。最后不光是我们自己，去那些HPC的workshop，大家都是一样的说法。结果就是平常
: 那种常见的32核心的机器，通常都是跑4MPIx8OpenMP或者8MPIx4OpenMP
w*g
37 楼
你有benchmark吗? 你这么说我很涨见识. 我见过的几个, openblas有openmp或者
thread版,
opencv用tbb, fftw用openmp, 还没见过哪个单机跑的轮子用MPI的. 你没有用32MPI我
觉得
就是一个证据, 就是MPI还做不到底. 但是即使是4x8或8x4能把OpenMP干掉我觉得也很
牛.
【在 s******u 的大作中提到】
: OpenMP不如MPI确实是很奇怪，而且测试的程序是基本完全数据独立，不需要共享和加
: 锁的那种理想算法，横竖应该跟MPI差不多，但是实际上效率只有MPI的一半到三分之二
: 左右。从Intel和AMD的CPU，到knights corner, knights landing都是这样子。要说是
: memory access的问题，但是multisock的CPU都是NUMA，而MIC还是UMA，按说更好才是
: 。最后不光是我们自己，去那些HPC的workshop，大家都是一样的说法。结果就是平常
: 那种常见的32核心的机器，通常都是跑4MPIx8OpenMP或者8MPIx4OpenMP
thread版,
opencv用tbb, fftw用openmp, 还没见过哪个单机跑的轮子用MPI的. 你没有用32MPI我
觉得
就是一个证据, 就是MPI还做不到底. 但是即使是4x8或8x4能把OpenMP干掉我觉得也很
牛.
【在 s******u 的大作中提到】
: OpenMP不如MPI确实是很奇怪，而且测试的程序是基本完全数据独立，不需要共享和加
: 锁的那种理想算法，横竖应该跟MPI差不多，但是实际上效率只有MPI的一半到三分之二
: 左右。从Intel和AMD的CPU，到knights corner, knights landing都是这样子。要说是
: memory access的问题，但是multisock的CPU都是NUMA，而MIC还是UMA，按说更好才是
: 。最后不光是我们自己，去那些HPC的workshop，大家都是一样的说法。结果就是平常
: 那种常见的32核心的机器，通常都是跑4MPIx8OpenMP或者8MPIx4OpenMP
L*8
38 楼
1.3GHz 72 core
是不是不如最新的 2块 xeon e5-2699 (每块22 core 2.30GHz ) ?
有16G作为L3 cache 是不是比普通的xeon 快呢？
【在 s******u 的大作中提到】
: 跟单线程运行比较，280个线程也就只有50-60x的speedup
是不是不如最新的 2块 xeon e5-2699 (每块22 core 2.30GHz ) ?
有16G作为L3 cache 是不是比普通的xeon 快呢？
【在 s******u 的大作中提到】
: 跟单线程运行比较，280个线程也就只有50-60x的speedup
s*u
39 楼
72个核心，然后每个核心是4个线程，硬件上只有一个instruction dispatcher，但是
有四个data dispatcher，所以理论上对SIMD还是能有不错的并行度。这样子总共280个
线程，怎么的我也指望能有100-140x之间的speedup吧
我用来测试的是PIC算法里面的charge deposition，32核心的CPU，MPI可以到30x。
BlueGeneQ，20000个核心基本可以到80-90%的效率，差不多16000x的speedup
【在 m****0 的大作中提到】
: 又看了一遍，72核心，50-60x其实还行啊（是不是我要求太低了。。。）
: 我好奇的是你的MPI能scale到什么程度？
有四个data dispatcher，所以理论上对SIMD还是能有不错的并行度。这样子总共280个
线程，怎么的我也指望能有100-140x之间的speedup吧
我用来测试的是PIC算法里面的charge deposition，32核心的CPU，MPI可以到30x。
BlueGeneQ，20000个核心基本可以到80-90%的效率，差不多16000x的speedup
【在 m****0 的大作中提到】
: 又看了一遍，72核心，50-60x其实还行啊（是不是我要求太低了。。。）
: 我好奇的是你的MPI能scale到什么程度？
w*g
40 楼
你这么一说我突然想起来, openMPI用的是轮询, 只要一跑上, 不管有没有算东西,
CPU都是100%. openmpi比openmp快可能和这个有关.
【在 s******u 的大作中提到】
: MIC有各种的绑定方法，比方说先每个核心塞一个线程，塞满之后再往每个核心赛第二
: 个线程，或者是每个核心先塞满四个线程，再接着塞下一个核心等等。我说50-60x已经
: 是最好的情况下了
CPU都是100%. openmpi比openmp快可能和这个有关.
【在 s******u 的大作中提到】
: MIC有各种的绑定方法，比方说先每个核心塞一个线程，塞满之后再往每个核心赛第二
: 个线程，或者是每个核心先塞满四个线程，再接着塞下一个核心等等。我说50-60x已经
: 是最好的情况下了
w*g
41 楼
我还见过一上来就把hyperthreading关掉的人. 我自己写的C++程序, 90%的情况
用perf进去看最慢的指令, 都是在等数据. 或者说能做的优化做完以后, 一般就
都变成内存瓶颈了.
【在 s******u 的大作中提到】
: 72个核心，然后每个核心是4个线程，硬件上只有一个instruction dispatcher，但是
: 有四个data dispatcher，所以理论上对SIMD还是能有不错的并行度。这样子总共280个
: 线程，怎么的我也指望能有100-140x之间的speedup吧
: 我用来测试的是PIC算法里面的charge deposition，32核心的CPU，MPI可以到30x。
: BlueGeneQ，20000个核心基本可以到80-90%的效率，差不多16000x的speedup
用perf进去看最慢的指令, 都是在等数据. 或者说能做的优化做完以后, 一般就
都变成内存瓶颈了.
【在 s******u 的大作中提到】
: 72个核心，然后每个核心是4个线程，硬件上只有一个instruction dispatcher，但是
: 有四个data dispatcher，所以理论上对SIMD还是能有不错的并行度。这样子总共280个
: 线程，怎么的我也指望能有100-140x之间的speedup吧
: 我用来测试的是PIC算法里面的charge deposition，32核心的CPU，MPI可以到30x。
: BlueGeneQ，20000个核心基本可以到80-90%的效率，差不多16000x的speedup
s*u
42 楼
你可以去试一下，单机上跑fftw，MPI一点都不比OpenMP差，是不是更好我倒是忘记了
，很久以前跑的。有两个以上的node，比方说32x2或者32x4的话纯MPI就不行了，不过
这个也许跟MPI的实现和硬件有更大的关系。3d FFT的transpose要用到alltoall，如果
优化不好的话这个是最大的性能瓶颈
benchmark我找找看
【在 w***g 的大作中提到】
: 你有benchmark吗? 你这么说我很涨见识. 我见过的几个, openblas有openmp或者
: thread版,
: opencv用tbb, fftw用openmp, 还没见过哪个单机跑的轮子用MPI的. 你没有用32MPI我
: 觉得
: 就是一个证据, 就是MPI还做不到底. 但是即使是4x8或8x4能把OpenMP干掉我觉得也很
: 牛.
，很久以前跑的。有两个以上的node，比方说32x2或者32x4的话纯MPI就不行了，不过
这个也许跟MPI的实现和硬件有更大的关系。3d FFT的transpose要用到alltoall，如果
优化不好的话这个是最大的性能瓶颈
benchmark我找找看
【在 w***g 的大作中提到】
: 你有benchmark吗? 你这么说我很涨见识. 我见过的几个, openblas有openmp或者
: thread版,
: opencv用tbb, fftw用openmp, 还没见过哪个单机跑的轮子用MPI的. 你没有用32MPI我
: 觉得
: 就是一个证据, 就是MPI还做不到底. 但是即使是4x8或8x4能把OpenMP干掉我觉得也很
: 牛.
w*g
43 楼
fftw还真有MPI!
【在 s******u 的大作中提到】
: 你可以去试一下，单机上跑fftw，MPI一点都不比OpenMP差，是不是更好我倒是忘记了
: ，很久以前跑的。有两个以上的node，比方说32x2或者32x4的话纯MPI就不行了，不过
: 这个也许跟MPI的实现和硬件有更大的关系。3d FFT的transpose要用到alltoall，如果
: 优化不好的话这个是最大的性能瓶颈
: benchmark我找找看
【在 s******u 的大作中提到】
: 你可以去试一下，单机上跑fftw，MPI一点都不比OpenMP差，是不是更好我倒是忘记了
: ，很久以前跑的。有两个以上的node，比方说32x2或者32x4的话纯MPI就不行了，不过
: 这个也许跟MPI的实现和硬件有更大的关系。3d FFT的transpose要用到alltoall，如果
: 优化不好的话这个是最大的性能瓶颈
: benchmark我找找看
s*u
44 楼
而且MPI版本的fftw远远快过OpenMP，至少三年前我测的时候是这样子
虚线是MPI，实线是OpenMP，超过32的部分不用去管
【在 w***g 的大作中提到】
: fftw还真有MPI!
虚线是MPI，实线是OpenMP，超过32的部分不用去管
【在 w***g 的大作中提到】
: fftw还真有MPI!
s*u
45 楼
嗯，我记得是一次memory load然后做几十次到上百次运算的才能做到CPU bound？一般
哪有这么多，我见过的几乎都是memory bound的
【在 w***g 的大作中提到】
: 我还见过一上来就把hyperthreading关掉的人. 我自己写的C++程序, 90%的情况
: 用perf进去看最慢的指令, 都是在等数据. 或者说能做的优化做完以后, 一般就
: 都变成内存瓶颈了.
哪有这么多，我见过的几乎都是memory bound的
【在 w***g 的大作中提到】
: 我还见过一上来就把hyperthreading关掉的人. 我自己写的C++程序, 90%的情况
: 用perf进去看最慢的指令, 都是在等数据. 或者说能做的优化做完以后, 一般就
: 都变成内存瓶颈了.
s*u
46 楼
有一点knights landing比xeon强，就是他的AVX512，你的应用能用得上的话裸提速起
码4倍以上，这个倒是实打实，而且和硬件4线程是独立的，也就是说每个核心可以跑4
个硬件线程，乘以每线程8倍宽度的AVX，都算上还是挺恐怖的
xeon是2线程的hyperthreading加上4倍宽度的AVX，而且里面的AVX指令对除法运算虽然
是4倍宽度，但是2倍延迟，基本等效于2倍宽度的SSE了
【在 L****8 的大作中提到】
: 1.3GHz 72 core
: 是不是不如最新的 2块 xeon e5-2699 (每块22 core 2.30GHz ) ?
: 有16G作为L3 cache 是不是比普通的xeon 快呢？
码4倍以上，这个倒是实打实，而且和硬件4线程是独立的，也就是说每个核心可以跑4
个硬件线程，乘以每线程8倍宽度的AVX，都算上还是挺恐怖的
xeon是2线程的hyperthreading加上4倍宽度的AVX，而且里面的AVX指令对除法运算虽然
是4倍宽度，但是2倍延迟，基本等效于2倍宽度的SSE了
【在 L****8 的大作中提到】
: 1.3GHz 72 core
: 是不是不如最新的 2块 xeon e5-2699 (每块22 core 2.30GHz ) ?
: 有16G作为L3 cache 是不是比普通的xeon 快呢？
L*8
47 楼
看了一下https://github.com/baidu-research/DeepBench/tree/master/results
矩阵乘法
KNL 比 titan /titan-pasca 稍快
卷积
KNL 比 titan /titan-pasca慢 花费大约2倍时间
我看KNL 用到deep learning 上 还是不错的
具体见附件
4
【在 s******u 的大作中提到】
: 有一点knights landing比xeon强，就是他的AVX512，你的应用能用得上的话裸提速起
: 码4倍以上，这个倒是实打实，而且和硬件4线程是独立的，也就是说每个核心可以跑4
: 个硬件线程，乘以每线程8倍宽度的AVX，都算上还是挺恐怖的
: xeon是2线程的hyperthreading加上4倍宽度的AVX，而且里面的AVX指令对除法运算虽然
: 是4倍宽度，但是2倍延迟，基本等效于2倍宽度的SSE了
矩阵乘法
KNL 比 titan /titan-pasca 稍快
卷积
KNL 比 titan /titan-pasca慢 花费大约2倍时间
我看KNL 用到deep learning 上 还是不错的
具体见附件
4
【在 s******u 的大作中提到】
: 有一点knights landing比xeon强，就是他的AVX512，你的应用能用得上的话裸提速起
: 码4倍以上，这个倒是实打实，而且和硬件4线程是独立的，也就是说每个核心可以跑4
: 个硬件线程，乘以每线程8倍宽度的AVX，都算上还是挺恐怖的
: xeon是2线程的hyperthreading加上4倍宽度的AVX，而且里面的AVX指令对除法运算虽然
: 是4倍宽度，但是2倍延迟，基本等效于2倍宽度的SSE了
w*g
48 楼
比deep learning 没太大意义啊. 第一价钱肯定比不过. 第二deep learning框架
都很成熟了, 根本不需要自己写gpu代码. 所有人都已经在GPU上搞了, 要回x86
反而有barrier.
手写新算法, x86要比GPU容易得多. 这个还是很有吸引力的.
GPU内存优化太啰嗦. 这个一般人搞不定 (其实是我自己搞不定, 推广到一般人了.)
【在 L****8 的大作中提到】
: 看了一下https://github.com/baidu-research/DeepBench/tree/master/results
: 矩阵乘法
: KNL 比 titan /titan-pasca 稍快
: 卷积
: KNL 比 titan /titan-pasca慢 花费大约2倍时间
: 我看KNL 用到deep learning 上 还是不错的
: 具体见附件
:
: 4
都很成熟了, 根本不需要自己写gpu代码. 所有人都已经在GPU上搞了, 要回x86
反而有barrier.
手写新算法, x86要比GPU容易得多. 这个还是很有吸引力的.
GPU内存优化太啰嗦. 这个一般人搞不定 (其实是我自己搞不定, 推广到一般人了.)
【在 L****8 的大作中提到】
: 看了一下https://github.com/baidu-research/DeepBench/tree/master/results
: 矩阵乘法
: KNL 比 titan /titan-pasca 稍快
: 卷积
: KNL 比 titan /titan-pasca慢 花费大约2倍时间
: 我看KNL 用到deep learning 上 还是不错的
: 具体见附件
:
: 4
k*f
49 楼
intel买了altera，以后可以cpu嵌入fpga，用fpga优化矩阵乘法和卷积，比gpu会快不
少的。不过fpga程序可就难多了，需要有人造好轮子。
【在 w***g 的大作中提到】
: 比deep learning 没太大意义啊. 第一价钱肯定比不过. 第二deep learning框架
: 都很成熟了, 根本不需要自己写gpu代码. 所有人都已经在GPU上搞了, 要回x86
: 反而有barrier.
: 手写新算法, x86要比GPU容易得多. 这个还是很有吸引力的.
: GPU内存优化太啰嗦. 这个一般人搞不定 (其实是我自己搞不定, 推广到一般人了.)
少的。不过fpga程序可就难多了，需要有人造好轮子。
【在 w***g 的大作中提到】
: 比deep learning 没太大意义啊. 第一价钱肯定比不过. 第二deep learning框架
: 都很成熟了, 根本不需要自己写gpu代码. 所有人都已经在GPU上搞了, 要回x86
: 反而有barrier.
: 手写新算法, x86要比GPU容易得多. 这个还是很有吸引力的.
: GPU内存优化太啰嗦. 这个一般人搞不定 (其实是我自己搞不定, 推广到一般人了.)
r*y
50 楼
fpga用functional programming很简便。
【在 k****f 的大作中提到】
: intel买了altera，以后可以cpu嵌入fpga，用fpga优化矩阵乘法和卷积，比gpu会快不
: 少的。不过fpga程序可就难多了，需要有人造好轮子。
【在 k****f 的大作中提到】
: intel买了altera，以后可以cpu嵌入fpga，用fpga优化矩阵乘法和卷积，比gpu会快不
: 少的。不过fpga程序可就难多了，需要有人造好轮子。
w*g
51 楼
说了好多年了. 我几年前写deep learning框架的时候就指着这个, 没有上GPU.
结果到现在还没有出来.
【在 k****f 的大作中提到】
: intel买了altera，以后可以cpu嵌入fpga，用fpga优化矩阵乘法和卷积，比gpu会快不
: 少的。不过fpga程序可就难多了，需要有人造好轮子。
结果到现在还没有出来.
【在 k****f 的大作中提到】
: intel买了altera，以后可以cpu嵌入fpga，用fpga优化矩阵乘法和卷积，比gpu会快不
: 少的。不过fpga程序可就难多了，需要有人造好轮子。
s*a
52 楼
你肯定搞的定，就是不值得花这个精力而已，非常distracting
【在 w***g 的大作中提到】
: 比deep learning 没太大意义啊. 第一价钱肯定比不过. 第二deep learning框架
: 都很成熟了, 根本不需要自己写gpu代码. 所有人都已经在GPU上搞了, 要回x86
: 反而有barrier.
: 手写新算法, x86要比GPU容易得多. 这个还是很有吸引力的.
: GPU内存优化太啰嗦. 这个一般人搞不定 (其实是我自己搞不定, 推广到一般人了.)
【在 w***g 的大作中提到】
: 比deep learning 没太大意义啊. 第一价钱肯定比不过. 第二deep learning框架
: 都很成熟了, 根本不需要自己写gpu代码. 所有人都已经在GPU上搞了, 要回x86
: 反而有barrier.
: 手写新算法, x86要比GPU容易得多. 这个还是很有吸引力的.
: GPU内存优化太啰嗦. 这个一般人搞不定 (其实是我自己搞不定, 推广到一般人了.)
l*m
53 楼
FPGA主频太低了，gpu的1/5 ～1/3. fpu和memory io都没优势。每个layer/opt做完后
， 基本要同步到主内存里，inference可能还有些优化可能，training太复杂了
FPGA就是省电，对个人用户没有任何意义。
【在 k****f 的大作中提到】
: intel买了altera，以后可以cpu嵌入fpga，用fpga优化矩阵乘法和卷积，比gpu会快不
: 少的。不过fpga程序可就难多了，需要有人造好轮子。
， 基本要同步到主内存里，inference可能还有些优化可能，training太复杂了
FPGA就是省电，对个人用户没有任何意义。
【在 k****f 的大作中提到】
: intel买了altera，以后可以cpu嵌入fpga，用fpga优化矩阵乘法和卷积，比gpu会快不
: 少的。不过fpga程序可就难多了，需要有人造好轮子。
y*b
54 楼
超级计算机，几千上万个节点的，基本都关掉超线程，普遍认为超线程对科学计算没有
帮助。
就是工作站，超线程对一个job也没啥帮助，除非同时运行两个job，假设一个job指16
核工作站上的一个16线程任务。如果一个job采用32线程，性能反而下降。估计超级计
算机考虑到这个因素，刻意关掉超线程。
perf是指perfsuite吗？
【在 w***g 的大作中提到】
: 我还见过一上来就把hyperthreading关掉的人. 我自己写的C++程序, 90%的情况
: 用perf进去看最慢的指令, 都是在等数据. 或者说能做的优化做完以后, 一般就
: 都变成内存瓶颈了.
帮助。
就是工作站，超线程对一个job也没啥帮助，除非同时运行两个job，假设一个job指16
核工作站上的一个16线程任务。如果一个job采用32线程，性能反而下降。估计超级计
算机考虑到这个因素，刻意关掉超线程。
perf是指perfsuite吗？
【在 w***g 的大作中提到】
: 我还见过一上来就把hyperthreading关掉的人. 我自己写的C++程序, 90%的情况
: 用perf进去看最慢的指令, 都是在等数据. 或者说能做的优化做完以后, 一般就
: 都变成内存瓶颈了.
y*b
55 楼
这个CPU bound Vs memory bound 一般用什么软件测试？
【在 s******u 的大作中提到】
: 嗯，我记得是一次memory load然后做几十次到上百次运算的才能做到CPU bound？一般
: 哪有这么多，我见过的几乎都是memory bound的
【在 s******u 的大作中提到】
: 嗯，我记得是一次memory load然后做几十次到上百次运算的才能做到CPU bound？一般
: 哪有这么多，我见过的几乎都是memory bound的
y*b
56 楼
有啥解释吗？
是总体上跟以下因素有关？
mpi靠手工分块(分区)决定计算粒度，这个常常就是一种优化；
而openmp靠机器决定计算粒度，通常太细而overhead太大。
还是跟编译器和底层硬件更有关系？
我做的一种密集颗粒碰撞模拟，也是mpi明显优于openmp，原计划在几千个
节点上采用hybrid mpi/openmp模式，最后发现还是pure mpi模式快得多，
跨五个数量级的模拟都给出同样结论。当然我这个模拟跟那些专门的测试
有所区别，毕竟有其它因素影响：比如有小量代码不适合openmp化，有些
地方加锁，算法还可进一步改进等等。
【在 s******u 的大作中提到】
: OpenMP不如MPI确实是很奇怪，而且测试的程序是基本完全数据独立，不需要共享和加
: 锁的那种理想算法，横竖应该跟MPI差不多，但是实际上效率只有MPI的一半到三分之二
: 左右。从Intel和AMD的CPU，到knights corner, knights landing都是这样子。要说是
: memory access的问题，但是multisock的CPU都是NUMA，而MIC还是UMA，按说更好才是
: 。最后不光是我们自己，去那些HPC的workshop，大家都是一样的说法。结果就是平常
: 那种常见的32核心的机器，通常都是跑4MPIx8OpenMP或者8MPIx4OpenMP
是总体上跟以下因素有关？
mpi靠手工分块(分区)决定计算粒度，这个常常就是一种优化；
而openmp靠机器决定计算粒度，通常太细而overhead太大。
还是跟编译器和底层硬件更有关系？
我做的一种密集颗粒碰撞模拟，也是mpi明显优于openmp，原计划在几千个
节点上采用hybrid mpi/openmp模式，最后发现还是pure mpi模式快得多，
跨五个数量级的模拟都给出同样结论。当然我这个模拟跟那些专门的测试
有所区别，毕竟有其它因素影响：比如有小量代码不适合openmp化，有些
地方加锁，算法还可进一步改进等等。
【在 s******u 的大作中提到】
: OpenMP不如MPI确实是很奇怪，而且测试的程序是基本完全数据独立，不需要共享和加
: 锁的那种理想算法，横竖应该跟MPI差不多，但是实际上效率只有MPI的一半到三分之二
: 左右。从Intel和AMD的CPU，到knights corner, knights landing都是这样子。要说是
: memory access的问题，但是multisock的CPU都是NUMA，而MIC还是UMA，按说更好才是
: 。最后不光是我们自己，去那些HPC的workshop，大家都是一样的说法。结果就是平常
: 那种常见的32核心的机器，通常都是跑4MPIx8OpenMP或者8MPIx4OpenMP
s*u
57 楼
好点的performance profiling tool，像allinea map，可以给出来一段时间内多少个
cycle是在等memory access，多少个cycle是在做运算等等
【在 y**b 的大作中提到】
: 这个CPU bound Vs memory bound 一般用什么软件测试？
cycle是在等memory access，多少个cycle是在做运算等等
【在 y**b 的大作中提到】
: 这个CPU bound Vs memory bound 一般用什么软件测试？
w*g
58 楼
就是linux自带那个perf record perf report那个. 自从linux 3.x有了perf
就把oprofile扔掉了.
16
【在 y**b 的大作中提到】
: 超级计算机，几千上万个节点的，基本都关掉超线程，普遍认为超线程对科学计算没有
: 帮助。
: 就是工作站，超线程对一个job也没啥帮助，除非同时运行两个job，假设一个job指16
: 核工作站上的一个16线程任务。如果一个job采用32线程，性能反而下降。估计超级计
: 算机考虑到这个因素，刻意关掉超线程。
: perf是指perfsuite吗？
就把oprofile扔掉了.
16
【在 y**b 的大作中提到】
: 超级计算机，几千上万个节点的，基本都关掉超线程，普遍认为超线程对科学计算没有
: 帮助。
: 就是工作站，超线程对一个job也没啥帮助，除非同时运行两个job，假设一个job指16
: 核工作站上的一个16线程任务。如果一个job采用32线程，性能反而下降。估计超级计
: 算机考虑到这个因素，刻意关掉超线程。
: perf是指perfsuite吗？
b*s
59 楼
did you count in PCIe transfer?
【在 s******u 的大作中提到】
: OpenMP不如MPI确实是很奇怪，而且测试的程序是基本完全数据独立，不需要共享和加
: 锁的那种理想算法，横竖应该跟MPI差不多，但是实际上效率只有MPI的一半到三分之二
: 左右。从Intel和AMD的CPU，到knights corner, knights landing都是这样子。要说是
: memory access的问题，但是multisock的CPU都是NUMA，而MIC还是UMA，按说更好才是
: 。最后不光是我们自己，去那些HPC的workshop，大家都是一样的说法。结果就是平常
: 那种常见的32核心的机器，通常都是跑4MPIx8OpenMP或者8MPIx4OpenMP
【在 s******u 的大作中提到】
: OpenMP不如MPI确实是很奇怪，而且测试的程序是基本完全数据独立，不需要共享和加
: 锁的那种理想算法，横竖应该跟MPI差不多，但是实际上效率只有MPI的一半到三分之二
: 左右。从Intel和AMD的CPU，到knights corner, knights landing都是这样子。要说是
: memory access的问题，但是multisock的CPU都是NUMA，而MIC还是UMA，按说更好才是
: 。最后不光是我们自己，去那些HPC的workshop，大家都是一样的说法。结果就是平常
: 那种常见的32核心的机器，通常都是跑4MPIx8OpenMP或者8MPIx4OpenMP
b*s
60 楼
agree. hyper threading is 2 virtual threads share the same execution unit
if they are all busy, it will slow down the performance
16
【在 y**b 的大作中提到】
: 超级计算机，几千上万个节点的，基本都关掉超线程，普遍认为超线程对科学计算没有
: 帮助。
: 就是工作站，超线程对一个job也没啥帮助，除非同时运行两个job，假设一个job指16
: 核工作站上的一个16线程任务。如果一个job采用32线程，性能反而下降。估计超级计
: 算机考虑到这个因素，刻意关掉超线程。
: perf是指perfsuite吗？
if they are all busy, it will slow down the performance
16
【在 y**b 的大作中提到】
: 超级计算机，几千上万个节点的，基本都关掉超线程，普遍认为超线程对科学计算没有
: 帮助。
: 就是工作站，超线程对一个job也没啥帮助，除非同时运行两个job，假设一个job指16
: 核工作站上的一个16线程任务。如果一个job采用32线程，性能反而下降。估计超级计
: 算机考虑到这个因素，刻意关掉超线程。
: perf是指perfsuite吗？
s*u
61 楼
这个跟pcie有什么关系？
【在 b*******s 的大作中提到】
: did you count in PCIe transfer?
【在 b*******s 的大作中提到】
: did you count in PCIe transfer?
l*m
62 楼
Intel 有新动作
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
m*5
63 楼
我更喜欢CPU
能做的事情比GPU多太多了，还能轻松扩展到集群，GPU限制则很大，好多库都不能用。
不过这玩意儿没用过，谁能搞个测评就好了。
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
能做的事情比GPU多太多了，还能轻松扩展到集群，GPU限制则很大，好多库都不能用。
不过这玩意儿没用过，谁能搞个测评就好了。
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
m*5
64 楼
我一铁哥们儿就专门搞这个的
除了特殊的信号处理领域，没啥太大意义，等你FPGA调好，CPU和GPU又不知道便宜了多
少。Intel是想搞个通用库，大家要用的时候它自动优化生成HDVL, 但按照我的经验来
说，这非常困难，FPGA之所以快，就是要针对特殊应用手工优化的。
【在 k****f 的大作中提到】
: intel买了altera，以后可以cpu嵌入fpga，用fpga优化矩阵乘法和卷积，比gpu会快不
: 少的。不过fpga程序可就难多了，需要有人造好轮子。
除了特殊的信号处理领域，没啥太大意义，等你FPGA调好，CPU和GPU又不知道便宜了多
少。Intel是想搞个通用库，大家要用的时候它自动优化生成HDVL, 但按照我的经验来
说，这非常困难，FPGA之所以快，就是要针对特殊应用手工优化的。
【在 k****f 的大作中提到】
: intel买了altera，以后可以cpu嵌入fpga，用fpga优化矩阵乘法和卷积，比gpu会快不
: 少的。不过fpga程序可就难多了，需要有人造好轮子。
m*5
65 楼
单机是这样？！
太奇怪了，我没单独测试过fftw, 我自己的程序测出来都是MPI慢不少，可能我通讯多
了点。该不会是fftw实现的时候openMP有什么锁，而MPI是都有自己的数据拷贝，没有
锁导致的？
【在 s******u 的大作中提到】
: 而且MPI版本的fftw远远快过OpenMP，至少三年前我测的时候是这样子
: 虚线是MPI，实线是OpenMP，超过32的部分不用去管
太奇怪了，我没单独测试过fftw, 我自己的程序测出来都是MPI慢不少，可能我通讯多
了点。该不会是fftw实现的时候openMP有什么锁，而MPI是都有自己的数据拷贝，没有
锁导致的？
【在 s******u 的大作中提到】
: 而且MPI版本的fftw远远快过OpenMP，至少三年前我测的时候是这样子
: 虚线是MPI，实线是OpenMP，超过32的部分不用去管
相关阅读
求教一个mathematica的pattern的问题compare double to float请教一个c++的问题一个perl bug,求救，谢谢！心似满月弓， 肚里干空空 (转载)请推荐一个画图工具来，出个题gbd调试时的一个简单问题 (转载)关于构造函数的一道测试题 (转载)如何最简单的获得一个随机字符串（PHP）？ (转载)Question简单python regular expression 问题求救要写一个user level thread librarymatlab读入数据的错误怎样在ssh窗口内显示颜色？java synchronized 问题ask for helphelp for interview question怎么样分配内存？c的小问题