G**Y
发帖数: 33224 | |
J**G
发帖数: 225 | 2 那得看程序优化的怎么样吧
【在 G**Y 的大作中提到】
: 大致的数量级？
: 10倍，100倍？
: 问问？
|
G**Y
发帖数: 33224 | 3 GPU主要能算点啥？
线性代数？
【在 J**G 的大作中提到】
: 那得看程序优化的怎么样吧
|
a******1
发帖数: 2340 | |
i******t
发帖数: 22541 | 5 我知道的 就是5-10倍的样子
当然有更快的 我就不知道了 |
w********r
发帖数: 14958 | 6 有篇paper， 大概是说，通过最好的优化，也就是5倍的样子。 |
E***e
发帖数: 3430 | 7 http://www.mathworks.com/products/distriben/examples.html?file=
随便哪个结果，你觉得CPU上10秒以内能跑完？
【在 w********r 的大作中提到】
: 有篇paper， 大概是说，通过最好的优化，也就是5倍的样子。
|
r******n
发帖数: 4522 | 8 我比较过，GPU单core的纯运算速度大概是CPU单core的1/20, 具体CPU频率跟显卡档次
不同肯定有出入，但应该就在这个数量级。GPU通常有几百个core, CPU4-8吧，这样下
来纯算力GPU也就是5-10倍。但GPU内存小，通常得搬进搬出地算，还有分布后同步啥的
，许多额外开销，所以能到5已经很不错了，还得是小数据，数据量大的GPU可能时间都
浪费在搬家上，还不如CPU。但GPU堆起来比CPU容易可以插很多。 |
i******t
发帖数: 22541 | 9 技术还在发展嘛
你说的这些问题 估计gpu也带改进了
如果经过一阵发展 能达到快5倍的话 也是很不错的提高啊 对吧
我个人还是觉得gpu是个趋势， 我倒没说 他一定比cpu好 或者占绝对优势
我的意思 这个是很不错的一个提高和可选择办法
【在 r******n 的大作中提到】
: 我比较过，GPU单core的纯运算速度大概是CPU单core的1/20, 具体CPU频率跟显卡档次
: 不同肯定有出入，但应该就在这个数量级。GPU通常有几百个core, CPU4-8吧，这样下
: 来纯算力GPU也就是5-10倍。但GPU内存小，通常得搬进搬出地算，还有分布后同步啥的
: ，许多额外开销，所以能到5已经很不错了，还得是小数据，数据量大的GPU可能时间都
: 浪费在搬家上，还不如CPU。但GPU堆起来比CPU容易可以插很多。
|
k*z
发帖数: 4704 | |
|
|
S******n
发帖数: 5022 | 11 intel搞过，项目（larrabee）失败转型（Xeon phi）了。
【在 k*z 的大作中提到】
: 有那个钱为啥不把CPU搞成几百个core的？
|
z***s
发帖数: 3241 | 12 啊 gpu都几百核了？ 我也太out了。。。。
voodoo时代的人就是要被淘汰啊。
【在 r******n 的大作中提到】
: 我比较过，GPU单core的纯运算速度大概是CPU单core的1/20, 具体CPU频率跟显卡档次
: 不同肯定有出入，但应该就在这个数量级。GPU通常有几百个core, CPU4-8吧，这样下
: 来纯算力GPU也就是5-10倍。但GPU内存小，通常得搬进搬出地算，还有分布后同步啥的
: ，许多额外开销，所以能到5已经很不错了，还得是小数据，数据量大的GPU可能时间都
: 浪费在搬家上，还不如CPU。但GPU堆起来比CPU容易可以插很多。
|
E***e
发帖数: 3430 | 13 几千核了
http://en.wikipedia.org/wiki/GTX_Titan#GeForce_700_.287xx.29_se
【在 z***s 的大作中提到】
: 啊 gpu都几百核了？ 我也太out了。。。。
: voodoo时代的人就是要被淘汰啊。
|
S******n
发帖数: 5022 | |
E***e
发帖数: 3430 | 15 现在关键看双精度和library了。。。
OpenCL下还是找不到类似CUDA Math和CULA的library
上次AMD公开的那个看了半天也就是个BLAS而已，别的啥都没有
【在 S******n 的大作中提到】
: 6000核 指日可待。
|
S******n
发帖数: 5022 | 16 http://news.mydrivers.com/1/279/279815.htm
【在 E***e 的大作中提到】
: 现在关键看双精度和library了。。。
: OpenCL下还是找不到类似CUDA Math和CULA的library
: 上次AMD公开的那个看了半天也就是个BLAS而已，别的啥都没有
|
h******6
发帖数: 2697 | 17 这个完全是看原来的算法可并行化的程度 原算法并行度高的改成GPU的程序优化之后几
百倍的提速是很常见的 另外 这个也取决于你用的什么GPU和什么CPU来比 这里的问题
并不是简单地你把随便一个算法或者程序拿过来放到一个GPU上跑测下时间 然后拿到
CPU上跑测下时间 然后比较两个时间
GPU计算现在还没办法普及 最主要是因为把一个算法在GPU上实现需要很有经验的程序
员才行 涉及到重新设计算法以及内存使用上的分配 目前的几个能自动把串行程序编译
成并行程序的compiler都效率非常低下 所以单纯问GPU计算比CPU计算快几倍是没有意
义的 |
S******n
发帖数: 5022 | 18 NVIDIA正式宣布CUDA 6：支持统一寻址！
NVIDIA今天(2013-11-15)正式宣布了最新版并行计算开发工具CUDA 6，相比此前的CUDA
5.5有着革命性的巨大进步。
NVIDIA表示，CUDA 6可以让并行编程前所未有的轻松，能够显著节省开发人员的时间和
精力，而通过GPU加速可带来最多8倍于CPU模式的性能提升。
CUDA 6的关键新特性包括：
1、统一寻址(Unified Memory)：
可直接访问CPU内存、GPU显存，无需在彼此之间手动拷贝数据，可在大量编程语言中更
简单地添加GPU加速支持。
其实CUDA 4就开始支持统一虚拟寻址，x86 CPU、GPU内存池可在同一空间内进行寻址，
但那仅仅是简单的内存管理，摆脱不了手动数据转移。
CUDA 6则在现有的内存池结构上增加了一个统一内存系统，程序员可以直接访问任何内
存/显存资源，或者在合法的内存空间内寻址，而不用管涉及到的到底是内存还是显存。
不过注意，CUDA 6并不是完全不需要数据拷贝，只不过将这个工作从程序员那里接过来
自动执行而已，它仍然受制于PCI-E的带宽和延迟，因此和AMD hUMA异构统一寻址架构
是不一样的。
另外值得一提的是，NVIDIA此前已经宣布下代GPU Maxwell将会支持统一虚拟内存，但
它要到明年才会发布。NVIDIA表示，他们找到了完全通过软件执行统一内存的方法，所
以就提前这么做了，Maxwell则会有某种硬件层面的统一内存技术(或许性能更高)，但
具体细节还有待公布。
2、替换库(Drop-in Libraries)：
简单地用GPU加速库替换已有的CPU库，BLAS(基础线性代数程序集)、FFTW(快速傅立叶
变换)计算即自动提速最多8倍。
3、多GPU支持(Multi-GPU Scaling)：
重新设计的BLAS、FFT GPU库，单个节点可自动支持最多八颗GPU，双精度浮点性能可超
过9TFlops，并且支持最多512GB的更大负载。
此外，CUDA 6平台还会提供一整套的编程工具、GPU加速数学库、文档和编程指导。
CUDA 6目前只是纸面宣布，2014年初才会开放下载。
【在 h******6 的大作中提到】
: 这个完全是看原来的算法可并行化的程度 原算法并行度高的改成GPU的程序优化之后几
: 百倍的提速是很常见的 另外 这个也取决于你用的什么GPU和什么CPU来比 这里的问题
: 并不是简单地你把随便一个算法或者程序拿过来放到一个GPU上跑测下时间 然后拿到
: CPU上跑测下时间 然后比较两个时间
: GPU计算现在还没办法普及 最主要是因为把一个算法在GPU上实现需要很有经验的程序
: 员才行 涉及到重新设计算法以及内存使用上的分配 目前的几个能自动把串行程序编译
: 成并行程序的compiler都效率非常低下 所以单纯问GPU计算比CPU计算快几倍是没有意
: 义的
|
E***e
发帖数: 3430 | |
j*******n
发帖数: 461 | 20 我上次挖矿bitcoin,用CPU和GPU分别试了一下,差别还是蛮大的:
CPU i7 4770k: 1Mps
GPU AMD 7950: 500Mps |
|
|
S******n
发帖数: 5022 | 21 intel说以后会在Xeon phi中集成一个独立的能boot system的CPU。
以后就是一张卡，一个64位CPU（2-12核不等）外加近百个x86 cores. |
E***e
发帖数: 3430 | 22 这条路基本走死了。。。
【在 S******n 的大作中提到】
: intel说以后会在Xeon phi中集成一个独立的能boot system的CPU。
: 以后就是一张卡，一个64位CPU（2-12核不等）外加近百个x86 cores.
|
r******n
发帖数: 4522 | 23 挖BTC是特例，基本靠堆core, A卡还比N卡快得多呢。
【在 j*******n 的大作中提到】
: 我上次挖矿bitcoin,用CPU和GPU分别试了一下,差别还是蛮大的:
: CPU i7 4770k: 1Mps
: GPU AMD 7950: 500Mps
|
x********o
发帖数: 2092 | 24 以前GPU对应单核或者双核的CPU有很大的优势，现在intel Xeon i7系列一颗CPU可以10
个core 20个thread，一个服务器加四个CPU很轻松到80个thread。 做计算的几乎所有
的代码都是对CPU优化，再加上内存，CPU做计算不用花多少时间就可以了。 |
E***e
发帖数: 3430 | 25 要看计算性质了
CPU多线程的overhead随核数增加太快
几百个核的CPU Grid，做monte carlo都干不过GPU
别说才80个thread了
当然很多矩阵运算，并行性质没那么突出的，还是CPU Grid更有优势。
10
【在 x********o 的大作中提到】
: 以前GPU对应单核或者双核的CPU有很大的优势，现在intel Xeon i7系列一颗CPU可以10
: 个core 20个thread，一个服务器加四个CPU很轻松到80个thread。 做计算的几乎所有
: 的代码都是对CPU优化，再加上内存，CPU做计算不用花多少时间就可以了。
|
O*******d
发帖数: 20343 | 26 可以平行运算的问题， GPU可以比CPU运算速度高百倍。 你首先要把计算问题分解成独
立的小单元，例如在图像处理中二维函数的计算，对应于每个像素，在很多情况下，其
计算是独立的，跟其它像素的数值无关，这种情况下，GPU大显神功。
【在 G**Y 的大作中提到】
: 大致的数量级？
: 10倍，100倍？
: 问问？
|
O*******d
发帖数: 20343 | 27 游戏是典型的GPU应用。 每个像素的计算基本上是独立的，例如计算色彩的混合，光线
的反射，前后物体的遮挡，像素点在空间的平移旋转，GPU可以轻易地每秒计算几千万
到上亿个像素值，CPU根本玩不转。 |
O*******d
发帖数: 20343 | 28 GPU的硬件，就是优化来做浮点运算的，所以特别适合解决数学问题。 所以GPU的算法
，最好少用branching，就是少用if-else。 每个计算单元不要太大太复杂。 例如像素
的颜色混合，就是把两种颜色按照你的意愿，混合成第三种颜色。 GPU的thread有上千
，并且启动thread的overhead基本是零。 如果你把问题分解成几百万个小单元，GPU
的几千个thread可以非常快速地扫过这几百万个单元。 |
E***e
发帖数: 3430 | 29 if else杀伤力有多大？我的应用虽然能并行但是也需要很多if else
还需要写min max之类的
这些有办法绕过嘛？
【在 O*******d 的大作中提到】
: GPU的硬件，就是优化来做浮点运算的，所以特别适合解决数学问题。 所以GPU的算法
: ，最好少用branching，就是少用if-else。 每个计算单元不要太大太复杂。 例如像素
: 的颜色混合，就是把两种颜色按照你的意愿，混合成第三种颜色。 GPU的thread有上千
: ，并且启动thread的overhead基本是零。 如果你把问题分解成几百万个小单元，GPU
: 的几千个thread可以非常快速地扫过这几百万个单元。
|
i******t
发帖数: 22541 | 30 恩
还是要看算法
看你能不能吧原来问题分解成独立的 如果能 性能肯定大幅度提高 否则 提高不大
所以说还是看1 问题 2算法
【在 h******6 的大作中提到】
: 这个完全是看原来的算法可并行化的程度 原算法并行度高的改成GPU的程序优化之后几
: 百倍的提速是很常见的 另外 这个也取决于你用的什么GPU和什么CPU来比 这里的问题
: 并不是简单地你把随便一个算法或者程序拿过来放到一个GPU上跑测下时间 然后拿到
: CPU上跑测下时间 然后比较两个时间
: GPU计算现在还没办法普及 最主要是因为把一个算法在GPU上实现需要很有经验的程序
: 员才行 涉及到重新设计算法以及内存使用上的分配 目前的几个能自动把串行程序编译
: 成并行程序的compiler都效率非常低下 所以单纯问GPU计算比CPU计算快几倍是没有意
: 义的
|
|
|
O*******d
发帖数: 20343 | 31 if-else的杀伤力到底有多大，我也不是很知道。 我读过的材料，一般都说要保持
kernel的code小，复杂度要低，最好是直接运算，不要把时间花在条件判断上。 如果
你要在kernel里运行循环，如果循环的次数是compile time已知的，最好把循环展开，
而不是每次要判断循环的次数。
适合GPU的数学问题，一般需要把复杂问题分解成独立的小单元。 如果每个单元比较复
杂，还需要进一步分解。 例如，给出一个一维函数值，给每个点做一个三次方插值，
给插的值赋予颜色，再把相邻的两个颜色做平均。 你需要写三个kernel function。
第一个做插值，第二个做赋予颜色，第三个做颜色平均。 每个kernel做的事情比较简
单。 用GPU把这三个kernel串联扫过去，每扫一次kernel时，例如插值，需要把插值
kernel在全部数值上完成，才走下一个kernel。 当然你需要考虑边界数值的问题，例
如在index是0时，或index是最大值时，插值的算法不太一样， 不要在kernel里考虑边
界值，只把非边界的数值送到GPU去计算，边界值用普通CPU来计算，这样你可以减少if
-else的使用
【在 E***e 的大作中提到】
: if else杀伤力有多大？我的应用虽然能并行但是也需要很多if else
: 还需要写min max之类的
: 这些有办法绕过嘛？
|
E***e
发帖数: 3430 | 32 看了大牛的描述，简单粗暴的原始人表示情绪十分稳定 lol
【在 O*******d 的大作中提到】
: if-else的杀伤力到底有多大，我也不是很知道。 我读过的材料，一般都说要保持
: kernel的code小，复杂度要低，最好是直接运算，不要把时间花在条件判断上。 如果
: 你要在kernel里运行循环，如果循环的次数是compile time已知的，最好把循环展开，
: 而不是每次要判断循环的次数。
: 适合GPU的数学问题，一般需要把复杂问题分解成独立的小单元。 如果每个单元比较复
: 杂，还需要进一步分解。 例如，给出一个一维函数值，给每个点做一个三次方插值，
: 给插的值赋予颜色，再把相邻的两个颜色做平均。 你需要写三个kernel function。
: 第一个做插值，第二个做赋予颜色，第三个做颜色平均。 每个kernel做的事情比较简
: 单。 用GPU把这三个kernel串联扫过去，每扫一次kernel时，例如插值，需要把插值
: kernel在全部数值上完成，才走下一个kernel。 当然你需要考虑边界数值的问题，例
|
a***e
发帖数: 27968 | 33 这年头GPU都是2560+ core了
【在 r******n 的大作中提到】
: 我比较过，GPU单core的纯运算速度大概是CPU单core的1/20, 具体CPU频率跟显卡档次
: 不同肯定有出入，但应该就在这个数量级。GPU通常有几百个core, CPU4-8吧，这样下
: 来纯算力GPU也就是5-10倍。但GPU内存小，通常得搬进搬出地算，还有分布后同步啥的
: ，许多额外开销，所以能到5已经很不错了，还得是小数据，数据量大的GPU可能时间都
: 浪费在搬家上，还不如CPU。但GPU堆起来比CPU容易可以插很多。
|
a***e
发帖数: 27968 | 34 天河2号上跑着48000快Xeon Phi,号称Top500 #1,比跑19000块Telsa的Titan快一倍
怎么就死了呢？
intel不知道怎么优化图形计算核，通用计算核丫还是很有一套的
【在 E***e 的大作中提到】
: 这条路基本走死了。。。
|
a***e
发帖数: 27968 | 35 你要是只做蒙特卡罗，还是上A卡巴
【在 E***e 的大作中提到】
: 要看计算性质了
: CPU多线程的overhead随核数增加太快
: 几百个核的CPU Grid，做monte carlo都干不过GPU
: 别说才80个thread了
: 当然很多矩阵运算，并行性质没那么突出的，还是CPU Grid更有优势。
:
: 10
|
E***e
发帖数: 3430 | 36 找几个数学函数有点烦人
不知道有没有比ArrayFire更好一点的
也不知道有没有类似CULA这样的东西。。。
唉
【在 a***e 的大作中提到】
: 你要是只做蒙特卡罗，还是上A卡巴
|
a***e
发帖数: 27968 | 37 关键看你想干什么
比如PHD拿它当工具，自己写点小code做计算模拟，
显然功能比性能重要，时间更重要
哪个容易写上哪个，就算真有性能5X的差距
不好写的debug的时间都比使用时间多
到时候调出来黄花菜都凉了
做R&D C&F的，也是时间重于性能，还是那个简单上哪个
商用的才有通用和终极性能方面的追求
CS HPC专业人员另说
蒙特卡罗，只要内存能对付过来，上哪个大部分情况都够用了
【在 E***e 的大作中提到】
: 找几个数学函数有点烦人
: 不知道有没有比ArrayFire更好一点的
: 也不知道有没有类似CULA这样的东西。。。
: 唉
|
d***a
发帖数: 13752 | 38 branch mis-prediction造成性能的损失是个动态值
看流水线的当前状态
一个branch mis-prediction的代价
能达到相当于上百条指令的执行时间
min/max用的简单if-else语句
可以用conditional execution取代branch
这个编译器能做，编程员不用操心
【在 E***e 的大作中提到】
: if else杀伤力有多大？我的应用虽然能并行但是也需要很多if else
: 还需要写min max之类的
: 这些有办法绕过嘛？
|
E***e
发帖数: 3430 | 39 if else有没有什么办法可以通过conditional execution取代branch？
其实都是很简单的if-else，数量倒是很不少。
【在 d***a 的大作中提到】
: branch mis-prediction造成性能的损失是个动态值
: 看流水线的当前状态
: 一个branch mis-prediction的代价
: 能达到相当于上百条指令的执行时间
: min/max用的简单if-else语句
: 可以用conditional execution取代branch
: 这个编译器能做，编程员不用操心
|
h******6
发帖数: 2697 | 40
这么说吧 当一部分线程执行if的时候 应该执行else的那些线程是idle的 然后开始执
行else 此时if的那部分线程是idle的 所以这部分被serialize的非常厉害（branch
divergence）性能也就大打折扣了 尤其是当if和else是被同一个warp里面的线程执行
的时候 总时间=if+else
没什么好办法避免 只能优化你的算法 比如把所有的if放到一起 所有else放到一起 尽
量减少serialization增大overlap的计算
【在 E***e 的大作中提到】
: if else杀伤力有多大？我的应用虽然能并行但是也需要很多if else
: 还需要写min max之类的
: 这些有办法绕过嘛？
|
|
|
E***e
发帖数: 3430 | 41 if it is just the time cost of "if+else", I could probably live with it...
Thanks a lot!
【在 h******6 的大作中提到】
:
: 这么说吧 当一部分线程执行if的时候 应该执行else的那些线程是idle的 然后开始执
: 行else 此时if的那部分线程是idle的 所以这部分被serialize的非常厉害（branch
: divergence）性能也就大打折扣了 尤其是当if和else是被同一个warp里面的线程执行
: 的时候 总时间=if+else
: 没什么好办法避免 只能优化你的算法 比如把所有的if放到一起 所有else放到一起 尽
: 量减少serialization增大overlap的计算
|
O*******d
发帖数: 20343 | 42 GPU不适合做有复杂逻辑的问题，最适合做直接暴力计算。 如果有复杂逻辑问题，需要
把问题分解成简单的小计算单元。 要知道， GUP的thread启动成本基本上是零。 可以
快速地对一个接一个的kernel计算。
给个例子。
你要种三种菜，莴笋，白菜，萝卜。 你有两种不同的种法。
1。 每棵莴笋白菜萝卜互相为邻，你播种上肥收割，三种菜同时管理。 这是把三个问
题合并在一个单元里。 你在处理每个单元时，要考虑莴笋白菜萝卜的不同处理方法。
2。把地分成三块，每块各种莴笋白菜萝卜。 他们的播种上肥收割是分开的。这是把三
个问题分开。先突击收割莴笋，再突击收割白菜，再突击收割萝卜。 GPU最适合这种方
式解决问题。 |
