Chiphell - 分享与交流用户体验

 找回密码
 加入我们
搜索
      
查看: 17527|回复: 130

CUDA到底能走多远?

[复制链接]
发表于 2009-8-27 17:22 | 显示全部楼层 |阅读模式
这两天闲着没事,突然发现PCI新开了个显卡达人,还有一篇CUDA的辩论帖……本人小白,高度没到那水平,而且那是7月初的事情了(看来偶很久木有看PCI非交易区的东西了),就不再去参乎了……

CHH牛人多,不过我想跟我一样半小白也不少,发个帖子让大家拍拍砖指正一下也好……

CUDA的东西,对我来说似乎太高深了一点,按照我的理解,打个简单点的比方来说明一下(理解不对的请各位指正):

1、Intel做的CPU只能进行混合加减运算,例如3+4-(5+1)这样的,而我们要做乘法运算5×4.因为CPU不支持乘法,所以我们只能用软件来实现乘法的算法:5+5+5+5.性能稍微慢点(要算3次),这个也没什么问题,但现在我们要做算1×1+2×2+……+100×100。这下惨了,算的太慢了……

2、以前Intel可以加快CPU的计算速度,所以大家也就忍忍等下一代CPU出来。等不及的用两个、四个、……、很多个CPU一块算。问题是Intel的CPU现在不能再快了,于是Intel把两个/四个CPU做在一起卖。当然了,习惯了只用一个CPU计算的,还是很慢。

3、NV做了一个专门做乘法计算的东西,叫GPU,算乘法很快,而且可以同时做10次乘法运算(恩,ATi也有这样的东西)。于是1×1+2×2+……100×100,很快就能算出结果来……于是NV说,既然我的GPU也能算数,而且比Intel的CPU快,那我可以抢Intel的饭碗了。于是弄了个CUDA出来:大家算数的时候,把所有的乘法都提取出来,都交给GPU去算,就让CPU去算加和减就好了。

4、NV忽悠了很多人,于是很多人都把自己要算数里面的乘法都单独拿出去,让NV的GPU去算……恩,补充一下,NV的GPU有很多型号,有可以同时做10次乘法的,也有同时只能做8次乘法的,也有同时只能做4次乘法的……,所以用CUDA的话,为了达到最高效率,把乘法挑出来这部工作,似乎有点痛苦。这次好不容易挑好了,NV又出来个同时可以算20次乘法的……

5、Intel不服气,不就算乘法么?于是弄了个Larrabee,干的事情跟NV的GPU差不多,虽然乘法没有NV算的快,不过Larrabee还能算加减哦(就是不能带括号)……只要不带括号的算式,或者算式在括号里面的部分,都可以直接给Larrabee去算,不用单独把乘法挑出来……而且因为本来就用括号分隔的,Intel很容易就做了个编译器,编译器可以自动把括号里面的东西交给Larrabee去算,所以大家直接输入原来的算式就可以了。

6、AMD?AMD自己既有CPU,也有算专门乘法的GPU。AMD似乎什么没干,等着MS做一个叫DirectCompute的超级牛X的计算器(软件,只能跑在Windows平台),那个计算器可以自己把乘法挑出去让GPU算……AMD自己支持这个计算器就好了……Windows以外的,有另外一个计算器叫OpenCL,AMD也支持的……

以上是现状,将来么?不知道,如果NV能让CUDA接受到一条算式就能够自动把乘法都挑出来让GPU去算,那么应该会是NV赢……或者Intel能让Larrabee算乘法比NV的GPU快,那么Intel会赢……如果大家都用MS的DirectCompute计算器或者OpenCL算数,AMD还有点机会(只要AMD的GPU乘法算的足够快)
发表于 2009-8-27 17:31 | 显示全部楼层
NV的CUDA应用面比A卡广.
好消息是BOINC的6.10版准备支持A卡了
发表于 2009-8-27 17:32 | 显示全部楼层
*/-27完全不懂
发表于 2009-8-27 17:41 | 显示全部楼层
本帖最后由 AFXIF 于 2009-8-27 17:48 编辑

