POPPUR爱换

标题: nVidia 通用运算CUDA架构:这编译器真阳春 [打印本页]

作者: Tanknet 时间: 2007-2-18 09:58
标题: nVidia 通用运算CUDA架构:这编译器真阳春
很不成熟呀,连OpenMP都没实现呢,用的是自己的一套线程函数
更不用说Auto-Vectorization/multithread了

想到ICC上手之容易,适用面之广,直令我根本不想再把CUDA Programing guide看下去,
我也没有8x00系列显卡

看来nVidia的编译器开发水平比起Intel差得还远.继续努力啊!

NV发布CUDA架构 G80万亿次科学运算
作者：Skyangeles 编辑：Skyangeles　2007-2-17 17:55:00

2月16号，NVIDIA公司正式发布了他们的CUDA架构（Compute Unified Device Architecture统一计算设备架构），这就是NV口中的通用GPU（GPGPU）的正式名称。本次，NV面向专业开发者们发布了CUDA软件开发包（SDK）以及C语言编译器的0.8版本。

实际上，早在去年发布G80系列显卡时，NV就已经预告了CUDA的到来。CUDA是世界上第一个针对GPU的C语言开发环境，可以充分应用GeForce 8800 GPU 128（GTX版）或96（GTS版）个流处理单元强大的浮点运算能力，解决复杂的科学运算问题。该环境目前仅支持8800系列显卡，未来还将对NV后续发布的Quadro专业显卡提供支持。根据NVIDIA的测试，8800显卡在CUDA架构中的峰值运算能力可达520GFlops，因此如果构建SLI双卡系统，可以达到1TFlops（即每秒运算1万亿次）的强大运算能力。

NV专业产品总经理Andy Keane介绍说：“目前GPU已经是足够强大的可编程处理器，非常适合大运算量的科学应用，诸如地质勘探，生物学，流体力学，金融建模等等。通过CUDA技术，所有开发人员都能够使用标准的C语言，挖掘NVIDIA GPU中多个处理单元强大的并行计算能力。”

虽然NVIDIA本次发布的CUDA开发环境已经提供了开放下载，但NV官方认为目前只有专业的程序员才是CUDA真正的用户。由于G80内部包含的128或96个流处理单元，在进行科学运算时相当于一个100颗左右CPU的大规模并行处理系统，普通的编程爱好者肯定无法驾驭其协同合作，完全发挥其性能。

CUDA开发环境目前支持Windows XP和Linux（Red Hat Enterprise Linux 4 Update 3）。遗憾的是，目前CUDA仅支持32位系统，因此在进行运算时只能够兼容单精度数据。NV透露今年晚些时候推出的新款显卡将支持64位系统，兼容双精度数据。

CUDA Toolkit Version 0.8/CUDA SDK Version 0.8以及说明文档（Windows XP/Linux）下载页面

http://developer.nvidia.com/object/cuda.html

作者: Prescott 时间: 2007-2-18 19:56
有没有评测阿？谁有G80，把下面NVIDIA给的几个例子跑跑看看结果如何？:lol:
# Parallel bitonic sort
# Matrix multiplication
# Matrix transpose
# Performance profiling using timers
# Parallel prefix sum (scan) of large arrays
# Image convolution
# 1D DWT using Haar wavelet
# OpenGL and Direct3D graphics interoperation examples
# CUDA BLAS and FFT library usage examples

作者: RacingPHT 时间: 2007-2-18 22:29
提示: 作者被禁止或删除内容自动屏蔽

作者: the_god_of_pig 时间: 2007-2-18 22:35
貌似P大很在意G80通用的performance哇w00t)

作者: maomaobear 时间: 2007-2-19 09:20
双精度能超过cell吗？如果gpu成功了，cell这种混合cpu就不用混了

作者: Prescott 时间: 2007-2-19 11:56

原帖由 the_god_of_pig 于 2007-2-18 22:35 发表
貌似P大很在意G80通用的performance哇w00t)

不是老有人在说很厉害嘛，好奇一下。

作者: Prescott 时间: 2007-2-19 11:57

原帖由 maomaobear 于 2007-2-19 09:20 发表
双精度能超过cell吗？如果gpu成功了，cell这种混合cpu就不用混了

