【转帖】NVIDIA：CUDA要走进大学课堂；Intel：GPGPU没有未来，CUDA只是历史过客

ocfail

原帖由 slgx 于 2008-7-2 17:19 发表


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

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

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

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

而对于高性能计算中，根据实际系统资源进行优化也是很重要的一环

yyzjp

原帖由 Edison 于 2008-7-2 13:10 发表


写CUDA就是写C。

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

要写出漂亮的CUDA程序呢?

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

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

CUDA还有很长的路要走...

Edison

原帖由 Bohr 于 2008-7-2 18:26 发表
两者的开发环境毫无可比性

你说的开发环境是指什么？

rtyou

原帖由 lunew 于 2008-7-2 18:48 发表
靠, 要从娃娃抓起?
cuda实用大约要等到下一代?

问题是NV的时间并不充裕

Edison

原帖由 Bohr 于 2008-7-2 18:58 发表
编译器、技术支持等

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

最重要的是，NVIDIA的CUDA在硬件上就已经是打下了非常好的并行化底子。

Edison

原帖由 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支持：

• FORTRAN using pinned memory calling CUBLAS (Fortran_Cuda_Blas.tgz)
• FORTRAN interface to CUDA kernel (Fortran_Cuda.tgz)

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

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

AMD也有自己的brook+，所以从他自身的角度来说，恐怕不会提供CUDA的支持。

rtyou

原帖由 天下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

到底是CUDA还是Larabee，其实还是要看需要。
对于家用来说，除了视频转换和游戏，现阶段可以说完全没有需要海量计算的地方。
对于企业，大部分的企业还在为企业信息的整合而在努力。海量计算离普及还很远。

如果什么时候40%以上的家庭或者企业都需要进行海量计算了，估计MS会出一个XXX的API，不管Intel还是NV还是AMD，统统要听MS滴。然后就跟现在的DX编程一样……

supermouse

原帖由 ocfail 于 2008-7-2 16:49 发表
作为一个写过C的程序员，我想说是：

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

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

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

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

    其实Intel也要面对同样的问题.  所以他们才在大力鼓吹如何如何的无脑易用. 而且他们之前的积累也让他们更有分量说话, 不止说的编译器. Intel搞平台战略也不是一天两天了.

furtfans

原帖由 ocfail 于 2008-7-2 16:49 发表
所以说  CUDA与Larrabee 之争 完全是编译器间的竞争 谁家的编译器好 程序员就喜欢用谁的来编译。 重新开发？对不起，高性能计算领域里的人都很懒，总是希望被编译器拯救，而不是去迎合某些不着边际的技术

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

rtyou

原帖由 jackpeng33 于 2008-7-3 08:40 发表

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

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

Edison

原帖由 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。

九泉苍月

Hynix和心爱的Toshiba好惨.....另外...Freescale还能增长？....

furtfans

我希望larrabee更适合真正的视觉计算。但不会寄望于这个东西能进入主流HPC领域，除非intel自己不想卖xeon给galaxy和IBM之类的HPC厂家了。。

Edison

原帖由 furtfans 于 2008-7-3 10:39 发表
我希望larrabee更适合真正的视觉计算。但不会寄望于这个东西能进入主流HPC领域，除非intel自己不想卖xeon给galaxy和IBM之类的HPC厂家了。。

这个东西不是Intel想不想卖的问题，而是他的对手已经在做这个事情。

furtfans

做的还不够好啊～～局限太多太多了。比如GPU线程间的计算结果交换就是大问题。目前的HPC一个core一般拥有4～8个GB的内存。节点间的通讯量也是巨大的。HPC应用最多的还是工程计算领域。真正的巨型机诸如蓝色基因部署少之又少。Nv不能解决对主流工程计算软件的支持问题就没戏。
Nv貌似是三代换一次架构吧，G80-G92-GT200。我倒是真的很期待看一看Nv下一代架构是个什么样子。