其实不用比喻,GPGPU的运算特性类似于DSP。
DSP是现成就有的东西。

比较一下就是,DSP适合于用同一段简短的指令处理大批数据,而CPU则是适合用复杂的指令处理一段数据。
 楼主| 发表于 2009-8-27 17:43 | 显示全部楼层
NV的CUDA应用面比A卡广.
好消息是BOINC的6.10版准备支持A卡了
ld0891 发表于 2009-8-27 17:31


应用面广么?我觉得要说现在支持CUDA的应用更多比较合适一点……

理论上来说,用CUDA API能实现的应用,OpenCL/DirectCompute也能实现,也许在N卡上性能不如CUDA,但可以很方便就移植到A卡,甚至Cell/Larrabee上。不过CUDA先行,现在支持CUDA的应用更多倒是真的。
发表于 2009-8-27 17:59 | 显示全部楼层
本帖最后由 minnow 于 2009-8-27 18:05 编辑

cuda没戏,你硬件在nb也得有软件支持才行,由传统的程序转移到cuda上花费的成本还是很可观的,所以大家基本都不鸟cuda。
发表于 2009-8-27 17:59 | 显示全部楼层
没有N卡,更不知道CUDA的作用
发表于 2009-8-27 18:01 | 显示全部楼层
OpenCL确实有一个优点就是不需要一定具备GPGPU就可以全功能实现。
一个软件调用了CUDA的,没有NV的GPU就用不到这个了。
但是调用的OpenCL的,有GPU可以用GPU,没有GPU可以用CPU,适合GPU的调度给GPU,适合给CPU的调度给CPU,都能干的CPU、GPU个各分一半;甚至某个调用在这个i7+9500GT的配置上是自动选择CPU实现,另一个E4200+GTX285的配置上是自动选择GPU实现,全是可以实现优化配置的。
所以给OpenCL写软件本身就没有什么后顾之忧了,大不了应用慢一点,没有什么不支持的。
发表于 2009-8-27 18:02 | 显示全部楼层
这些东西都是要看推广力度的     如果推广力度不足  再先进的东西都不能成为主流    nv推cuda已经有一段时间  但是nv的影响力明显不够大。。。其实nv还是很有勇气了  敢主动抢intel的饭碗  导致自己的平台被打压   intel的显卡尚处于起步阶段 不过以其垄断力量来看成为主流的机会不少  amd则有完整的cpu和gpu方案  啥都不缺但是缺钱  总的来讲3个方案都有其优势劣势    谁能抓住人们的需要谁就成功了
发表于 2009-8-27 18:04 | 显示全部楼层
cuda我研究过一段时间,向并发式的程序设计转移还是挺痛苦的。
计算能力是有显著提高,不过那是建立在你可以让你的程序充分的并发执行的基础上,否则比cpu还慢。
发表于 2009-8-27 18:06 | 显示全部楼层
CUDA目前还不能自己养活自己……
 楼主| 发表于 2009-8-27 18:19 | 显示全部楼层
本帖最后由 harley 于 2009-8-27 18:21 编辑
这些东西都是要看推广力度的     如果推广力度不足  再先进的东西都不能成为主流    nv推cuda已经有一段时间  但是nv的影响力明显不够大。。。其实nv还是很有勇气了  敢主动抢intel的饭碗  导致自己的平台被打压   i ...
superrugal 发表于 2009-8-27 18:02


推广力度的确很重要,但即使不需要东西是最好的,也不能太烂的。

CUDA的推广,NV本身在HPC的影响力不够大固然是一方面,但最重要的我认为还是已有程序的移植/优化的难度太高。也许从头开始编写一两个小程序无所谓,但如果是一个大的HPC项目,需要上千人月甚至更大的编码工作量的时候,这个问题就很明显了。

当然,CUDA毕竟是新东西,要一下子就成熟起来,是不可能的。只不过现在Intel将要提供了另一种方式,到底哪种方式可以先占据市场,这个真的不好说。