现在怎么可能超过，好歹Cell还能跑跑双精度，这个现在根本不支持双精度。

不过据说也快了。

作者: 天天要上 时间: 2007-2-19 12:51
残念……偶一点都看不懂……

飘过飘过~~~:a)

作者: the_god_of_pig 时间: 2007-2-19 13:07
我也很想知道到底性能怎么样:lol:

cell的模拟地球忽悠了我们一把，

PPU的效果革命忽悠了我们一把，

某社的GPU物理运算又忽悠了我们一把，:wacko: :wacko: :wacko:

现在对暴力没什么信心了~:(

作者: potomac 时间: 2007-2-19 13:10
提示: 作者被禁止或删除内容自动屏蔽

作者: the_god_of_pig 时间: 2007-2-19 13:20
现在IBM智慧不通，只好上暴力:lol:

I还有EPIC,可以顶一会儿:wub:

作者: ljlxl 时间: 2007-2-19 14:07
这么长，楼主辛苦了

作者: jhj9 时间: 2007-2-19 17:25

原帖由 Prescott 于 2007-2-19 11:57 发表

现在怎么可能超过，好歹Cell还能跑跑双精度，这个现在根本不支持双精度。

不过据说也快了。

G80是支持FP32的，怎么可能不支持双精度呢？

作者: Prescott 时间: 2007-2-19 21:41

原帖由 jhj9 于 2007-2-19 17:25 发表

G80是支持FP32的，怎么可能不支持双精度呢？

:wacko:
因为双精度是64bit的。:lol:

[ 本帖最后由 Prescott 于 2007-2-19 21:52 编辑 ]

作者: fineday 时间: 2007-2-19 23:13
:p 我觉得很奇怪，ICC是不是3个月前才出来的东西？
或者，ICC出来3个月的时候，是不是非常完美？
别忘了ICC针对的是CPU，CUDA针对的是GPU。
至于双精度，late 2007。

作者: potomac 时间: 2007-2-19 23:24
提示: 作者被禁止或删除内容自动屏蔽

作者: fineday 时间: 2007-2-19 23:51

原帖由 potomac 于 2007-2-19 23:24 发表
最大问题不是性能，是只能跑在自己的平台上，以致于没法推广。

所以intel的计划是最好的。:thumbsup:

w00t) 万一哪天Intel被AMD给ri翻在地怎么办

作者: elisha 时间: 2007-2-20 00:04

原帖由 fineday 于 2007-2-19 23:13 发表
:p 我觉得很奇怪，ICC是不是3个月前才出来的东西？
或者，ICC出来3个月的时候，是不是非常完美？
别忘了ICC针对的是CPU，CUDA针对的是GPU。
至于双精度，late 2007。

:funk: :funk:

作者: potomac 时间: 2007-2-20 00:30
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2007-2-20 01:42
1、编写dx、ogl程序的时候，大家根本没有使用OpenMP。
2、G80的ALU是MIMD+scalar+GIGA Thread的。

作者: acqwer 时间: 2007-2-20 12:07

原帖由 fineday 于 2007-2-19 23:51 发表

w00t) 万一哪天Intel被AMD给ri翻在地怎么办

如果哪天AMD真的ri翻了Intel，NV早就不存在了。

作者: Prescott 时间: 2007-2-20 12:19

原帖由 Edison 于 2007-2-20 01:42 发表
1、编写dx、ogl程序的时候，大家根本没有使用OpenMP。
2、G80的ALU是MIMD+scalar+GIGA Thread的。

1. OGL和DX的数据结构以及计算方式和通用处理中的数据结构及计算方式没有可比性。
2. ALU就是ALU，没有什么MIMD+scalar+GIGA Thread之说。

[ 本帖最后由 Prescott 于 2007-2-20 12:21 编辑 ]

作者: archerzz 时间: 2007-2-20 12:51

原帖由 fineday 于 2007-2-19 23:13 发表
:p 我觉得很奇怪，ICC是不是3个月前才出来的东西？
或者，ICC出来3个月的时候，是不是非常完美？
别忘了ICC针对的是CPU，CUDA针对的是GPU。
至于双精度，late 2007。

ICC有n年的历史了……

作者: Edison 时间: 2007-2-20 13:09

