POPPUR爱换

标题: 【转帖】NVIDIA：CUDA要走进大学课堂；Intel：GPGPU没有未来，CUDA只是历史过客 [打印本页]
作者: rtyou    时间: 2008-7-2 12:14
标题: 【转帖】NVIDIA：CUDA要走进大学课堂；Intel：GPGPU没有未来，CUDA只是历史过客
http://news.mydrivers.com/1/110/110050.htm
http://news.mydrivers.com/1/110/110056.htm
NVIDIA公司日前宣布，将向伊利诺伊大学Urbana-Champaign分校（UIUC）捐赠50万美元，并命名该校为全球首个CUDA卓越中心（CUDA Center of Excellence）。
这并不是NVIDIA首次向该校进行捐献。去年，NVIDIA就像UIUC的理论和计算生物物理学学科捐赠了32台QuadroPlex 4双GPU工作站，组成CUDA计算集群进行分子动力学研究。令该校成为首家利用GPU并行通用计算进行科学研究的高等学府之一。此次的CUDA卓越中心项目则是向致力于推广GPU并行运算的高校进行奖励，帮助学校在教学中向学生推广新的并行处理架构。
这样的礼遇实际并非UIUC独享。NVIDIA表示，如果高校希望成为CUDA卓越中心，只要在校内开设CUDA课程，并且科研工作中应用CUDA技术。NVIDIA就将对学校提供资金和设备支持，包括协助建设GPU集群高性能计算机。
有趣的事，UIUC全球首家CUDA卓越中心的首席研究员胡文美教授，其在伊利诺伊大学电气及计算机工程专业的首席教授教席是由AMD公司及其创始人桑德斯共同捐资设立的，这里也是桑德斯的母校。看来，NVIDIA和AMD这对冤家，在对高校科研人才的争夺中也想到了一起。
********************************************************
在宣布Intel迎来四十岁生日之后，Intel高级副总裁、数字企业部总经理Pat Gelsinger接受了媒体采访，期间声称CUDA技术最多不过是“计算历史长河中的一朵小浪花而已”。
他说：“计算历史上一再重复出现的一个问题是，有人想出了一个很酷的新点子，保证说会带来10倍、20倍的性能提升，但你必须面对全新编程模型的麻烦，而在通用计算模型问题上，这一障碍是无法克服的。”
Gelsinger以Cell处理器架构为例证明其观点：“它确实是一个全新的计算架构，但很多年过去了，程序员们还是很难理解如何为其编写应用程序。”
Gelsinger声称，以上就是Intel Larrabee图形芯片为何完全基于IA x86核心的主要原因。他说：“我们不会强迫程序员学习一个全新架构，而是让他们面对自己熟悉的东西，然后对现有编程模型进行拓展，加入新的视觉计算数据并行处理机制。这就是我们在开发Larrabee时的策略。它是一个IA兼容核心，加入了图形矢量视觉指令集，完全支持原生编程模型和DirectX、OpenGL等API接口。”
Gelsinger还表示独立软件开发商对Larrabee充满了热情，这也证明他们的策略是正确的，适合长期发展。
作者: gz_easy    时间: 2008-7-2 12:22
以前在一些媒体看到介绍Pat Gelsinger是个很低调的人；怎么自IDF2008 Shanghai开始便一反常规。
作者: gz_easy    时间: 2008-7-2 12:28
Intel意图把x86架构带入包括GPU在内尽可能多的领域，这是司马昭之心。。。
作者: 平日    时间: 2008-7-2 12:45
路过，两年后Larrabee发布了再来挖坟
作者: Bohr    时间: 2008-7-2 13:04
提示: 作者被禁止或删除 内容自动屏蔽
作者: beer966    时间: 2008-7-2 13:06
反对X86岂不间接也要反对MS........{shy:]
作者: acqwer    时间: 2008-7-2 13:09
我本来以为cuda是打算战Larrabee的，现在才知道NV是为了让自家产品在性能不及的情况下有其他的东西可以吹，就像“真”四核一样。
作者: Edison    时间: 2008-7-2 13:10
原帖由 Bohr 于 2008-7-2 13:04 发表
当cuda编程和c语言编程变得一样时，它才有可能被大部分程序员接受