另外,AMD不是什么都不缺,AMD缺乏的是一套方便而且完整的编译器。
发表于 2009-8-27 18:38 | 显示全部楼层
学过FPGA的就能很容易明白LZ这段话什么意思了。
发表于 2009-8-27 18:47 | 显示全部楼层
的确,CUDA效率问题一直都有。当然完全优化后速度是很IMBA……不过这个开发成本……
现在用CUDA的程序貌似大部分都是NV自己贴钱别人才做的
至于CUDA能走多远,个人认为牌子能走下去,里面的东西就难说了
发表于 2009-8-27 19:45 | 显示全部楼层
现在CUDA的程序都是本来就很适合并发运算的程序。
发表于 2009-8-27 19:51 | 显示全部楼层

关键是你要有称手的 SDK, 要有足够的美刀去推广, 学习成本尽量低

这些都是 CUDA 现在的优点...

要做到很高性能固然要求对 HPC 有很深的理解, 对并行开发很有经验

但是 SDK 够强的话能省掉很多事, 不谈科学计算, 看看现在的转码吧...
发表于 2009-8-27 20:11 | 显示全部楼层
太高深。。路过看看*/-91
发表于 2009-8-27 20:21 | 显示全部楼层
起码CUDA让NV赚了钱。。。。
发表于 2009-8-27 20:38 | 显示全部楼层
按nvidia的说法
HD4870 是800个BB gun
GTX285 是240个machine gun
core i7  是4个canon
发表于 2009-8-27 21:06 | 显示全部楼层
个人感觉,CUDA如果大规模使用的话,可能会在很长时间之后。4核CPU出现这么长时间了,但是真正对应4核心优化的程序比例有多少?更何况CUDA这个新结构了。Nvidia再怎么花力气,总不会比Intel+AMD都强吧
 楼主| 发表于 2009-8-27 21:35 | 显示全部楼层
关键是你要有称手的 SDK, 要有足够的美刀去推广, 学习成本尽量低

这些都是 CUDA 现在的优点...

要做到很高性能固然要求对 HPC 有很深的理解, 对并行开发很有经验

但是 SDK 够强的话能省掉很多事, 不谈科学 ...
挪威的冬天 发表于 2009-8-27 19:51


说实话,看了一下文档(没有实际编程过),其实CUDA的SDK已经相当方便了。如果有HPC开发经验,并且有一定建模能力的话,应该学起来也很快。

问题在于两个,一个是已有的程序,要以CUDA运行并且能发挥CUDA性能的话,很多地方要重写。视频转码软件才多大?重新写的工作量还是可以接受的。但对于一些大量数据而且超复杂计算的,那就不好说了。而且还有后期的维护,Debug之类的。

最理想的情况,是NV只给出一个CUDA编译器,可以自动分析代码,并把里面可以并行执行的部分编译成GPU执行,CUDA对程序员来说完全透明。不过要走到这一步,NV还有很多工作要做,很长一段路要走倒是真的。
发表于 2009-8-27 21:45 | 显示全部楼层
自动并行化,很早就被证明是个NP 问题。
发表于 2009-8-27 22:23 | 显示全部楼层
我一直觉得,现在GPU的编程模型,包括CUDA,就是把for循环并行化。我问NV的哥们这个问题,说来说去,也还是没有证明GPU能做的更多。

CUDA的层次比AMD的stream sdk要高很多,实际上AMD的CAL,甚至OpenCL,都可以看成是一个中间语言,诸如CUDA这样的高级语言可以构建在其之上。这实际上可以看出A和N不同的思路,N要包办一切,而A要构建一个生态圈,只提供底层的运行库支持,高级语言可以由社区或者其他公司去做。
 楼主| 发表于 2009-8-27 22:24 | 显示全部楼层
本帖最后由 harley 于 2009-8-27 22:25 编辑
自动并行化,很早就被证明是个NP 问题。
tomsmith 发表于 2009-8-27 21:45


的确是这样,偶NC了……

不过有没有可能有一个编译器对于类似这样的代码段,

  1. for(int i=0,j=0;i<size;i++)
  2. {
  3.     j = floor(N*R1);
  4.     I = N - j*IDIM;
  5.     J = j;
  6. }