原帖由 Prescott 于 2007-2-20 12:19 发表
1. OGL和DX的数据结构以及计算方式和通用处理中的数据结构及计算方式没有可比性。
2. ALU就是ALU，没有什么MIMD+scalar+GIGA Thread之说。

GPGPU最适合的计算就是Array类的计算，这和图形处理是一样的，和GFX-GPU处理不同的是，GPGPU的API不需要理会纹理格式等DX、OGL API必须由开发人员应付的东西。

我说的G80的ALU是标量化issue设计是针对"更不用说Auto-Vectorization/multithread了"这样根本不了解G80、GPGPU的话语。

作者: fineday 时间: 2007-2-20 23:25

原帖由 archerzz 于 2007-2-20 12:51 发表

ICC有n年的历史了……

:p 用一个n年历史的东西的成熟度来和新出现不到3个月的玩意儿比，很公平么?

作者: Tanknet 时间: 2007-2-21 15:13

GPGPU最适合的计算就是Array类的计算，这和图形处理是一样的，和GFX-GPU处理不同的是，GPGPU的API不需要理会纹理格式等DX、OGL API必须由开发人员应付的东西。

我说的G80的ALU是标量化issue设计是针对"更不用说Auto-Vectorization/multithread了"这样根本不了解G80、GPGPU的话语。

我知道的啦，标量化issue是不错，可是CUDA说到底还是在要求程序员给GPU提供Array来运算，而不是它自己去发现并行性

此外GPU本身不处理Thread并行问题,因此也没有Multithread之说

ICC这个东西，我是从ICC9.0+VC6用起的，不了解过去的历史，有人介绍一下？或者提供一下早期版本？

作者: the_god_of_pig 时间: 2007-2-21 18:12

原帖由 Tanknet 于 2007-2-21 15:13 发表

我知道的啦，标量化issue是不错，可是CUDA说到底还是在要求程序员给GPU提供Array来运算，而不是它自己去发现并行性
此外GPU本身不处理Thread并行问题,因此也没有Multithread之说

ICC这个东西，我是从 ...

:funk: :funk: :funk: :funk:

4-issue以上的乱序已经要了厂商们的命~
您老人家来了个GPU自己发现并行性，要是实现的话岂不是die size要有几个平方米~w00t)

[ 本帖最后由 the_god_of_pig 于 2007-2-21 18:27 编辑 ]

作者: Prescott 时间: 2007-2-21 18:50

原帖由 不老牛奶 于 2007-2-21 18:48 发表
现在还没有哪个CPU厂商强到能够设计出一款自动将进程分解为适当数目线程的CPU/编译器，都是靠程序员“人工”多线程，完成一个程序的彻底两线程化就已经可以折磨死人了......

当然有这样的编译器。

作者: Prescott 时间: 2007-2-21 21:37

原帖由 不老牛奶 于 2007-2-21 18:53 发表

:rolleyes: 又来扯ICC无敌论？P大，心知肚明的事，就不要装傻了——

IBM的编译器也有啊。Sun的也有啊。我又没说ICC.

作者: potomac 时间: 2007-2-21 23:11
提示: 作者被禁止或删除内容自动屏蔽

作者: 来不及思考 时间: 2007-2-22 02:52
提示: 作者被禁止或删除内容自动屏蔽

作者: RacingPHT 时间: 2007-2-22 11:02
提示: 作者被禁止或删除内容自动屏蔽

作者: Prescott 时间: 2007-2-22 12:20

原帖由 不老牛奶 于 2007-2-22 10:18 发表

那种程度的多线程，顶多算是替程序员优化而已，大家都清楚真正意义上的多线程程序开发是什么概念吧？

当然概念不完全一样。但是对于某些计算密集型的程序这样效果也还不错。

作者: Prescott 时间: 2007-2-22 12:21

原帖由 RacingPHT 于 2007-2-22 11:02 发表
现在有人信"自动发现并行"么？

还是有效果的啦。如果你不信，那就请您解释一下这个specfp的成绩？

http://www.spec.org/osg/cpu2000/ ... 20060724-06684.html

[ 本帖最后由 Prescott 于 2007-2-22 12:26 编辑 ]

作者: RacingPHT 时间: 2007-2-22 14:40
提示: 作者被禁止或删除内容自动屏蔽

欢迎光临 POPPUR爱换 (https://we.poppur.com/)