L****8
发帖数: 3938 | 1 貌似不错啊 可以拼 GUP了
写 GPU code 太麻烦了 |
k****f
发帖数: 3794 | 2 gpu已经有很多轮子了，比cpu好用多
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
|
w***g
发帖数: 5958 | 3 价钱拼得过吗? 我是CPU党.
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
|
l*******m
发帖数: 1096 | 4 性能和amd估计差不多，价格比nvidia的企业级便宜些
【在 w***g 的大作中提到】
: 价钱拼得过吗? 我是CPU党.
|
N*****m
发帖数: 42603 | 5 larrabee重生？
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
|
l*******m
发帖数: 1096 | 6 cuda, nvcc都是binary. 如果cpu速度快些，轮子马上就多了。nvidia的优势是gamers
gpus价格低，一般人都能入手
【在 k****f 的大作中提到】
: gpu已经有很多轮子了，比cpu好用多
|
s******u
发帖数: 501 | 7 烂。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 太麻烦了
|
L****8
发帖数: 3938 | 8 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
|
c*******9
发帖数: 9032 | 9 72个远远不够呀。
gamers
【在 l*******m 的大作中提到】
: cuda, nvcc都是binary. 如果cpu速度快些，轮子马上就多了。nvidia的优势是gamers
: gpus价格低，一般人都能入手
|
w***g
发帖数: 5958 | 10 为啥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
|
|
|
m****0
发帖数: 229 | 11 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
|
w***g
发帖数: 5958 | 12 转apache license了, 可以跟进下. 就是写的code太难看, 只适合做比较底层的东西.
【在 m****0 的大作中提到】
: Intel自己的TBB怎么样？
|
L****8
发帖数: 3938 | 13 用c++11的thread 就可以 临时开个72线程
每个负责图像的一块区域
自己写 很简单
【在 w***g 的大作中提到】
: 转apache license了, 可以跟进下. 就是写的code太难看, 只适合做比较底层的东西.
|
m****0
发帖数: 229 | 14 居然是这样
没用过没有概念
James自己还把CUDA,OpenCL,OpenMP鄙视一番
我还以为TBB写出来会比较high level
原来也没有好多少啊
【在 w***g 的大作中提到】
: 转apache license了, 可以跟进下. 就是写的code太难看, 只适合做比较底层的东西.
|
m****0
发帖数: 229 | 15 scaling如何？
【在 L****8 的大作中提到】
: 用c++11的thread 就可以 临时开个72线程
: 每个负责图像的一块区域
: 自己写 很简单
|
L****8
发帖数: 3938 | 16 我只试过12核cpu
【在 m****0 的大作中提到】
: scaling如何？
|
w***g
发帖数: 5958 | 17 现在也有lambda了. 但即便这样简洁性也还是比openmp差太远.
以前没有lambda时, 为了parallelize一点东西费老了劲了, 而那时
就有omp parallel for了. 所以我一直不用tbb.
为了一点点性能牺牲代码的优美性不值得.
我知道opencv是用tbb的.
【在 m****0 的大作中提到】
: 居然是这样
: 没用过没有概念
: James自己还把CUDA,OpenCL,OpenMP鄙视一番
: 我还以为TBB写出来会比较high level
: 原来也没有好多少啊
|
L****8
发帖数: 3938 | 18 是不是每个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
|
m****0
发帖数: 229 | 19 又看了一遍，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
|
k****i
发帖数: 101 | 20 nvda撕intc phi - no free-lunch for recompile & run
http://www.nvidia.com/object/justthefacts.html
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
|
|
|
k****i
发帖数: 101 | 21 clang在做cuda编译，用的sdk，driver还是closed的。
http://llvm.org/docs/CompileCudaWithLLVM.html
gamers
【在 l*******m 的大作中提到】
: cuda, nvcc都是binary. 如果cpu速度快些，轮子马上就多了。nvidia的优势是gamers
: gpus价格低，一般人都能入手
|
s******u
发帖数: 501 | 22 跟单线程运行比较，280个线程也就只有50-60x的speedup
【在 L****8 的大作中提到】
: 50-60x 是跟谁比较？
|
s******u
发帖数: 501 | 23 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优化好了就行.
|
s******u
发帖数: 501 | 24 没拿TBB写过并行程序，所以不敢说。我听说的是TBB更适合task并行，而不是data并行
，所以也许并不适合通常的数值计算。当然只是听说，不负责任，呵呵
【在 m****0 的大作中提到】
: Intel自己的TBB怎么样？
|
s******u
发帖数: 501 | 25 MIC有各种的绑定方法，比方说先每个核心塞一个线程，塞满之后再往每个核心赛第二
个线程，或者是每个核心先塞满四个线程，再接着塞下一个核心等等。我说50-60x已经
是最好的情况下了
【在 L****8 的大作中提到】
: 是不是每个thread不能绑定到一个cpu core上？
|
p***o
发帖数: 1252 | 26 真诡异
【在 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
发帖数: 5958 | 27 你有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
|
L****8
发帖数: 3938 | 28 1.3GHz 72 core
是不是不如最新的 2块 xeon e5-2699 (每块22 core 2.30GHz ) ?
有16G作为L3 cache 是不是比普通的xeon 快呢？
【在 s******u 的大作中提到】
: 跟单线程运行比较，280个线程也就只有50-60x的speedup
|
s******u
发帖数: 501 | 29 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到什么程度？
|
w***g
发帖数: 5958 | 30 你这么一说我突然想起来, openMPI用的是轮询, 只要一跑上, 不管有没有算东西,
CPU都是100%. openmpi比openmp快可能和这个有关.
【在 s******u 的大作中提到】
: MIC有各种的绑定方法，比方说先每个核心塞一个线程，塞满之后再往每个核心赛第二
: 个线程，或者是每个核心先塞满四个线程，再接着塞下一个核心等等。我说50-60x已经
: 是最好的情况下了
|
|
|
w***g
发帖数: 5958 | 31 我还见过一上来就把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
|
s******u
发帖数: 501 | 32 你可以去试一下，单机上跑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干掉我觉得也很
: 牛.
|
w***g
发帖数: 5958 | 33 fftw还真有MPI!
【在 s******u 的大作中提到】
: 你可以去试一下，单机上跑fftw，MPI一点都不比OpenMP差，是不是更好我倒是忘记了
: ，很久以前跑的。有两个以上的node，比方说32x2或者32x4的话纯MPI就不行了，不过
: 这个也许跟MPI的实现和硬件有更大的关系。3d FFT的transpose要用到alltoall，如果
: 优化不好的话这个是最大的性能瓶颈
: benchmark我找找看
|
s******u
发帖数: 501 | 34 而且MPI版本的fftw远远快过OpenMP，至少三年前我测的时候是这样子
虚线是MPI，实线是OpenMP，超过32的部分不用去管
【在 w***g 的大作中提到】
: fftw还真有MPI!
|
s******u
发帖数: 501 | 35 嗯，我记得是一次memory load然后做几十次到上百次运算的才能做到CPU bound？一般
哪有这么多，我见过的几乎都是memory bound的
【在 w***g 的大作中提到】
: 我还见过一上来就把hyperthreading关掉的人. 我自己写的C++程序, 90%的情况
: 用perf进去看最慢的指令, 都是在等数据. 或者说能做的优化做完以后, 一般就
: 都变成内存瓶颈了.
|
s******u
发帖数: 501 | 36 有一点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 快呢？
|
L****8
发帖数: 3938 | 37 看了一下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了
|
w***g
发帖数: 5958 | 38 比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
|
k****f
发帖数: 3794 | 39 intel买了altera，以后可以cpu嵌入fpga，用fpga优化矩阵乘法和卷积，比gpu会快不
少的。不过fpga程序可就难多了，需要有人造好轮子。
【在 w***g 的大作中提到】
: 比deep learning 没太大意义啊. 第一价钱肯定比不过. 第二deep learning框架
: 都很成熟了, 根本不需要自己写gpu代码. 所有人都已经在GPU上搞了, 要回x86
: 反而有barrier.
: 手写新算法, x86要比GPU容易得多. 这个还是很有吸引力的.
: GPU内存优化太啰嗦. 这个一般人搞不定 (其实是我自己搞不定, 推广到一般人了.)
|
r******y
发帖数: 3838 | 40 fpga用functional programming很简便。
【在 k****f 的大作中提到】
: intel买了altera，以后可以cpu嵌入fpga，用fpga优化矩阵乘法和卷积，比gpu会快不
: 少的。不过fpga程序可就难多了，需要有人造好轮子。
|
|
|
w***g
发帖数: 5958 | 41 说了好多年了. 我几年前写deep learning框架的时候就指着这个, 没有上GPU.
结果到现在还没有出来.
【在 k****f 的大作中提到】
: intel买了altera，以后可以cpu嵌入fpga，用fpga优化矩阵乘法和卷积，比gpu会快不
: 少的。不过fpga程序可就难多了，需要有人造好轮子。
|
s****a
发帖数: 238 | 42 你肯定搞的定，就是不值得花这个精力而已，非常distracting
【在 w***g 的大作中提到】
: 比deep learning 没太大意义啊. 第一价钱肯定比不过. 第二deep learning框架
: 都很成熟了, 根本不需要自己写gpu代码. 所有人都已经在GPU上搞了, 要回x86
: 反而有barrier.
: 手写新算法, x86要比GPU容易得多. 这个还是很有吸引力的.
: GPU内存优化太啰嗦. 这个一般人搞不定 (其实是我自己搞不定, 推广到一般人了.)
|
l*******m
发帖数: 1096 | 43 FPGA主频太低了，gpu的1/5 ～1/3. fpu和memory io都没优势。每个layer/opt做完后
， 基本要同步到主内存里，inference可能还有些优化可能，training太复杂了
FPGA就是省电，对个人用户没有任何意义。
【在 k****f 的大作中提到】
: intel买了altera，以后可以cpu嵌入fpga，用fpga优化矩阵乘法和卷积，比gpu会快不
: 少的。不过fpga程序可就难多了，需要有人造好轮子。
|
y**b
发帖数: 10166 | 44 超级计算机，几千上万个节点的，基本都关掉超线程，普遍认为超线程对科学计算没有
帮助。
就是工作站，超线程对一个job也没啥帮助，除非同时运行两个job，假设一个job指16
核工作站上的一个16线程任务。如果一个job采用32线程，性能反而下降。估计超级计
算机考虑到这个因素，刻意关掉超线程。
perf是指perfsuite吗？
【在 w***g 的大作中提到】
: 我还见过一上来就把hyperthreading关掉的人. 我自己写的C++程序, 90%的情况
: 用perf进去看最慢的指令, 都是在等数据. 或者说能做的优化做完以后, 一般就
: 都变成内存瓶颈了.
|
y**b
发帖数: 10166 | 45 这个CPU bound Vs memory bound 一般用什么软件测试？
【在 s******u 的大作中提到】
: 嗯，我记得是一次memory load然后做几十次到上百次运算的才能做到CPU bound？一般
: 哪有这么多，我见过的几乎都是memory bound的
|
y**b
发帖数: 10166 | 46 有啥解释吗？
是总体上跟以下因素有关？
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
发帖数: 501 | 47 好点的performance profiling tool，像allinea map，可以给出来一段时间内多少个
cycle是在等memory access，多少个cycle是在做运算等等
【在 y**b 的大作中提到】
: 这个CPU bound Vs memory bound 一般用什么软件测试？
|
w***g
发帖数: 5958 | 48 就是linux自带那个perf record perf report那个. 自从linux 3.x有了perf
就把oprofile扔掉了.
16
【在 y**b 的大作中提到】
: 超级计算机，几千上万个节点的，基本都关掉超线程，普遍认为超线程对科学计算没有
: 帮助。
: 就是工作站，超线程对一个job也没啥帮助，除非同时运行两个job，假设一个job指16
: 核工作站上的一个16线程任务。如果一个job采用32线程，性能反而下降。估计超级计
: 算机考虑到这个因素，刻意关掉超线程。
: perf是指perfsuite吗？
|
b*******s
发帖数: 5216 | 49 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
|
b*******s
发帖数: 5216 | 50 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吗？
|
|
|
s******u
发帖数: 501 | 51 这个跟pcie有什么关系？
【在 b*******s 的大作中提到】
: did you count in PCIe transfer?
|
l*******m
发帖数: 1096 | 52 Intel 有新动作
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
|
m********5
发帖数: 17667 | 53 我更喜欢CPU
能做的事情比GPU多太多了，还能轻松扩展到集群，GPU限制则很大，好多库都不能用。
不过这玩意儿没用过，谁能搞个测评就好了。
【在 L****8 的大作中提到】
: 貌似不错啊 可以拼 GUP了
: 写 GPU code 太麻烦了
|
m********5
发帖数: 17667 | 54 我一铁哥们儿就专门搞这个的
除了特殊的信号处理领域，没啥太大意义，等你FPGA调好，CPU和GPU又不知道便宜了多
少。Intel是想搞个通用库，大家要用的时候它自动优化生成HDVL, 但按照我的经验来
说，这非常困难，FPGA之所以快，就是要针对特殊应用手工优化的。
【在 k****f 的大作中提到】
: intel买了altera，以后可以cpu嵌入fpga，用fpga优化矩阵乘法和卷积，比gpu会快不
: 少的。不过fpga程序可就难多了，需要有人造好轮子。
|
m********5
发帖数: 17667 | 55 单机是这样？！
太奇怪了，我没单独测试过fftw, 我自己的程序测出来都是MPI慢不少，可能我通讯多
了点。该不会是fftw实现的时候openMP有什么锁，而MPI是都有自己的数据拷贝，没有
锁导致的？
【在 s******u 的大作中提到】
: 而且MPI版本的fftw远远快过OpenMP，至少三年前我测的时候是这样子
: 虚线是MPI，实线是OpenMP，超过32的部分不用去管
|