复制代码
自动转换为类似这样的GPU代码呢?

  1. __global__ void kernel2(int *N,int *I,int *J,int IDIM,int JDIM)
  2. {
  3.     int tid = blockIdx.x*blockDim.x+threadIdx.x;
  4.     int n,j;
  5.     if(tid<IDIM*JDIM)
  6.     {
  7.         n = N[tid];
  8.         j = floor(n*R1);
  9.         I[tid] = n-j*IDIM;
  10.         J[tid] = j;
  11.     }
  12. }   
复制代码
不需要是最优的解决方案,也不需要完全发挥GPU的性能,更加不需要把所有可并行化的地方都并行化。只要程序员不需要为了CUDA而去大幅修改程序,就能发挥GPU的部分性能,那么CUDA的前景还是一片光明的。即使是LRB,也不可能说现有程序完全不动,只要重新编译就能发挥LRB 80%以上的性能。
发表于 2009-8-27 22:24 | 显示全部楼层
OpenCL确实有一个优点就是不需要一定具备GPGPU就可以全功能实现。
一个软件调用了CUDA的,没有NV的GPU就用不到这个了。
但是调用的OpenCL的,有GPU可以用GPU,没有GPU可以用CPU,适合GPU的调度给GPU,适合给CPU的调 ...
AFXIF 发表于 2009-8-27 18:01


貌似CUDA也有many core的版本,可以跑在CPU上
 楼主| 发表于 2009-8-27 22:32 | 显示全部楼层
我一直觉得,现在GPU的编程模型,包括CUDA,就是把for循环并行化。我问NV的哥们这个问题,说来说去,也还是没有证明GPU能做的更多。

CUDA的层次比AMD的stream sdk要高很多,实际上AMD的CAL,甚至OpenCL,都可以看 ...
savage 发表于 2009-8-27 22:23


呵呵,偶滴理解是GPU本来就不可能比CPU做得多……不过可以做的比CPU快而已……至于for循环并行化,这个本来就是多线程编程的一个典型例子。

至于整个生态圈的问题,我个人认为还是很有必要的。否则Intel不会一直费力气去搞一系列的Intel XX Complier出来……
 楼主| 发表于 2009-8-27 22:34 | 显示全部楼层
貌似CUDA也有many core的版本,可以跑在CPU上
savage 发表于 2009-8-27 22:24


好像是emu模式,Debug用的,CUDA现在还不支持Debug
发表于 2009-8-27 22:36 | 显示全部楼层
我一直觉得,现在GPU的编程模型,包括CUDA,就是把for循环并行化。我问NV的哥们这个问题,说来说去,也还是没有证明GPU能做的更多。

CUDA的层次比AMD的stream sdk要高很多,实际上AMD的CAL,甚至OpenCL,都可以看 ...
savage 发表于 2009-8-27 22:23

A的通用运算=0
最新的A记SDK已经放弃对CAL的支持
发表于 2009-8-27 22:38 | 显示全部楼层
CUDA前途是无量的,NV默默耕耘了几年,据业内朋友说,国内以中科院为代表的多个院所、研究院已经在全面普及CUDA和Tesla

Intel如果不担心,完全没必要作LRB
发表于 2009-8-27 22:41 | 显示全部楼层
出现内存和显存在用DMA玩接传球的话这个程序效率就悲剧了……
而larrabee的优点是很多情况下不需要接传球,核心是完整的CPU(虽然单线程性能不怎么样),很多情况下就能满足需要。
您需要登录后才可以回帖 登录 | 加入我们

本版积分规则

小黑屋|手机版|Archiver|Chiphell ( 沪ICP备12027953号-5 )沪公网备310112100042806 上海市互联网违法与不良信息举报中心

GMT+8, 2020-11-29 16:29 , Processed in 0.012197 second(s), 20 queries , Gzip On, Redis On.

Powered by Discuz! X3.2

© 2007-2020 Chiphell.com All rights reserved.

快速回复 返回顶部 返回列表