写CUDA就是写C。

写CUDA你不需要考虑SIMD的问题，而写SSE你反而可能需要用到intrinsics。
作者: Edison    时间: 2008-7-2 13:11
原帖由 beer966 于 2008-7-2 13:06 发表
反对X86岂不间接也要反对MS........{shy:]


反x86不等于反microsoft，反windows才是真正的反microsoft。
作者: rtyou    时间: 2008-7-2 13:27
原帖由 平日 于 2008-7-2 12:45 发表
路过，两年后Larrabee发布了再来挖坟


等到CUDA成为笑谈后反挖[cool>
作者: furtfans    时间: 2008-7-2 14:22
架构原因，gpu能搞的计算目前还仅限于一些高度并行化的东西。不能解决复杂并行程序的编译问题永远在主流高性能计算领域没有出头之日。
作者: yehaku04    时间: 2008-7-2 14:52
INTEL打算要自己出CPU+GPU二合一的处理器了。
一统显卡市场。以后什么N卡A卡都靠边站{lol:]
作者: CC9K    时间: 2008-7-2 15:16
反GPU才是反微软

没GPU要DX API干什么么？

没DX支持的PC游戏才懒得用Win，现在MAC OS、Linux一样好用
作者: predacon    时间: 2008-7-2 15:23
有些道理

其实就larabee，cell 来讲,x86不x86并不是编程困难的主要来源，并行化才是。实在不看好larabee, 难道每一个core都有一个x86前端，这个开销比4核2核可要大多了


原帖由 CC9K 于 2008-7-2 15:16 发表
反GPU才是反微软

没GPU要DX API干什么么？

没DX支持的PC游戏才懒得用Win，现在MAC OS、Linux一样好用
作者: dklulu    时间: 2008-7-2 15:44
原帖由 CC9K 于 2008-7-2 15:16 发表
反GPU才是反微软

没GPU要DX API干什么么？

没DX支持的PC游戏才懒得用Win，现在MAC OS、Linux一样好用


{lol:] 够简洁,很有意思,简言之INTEL要是能按照自己步调发展有可能变成微软的头号敌人{blush:]
作者: Jason21    时间: 2008-7-2 16:12
原帖由 CC9K 于 2008-7-2 15:16 发表
反GPU才是反微软

没GPU要DX API干什么么？

没DX支持的PC游戏才懒得用Win，现在MAC OS、Linux一样好用

谁说反对DX了！

“这就是我们在开发Larrabee时的策略。它是一个IA兼容核心，加入了图形矢量视觉指令集，完全支持原生编程模型和DirectX、OpenGL等API接口。”
作者: ocfail    时间: 2008-7-2 16:24
原帖由 furtfans 于 2008-7-2 14:22 发表
架构原因，gpu能搞的计算目前还仅限于一些高度并行化的东西。不能解决复杂并行程序的编译问题永远在主流高性能计算领域没有出头之日。


麻烦请把

高度并行化的东西

复杂并行程序

解释一下

并举1-2个其在“主流”高性能计算领域的实例{excl:]
作者: ocfail    时间: 2008-7-2 16:49
作为一个写过C的程序员，我想说是：

对于一个C程序员来说，我想知道的，仅仅是我有些什么资源，它们现在的状态如何

C程序员不是写汇编代码 虽然需要有汇编的底子，但是编译器帮助我们完成了大部分事情，对于CPU+GPU的编程，无异于多CPU的编程，所有的计算单元 对于C程序员来说都是一样的，至少编译器要保证它们是一样的

我建立2个含有1024个双精度浮点数的数组 把它提交给一个CPU核心 或者 一个GPU核心 去做加法 代码是一致的，仅仅的区别可能就是 调用方法改名而已

作为C程序员 只要把这2个数组 提交出去 让状态空闲的资源进行计算 并返回结果就可以，有些人认为的复杂度 全部是由编译器完成的，与开发代码没有关系

极端的说，某些高性能计算，其过程也就是 征询空闲资源，提交数据，把计算结果再返回的过程  何来高度并行化与复杂并行化之说？

所以说  CUDA与Larrabee 之争 完全是编译器间的竞争 谁家的编译器好 程序员就喜欢用谁的来编译。 重新开发？对不起，高性能计算领域里的人都很懒，总是希望被编译器拯救，而不是去迎合某些不着边际的技术
作者: kts    时间: 2008-7-2 16:54
原帖由 rtyou 于 2008-7-2 12:14 发表
http://news.mydrivers.com/1/110/110050.htm
http://news.mydrivers.com/1/110/110056.htm
NVIDIA公司日前宣布，将向伊利诺伊大学Urbana-Champaign分校（UIUC）捐赠50万美元，并命名该校为全球首个CUDA卓越中心（ ...


最看不惯对新东西下结论说“这个困难无法克服”，一般审论文的时候遇到这种是话统统拍死，他是老几他觉得困难就能下结论了？
作者: ocfail    时间: 2008-7-2 17:08
原帖由 slgx 于 2008-7-2 17:02 发表


请参考“生产者-消费者”问题。


进程互斥 是可以通过程序进行控制的

我对GPGPU和CPU的看法是在计算层面的，即对于合适的编译器 这2者对于程序员是透明的，程序员只要知道手头上有多少个计算资源，不需去管这个计算资源是在什么位置 又是如何完成的
作者: ocfail    时间: 2008-7-2 17:25
原帖由 slgx 于 2008-7-2 17:19 发表


现在不是要你去判断这个资源在什么位置能不能访问的临界区。
而是这个“生产者”基于模型生产不出（不够）产品，一大堆“消费者”就得干等着。
请问哪个编译器能解决这个问题，一大堆计算资源如何迁就这个“生 ...


我觉得我们的讨论已经开始偏题了

这确实是一个问题，但是这不会影响到GPGPU的发展

编译器能让我像用CPU一样用GPU资源 这就可以了

而对于高性能计算中，根据实际系统资源进行优化也是很重要的一环
作者: yyzjp    时间: 2008-7-2 17:28
原帖由 Edison 于 2008-7-2 13:10 发表


写CUDA就是写C。

写CUDA你不需要考虑SIMD的问题，而写SSE你反而可能需要用到intrinsics。


要写出漂亮的CUDA程序呢?

要写出高效并行度很高的CUDA程序呢?

热球的文章你比我熟悉吧.

CUDA还有很长的路要走...
作者: Bohr    时间: 2008-7-2 18:26
提示: 作者被禁止或删除 内容自动屏蔽
作者: Edison    时间: 2008-7-2 18:50
原帖由 Bohr 于 2008-7-2 18:26 发表
两者的开发环境毫无可比性


你说的开发环境是指什么？
作者: rtyou    时间: 2008-7-2 18:54
原帖由 lunew 于 2008-7-2 18:48 发表
靠, 要从娃娃抓起?
cuda实用大约要等到下一代?


问题是NV的时间并不充裕
作者: Bohr    时间: 2008-7-2 18:58
提示: 作者被禁止或删除 内容自动屏蔽
作者: Edison    时间: 2008-7-2 19:13
原帖由 Bohr 于 2008-7-2 18:58 发表
编译器、技术支持等

我认为关键是它们都是C来编写、都支持Windows、Linux，这些才是最重要的，在编译器技术上Intel的优势也不过是表现在x86上，它的对手又不是使用x86的，你的x86编译器好到顶也没啥影响，在其他方面Intel的软件支持也有些不足的，你看看在Linpack上他们的MKL相对GotoBLAS来说是如何糟糕的。

最重要的是，NVIDIA的CUDA在硬件上就已经是打下了非常好的并行化底子。
作者: 天下18    时间: 2008-7-2 20:09
提示: 作者被禁止或删除 内容自动屏蔽
作者: Edison    时间: 2008-7-2 20:54
原帖由 mousefire 于 2008-7-2 19:40 发表
语言无所谓，问题是语言所表达的思想，一般的工程技术人员写程序时，最差的也是最普遍的就是不管三七二十一把程序写出来算出来就OK，毕竟大多数任务对现代计算机的运算能力来说已经太easy了，好一点的大不了用个intel c++编译器，可以实现对处理器的优化（当然最高一级的优化只针对扣肉系列），写个简单的多线程也不难（顺便说句10.0版本的intel c++对多线程的优化确实很nb）。。。写CUDA呢？我是没有写过，不大清楚要想用上它，从硬件到软件到底要作多少准备，就算这些准备只花一天时间，接下来我要学会用它写出成熟的程序又得用多久？而且从它本身的特性来看，稍微复杂综合一点的东西，又不能只靠GPU，它和CPU的综合怎么办（这一句是臆想，我没有用过，还请E大指教）？最后一个问题，每个科研领域都有大量的历史遗留代码，这些玩意的处理也是一个很恶心的问题，见过师兄把一坨坨fortran转成c++的，很累很无聊，那如果是转成CUDA实现呢？恐怕就不光是累、无聊，还很伤脑筋了吧。。。对于用计算机的人来说，它毕竟只是一个工具，玩游戏的只要它跑得快画面不出问题，我们做工程的计算时要用，恐怕也不会关心程序是否能编得好些少运行几个小时，要确保也只是确保程序的稳定性，别出错就行，C#画个界面，VC封装功能代码，用到数学的地方matlab的数学库直接搬过来用，这样写程序很轻松效率也很高，向别人介绍或者和别人交流时也只要很少几句话就能让人明白自己的程序每个部分都在干什么，我可不想向每一个师兄师姐师弟师妹导师解释一遍我的程序用的是CUDA，然后看着他们瞪大着的眼睛给他们解释老半天。。。。
      也许CUDA会有一天应用于视频转换之类的软件成功商业化，但是我很怀疑如此狭窄的领域是否值得Nvidia把它作为宣传产品时的一大重点，也很怀疑它会不会因为对A卡的不兼容性导致厂商根本不愿意为了一个只能用在一部分计算机上的技术赔Nvidia一起赌（对于软件厂商来说，它没有权力要求用户全用N卡，相反，它要考虑的问题是用户不管是用的什么卡，都能很好的运行软件）CUDA用了C，确实很容易实现多操作系统平台，但是如果它天生歧视A卡，那么它的兼容性永远都很烂，看到暗黑三用Havok了么？Nvidia，你要记住你不是老大，老大是客户


CUDA的设置、介绍和基本的一些游戏规则其实NVIDIA的文档也都说得比较清楚了，这里可以参考一下：http://www.pcinlife.com/article/graphics/2008-06-04/1212575164d532.html

CUDA目前提供了一定的Fortran支持：


matlab方面也有对应的plug-in：
http://developer.nvidia.com/object/matlab_cuda.html

CUDA作为一个语言，它本质上是没有什么歧视的问题，从RV770的体系架构来看，也已经是非常非常接近于CUDA，如果AMD能根据其自己的产品提供编译器和驱动支持，应该是不成问题的，AMD最近公布R600 ISA应该也是有点希望第三方提供一些接口上的支持的意思吧。

AMD也有自己的brook+，所以从他自身的角度来说，恐怕不会提供CUDA的支持。
作者: rtyou    时间: 2008-7-2 21:48
原帖由 天下18 于 2008-7-2 20:09 发表
我觉得INTEL十分清楚他的威胁来自哪里


Intel当然知道~ 很明确，对Intel地位有威胁的不可能是一家fab都没有的“皮包公司”

可惜Nfan总以为是NV，太YY了" src="./images/smilies/PCinlife2009/rolleyes.gif" border=0 smilieid="123">

目前看来一家做（严格说是设计）GPU的厂家和做声卡、网卡的厂家没有多大区别，不过有些人太夜郎自大了点~

[ 本帖最后由 rtyou 于 2008-7-2 21:52 编辑 ]
作者: harleylg    时间: 2008-7-2 21:52
到底是CUDA还是Larabee，其实还是要看需要。
对于家用来说，除了视频转换和游戏，现阶段可以说完全没有需要海量计算的地方。
对于企业，大部分的企业还在为企业信息的整合而在努力。海量计算离普及还很远。

如果什么时候40%以上的家庭或者企业都需要进行海量计算了，估计MS会出一个XXX的API，不管Intel还是NV还是AMD，统统要听MS滴。然后就跟现在的DX编程一样……
作者: jackpeng33    时间: 2008-7-3 08:40
提示: 作者被禁止或删除 内容自动屏蔽
作者: supermouse    时间: 2008-7-3 09:16
原帖由 ocfail 于 2008-7-2 16:49 发表
作为一个写过C的程序员，我想说是：

对于一个C程序员来说，我想知道的，仅仅是我有些什么资源，它们现在的状态如何

C程序员不是写汇编代码 虽然需要有汇编的底子，但是编译器帮助我们完成了大部分事情，对于CP ...


    没错, 你可以完全依赖编译器. 然后照旧的把这两个数组扔出去. 那么CUDA对你的好处, 也不过就是一个闲置的GPU变成一个CPU而已. 首先NV的编译器开发能力还没有得到认可, 你得到的很可能是个效率一般而且还不完整的CPU.  其次, 对于大部分用户来说, 如果只是要多个CPU核心,  直接买CPU就好了...还省个程序员.

    如果你要真的想写个好的CUDA程序, 那么你扔出去的很可能就不是两个数组了. 扔数组简单, 在何时扔出什么数组就比较复杂了.

    其实Intel也要面对同样的问题.  所以他们才在大力鼓吹如何如何的无脑易用. 而且他们之前的积累也让他们更有分量说话, 不止说的编译器. Intel搞平台战略也不是一天两天了.
作者: furtfans    时间: 2008-7-3 09:21
原帖由 ocfail 于 2008-7-2 16:49 发表
所以说  CUDA与Larrabee 之争 完全是编译器间的竞争 谁家的编译器好 程序员就喜欢用谁的来编译。 重新开发？对不起，高性能计算领域里的人都很懒，总是希望被编译器拯救，而不是去迎合某些不着边际的技术


所以才说不能解决复杂并行问题，在主流领域就没有出头之日。不是所有HPC程序员都精通MPI的。因为力学专业的关系。我接触过一些大型机和非常多的专业软件。回到你上面一帖提到的问题，主流高性能应用是什么？我可以告诉你，在国内是结构计算，其次才是和地球物理有关的那些东西以及其他。就结构计算领域来说，一个好的前处理优化会节省巨大的计算时间。而前处理优化会涉及到有限元间传递函数的优化。因为网格多边形边数的不同，会产生大量的结构不一致甚至所需算法不一致的方程组，比如拉格朗日法，欧拉法的混合。而这些前处理，既是一种复杂的并行应用。处理之后的求解，由于存在不同形式的方程组，那么就要求cpu（或者gpgpu）有灵活的处理方式。在多线程的HPC中，这种计算不需要等待多长时间，几个不同的方程组在几个不同的核心中求解并互相返回计算结果。我所谓的高度并行化问题，就是不同线程计算过程中，方程形式一致且互相极少交换数据或者不交换数据的的并行应用。显然对于前述的结构计算/有限元分析来说，这种情形实在是太过理想化了。就像前一阵INTEL批评CUDA的视频编码太过简单粗暴一样，这些都需要优化的东西目前在GPGPU上应用尚早。你最后也提到了：“高性能计算领域里的人都很懒，总是希望被编译器拯救，而不是去迎合某些不着边际的技术”。我想这是对的，在HPC领域看来，CUDA目前就是一个不着边际的东西，因为它的局限性太大了。这个局限性不来自CUDA本身，而是来自架构。
作者: rtyou    时间: 2008-7-3 09:26
原帖由 jackpeng33 于 2008-7-3 08:40 发表

这个言论真是太搞笑了，没有厂的大公司多的是，生产的东西没人要的话你所说的FAB营运不用钱吗？IT企业要生存主要需要什么，你认为是工厂吗？


没什么搞笑的，只是实情，没有什么单纯的需要，更不是靠嘴巴和忽悠。
就像声卡公司逐渐淡出一样，专门的显卡公司也一样甚至还不如。
看看下图就知道Intel真正的对手是谁？！台积电代工Nv而已，没有Fab就是这么被动。

作者: Edison    时间: 2008-7-3 09:28
原帖由 book008 于 2008-7-3 08:13 发表
看了一下贵站的CUDA简述,了解不多,随便说说.
CUDA程序的确是基于类C可说类C++的语言来编写.
问题是到具体开发时,如果想最大效能利用GPU资源,是要考虑程序线程式具体分配到那个"GRID"或"块"去执行.
如果这个线程一但出错,或是溢出,如何做调试,也是个问题.

而INTEL的意思是,开发游戏时还是基于DX/OPGL来开发.
假设:调用了一个DX的API,这个API执行,是在CPU里执行,还是到GPU并行运算,则由CPU做决策.
程序员跟本就不用考虑.相对而言,开发难度更简单,工作更高效的多.


我不认为Intel会推荐使用D3D或者OGL作GPGPU开发，它们不支持scatter，没有scatter，大部分的东西都不能干。

Larrabee有自己的通用计算开发工具——Larrabee SDK aka Native SDK。
作者: 九泉苍月    时间: 2008-7-3 09:28
Hynix和心爱的Toshiba好惨.....另外...Freescale还能增长？....
作者: furtfans    时间: 2008-7-3 10:39
我希望larrabee更适合真正的视觉计算。但不会寄望于这个东西能进入主流HPC领域，除非intel自己不想卖xeon给galaxy和IBM之类的HPC厂家了。。
作者: Edison    时间: 2008-7-3 10:40
原帖由 furtfans 于 2008-7-3 10:39 发表
我希望larrabee更适合真正的视觉计算。但不会寄望于这个东西能进入主流HPC领域，除非intel自己不想卖xeon给galaxy和IBM之类的HPC厂家了。。

这个东西不是Intel想不想卖的问题，而是他的对手已经在做这个事情。
作者: furtfans    时间: 2008-7-3 10:47
做的还不够好啊～～局限太多太多了。比如GPU线程间的计算结果交换就是大问题。目前的HPC一个core一般拥有4～8个GB的内存。节点间的通讯量也是巨大的。HPC应用最多的还是工程计算领域。真正的巨型机诸如蓝色基因部署少之又少。Nv不能解决对主流工程计算软件的支持问题就没戏。
Nv貌似是三代换一次架构吧，G80-G92-GT200。我倒是真的很期待看一看Nv下一代架构是个什么样子。
作者: Edison    时间: 2008-7-3 11:12
原帖由 furtfans 于 2008-7-3 10:47 发表
做的还不够好啊～～局限太多太多了。比如GPU线程间的计算结果交换就是大问题。目前的HPC一个core一般拥有4～8个GB的内存。节点间的通讯量也是巨大的。HPC应用最多的还是工程计算领域。真正的巨型机诸如蓝色基因部署少之又少。Nv不能解决对主流工程计算软件的支持问题就没戏。
Nv貌似是三代换一次架构吧，G80-G92-GT200。我倒是真的很期待看一看Nv下一代架构是个什么样子。


Tesla架构是有64bit MMU的，CUDA本身也提供了shared memory、device memory、host memory等阶层内存模型的支持，Tesla 1070有4GB GDDR3 per GPU，total 16GB per node，408GB/s的带宽（这是CPU完全无法媲美的），如果你有更多的预算，可以提出定制。

Tesla的系统界面是两条PCIE 16X 2.0，每条的带宽是8GB/s各向，共计16GB/s，是InfiniBand QDR 4X的4倍。

我不清楚你说得主流工程计算软件是指哪些，如果还是指matlab的话，前面已经有提供相应的CUDA plug-in连接了。

这里有一些相应的应用介绍：
http://www.beyond3d.com/content/articles/107/2
作者: kril    时间: 2008-7-3 11:19
CUDA暂时只适合在一些需要高带宽的应用上，比如核爆
作者: Edison    时间: 2008-7-3 11:31
原帖由 kril 于 2008-7-3 11:19 发表
CUDA暂时只适合在一些需要高带宽的应用上，比如核爆

CUDA只是一个C的扩展，理论上所有的算法都能在上面实现，包括h264编码、游戏物理加速等大家常见的应用都已经有了相关软件。
作者: Edison    时间: 2008-7-3 14:03
NVIDIA 表示 Ansys 正在做一个 CUDA 的项目，不过应该还有段时间。
作者: furtfans    时间: 2008-7-3 16:56
MSC software,comsol,Ansys...很多很多。真想列能列出来几十个，cuda到现在这么长时间，工程领域没有一家支持的（有个原因是之前只支持单精度浮点）。现在能见到的大多是数学，物理计算，而且都是明显的高度并行化的。但也并不是简简单单的像写c一样写出来算法就完了，优化还要做很多很多。工作性质实在是有些类似MPI编程的程序员。类似CUDA的matlab，pathyon中的 parallel computing plug in实际上现在有一个极为成熟的解决方案，名字叫做star-p，cuda现阶段哪怕能跟这个东西小拼一下都是极为成功的。
另外，我说一个core占用4-8gb内存，一个gpu有多少“core”呢？上百个？而且问题的关键并不在带宽上，而是虽然GPU可以同时执行一大堆线程，但是每个线程能做的事情和CPU比起来都还显得太简单了，而且每个thread又能占有多少带宽呢？。如何将巨大复杂的问题变成如此并行化，对程序员来说都是噩梦，更不要说追求界面友善化的商业应用软件了。
在adams的一些多自由度运动分析中，超过256线程的求解相对256线程的求解速度已经近乎0增长在某些极端个例中甚至是负增长，比如多重受力，大量边界条件的模型。ansys也是类似的。其中一个原因就是因为线程拆的太过细小，以至于迭代次数暴增（在多自由度运动分析和有限元分析中，就是迭代迭代再迭代，直到满足要求精度为止）。所以，并行问题的拆分并不是拆的越细越好。
我并不是否定cuda，相反我确实认为这个东西是个巨大的革新。但如果单从硬件指标，比如带宽，线程数量等等来看待超级计算的应用的话那么局限性非常大。我们不能忽略并行问题本身的性质。而现在GPU能够处理的最好的就是本身被拆成非常多线程的数学基本问题，比如F傅立叶变换。但工程上仅仅应用傅立叶变换的场合是没有的，比如一个多自由度系统的模态分析，多物理场的耦合等等。
你说到的ansys的项目我刚刚没有查到，有的话相信也只是一个算例而已，应该不是一个可以立刻应用的插件。

我认为GPGPU计算要走的路还很长。它能够成功的重要条件就是使工程/科学工作者摒弃传统HPC。而做到这点必须对应用软件提供良好支持。CUDA的未来不是梦，只不过还年轻。

[ 本帖最后由 furtfans 于 2008-7-3 16:59 编辑 ]
作者: furtfans    时间: 2008-7-3 17:00
simwe关于gpgpu的讨论串居然没了，真不幸。。。不过有兴趣的可以去上超算的版块发贴问问专业HPC编程人员的意见。

[ 本帖最后由 furtfans 于 2008-7-3 17:07 编辑 ]
作者: Edison    时间: 2008-7-3 17:13
NVIDIA的CUDA forum有人扔了个这样的东西，我对python不熟悉，你可以试试看。
ftp://ftp.graviscom.de/pub/code/python-cuda

这是相关的讨论串：
http://forums.nvidia.com/index.php?showtopic=54496


还有人做了个PyCDUA：
http://forums.nvidia.com/index.php?showtopic=70067

I am happy to announce the availability of PyCuda, which is a Python wrapper around Cuda. What differentiates it from previous efforts?