1001コメント273KB

GPGPU#3

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん

2009/03/21(土) 19:18:14

GPGPUについて語りましょう

前スレ
GPGPU#2
http://pc11.2ch.net/test/read.cgi/tech/1188374938/

関連スレ
http://pc11.2ch.net/test/read.cgi/tech/1228891105/
http://pc11.2ch.net/test/read.cgi/tech/1206152032/

参考リンク
総本山? gpgpu.org
http://www.gpgpu.org/
OpenCL
http://www.khronos.org/opencl/
NVIDIA CUDA
http://developer.nvidia.com/object/cuda.html
ATI Stream
http://developer.amd.com/gpu/ATIStreamSDK/Pages/default.aspx
GPUをCPU的に活用するGPGPUの可能性
http://pcweb.mycom.co.jp/articles/2005/09/06/siggraph2/

0348名無しさん＠そうだ選挙に行こう

2009/08/30(日) 09:31:45

GPGPUなんて使えない。NVIDIAはそれしかないからプッシュしているだけで
少し知識があれば一番高いPentiumを買うのが一番頭がいい。

0349名無しさん＠そうだ選挙に行こう

2009/08/30(日) 09:56:26

CPU=マイコン
GPGPU=劣化FPGA

0350,,・´∀｀・,,）っ-○○○ ◆???

2009/08/30(日) 09:57:37

>>346
理屈考えろよ
電子を遠くに流そうとすればするほど電力のロスは大きくなる。

一方演算ユニットとかってそんなに消費電力食う訳じゃない。
ローカルのキャッシュメモリあるいはスクラッチパッドメモリを作って
ALU間の電子の移動を最小限にしたほうが良い

少なくともVRAMとの間を何度も往復するよりはよっぽど改善される。
現行のGDDR5帯域当たりの消費電力は1Gbpsあたり0.5Wだ。
GPUの消費電力の何割占めてるかわかるだろ。

ついでに言うとコントローラそのものが熱源になるから熱密度の制約が出てくる。
莫大なトラフィックを捌くコントローラにトランジスタ割くよりも、演算ユニットの数を増やして
同じトランジスタでも熱密度の制約が比較的少ないSRAMの大容量化を行い
メモリ帯域をセーブした方が健全。
レイテンシが小さくなって命令のインターリーブ数も抑えることができる。
レンダリング方法はタイルレンダ主体になるが。

0351名無しさん＠そうだ選挙に行こう

2009/08/30(日) 10:00:46

>>350
じゃあGrape-DRでよくね？

0352名無しさん＠そうだ選挙に行こう

2009/08/30(日) 10:39:36

今更GRAPEとかイラネ

0353名無しさん＠そうだ選挙に行こう

2009/08/30(日) 10:47:44

http://www.4gamer.net/games/076/G007660/20090529065/
NVIDIAの中の人も同じようなこと言ってたり。
最終的にGPUもLarrabeeみたいな感じになるのか？

0354名無しさん＠そうだ選挙に行こう

2009/08/30(日) 10:48:16

>>348
CPUとGPU両方使えば、より性能が伸びるだろ。
なんで片方しか使わない事になってるんだよｗ

0355名無しさん＠そうだ選挙に行こう

2009/08/30(日) 10:49:09

言っているだけで物は出ない（笑）

0356名無しさん＠そうだ選挙に行こう

2009/08/30(日) 10:49:54

OSX10.6でOpenCL使ってるんだが
なんかいまいちなんだけど

0357名無しさん＠そうだ選挙に行こう

2009/08/30(日) 11:05:09

どんな感じよ？

0358名無しさん＠そうだ選挙に行こう

2009/08/30(日) 11:06:08

もうOpenCL使える実装あんの？

0359名無しさん＠そうだ選挙に行こう

2009/08/30(日) 11:15:28

>>358
10.6ならRadeonとGeforce使ってOpenCLできるよ

0360名無しさん＠そうだ選挙に行こう

2009/08/30(日) 11:17:59

なんと！
ちょっとSnow leopardかってくる！

0361,,・´∀｀・,,）っ-○○○ ◆???

2009/08/30(日) 11:40:36

>>354
スタンフォードの教授だって言っても大学の研究資金って企業からの金で成り立ってるわけだから
決して公正客観だとは思わない方が良い

グラフィックって大雑把に言って点の数だけ並列化できるからトランジスタ分だけ性能が伸びるのは当たり前。
GPUの性能進化なんて野はグラフィックという用途に絞った話で、様々なプログラムを
好き嫌いなく動かさないといけないCPUとは全然土俵が違う。

同じ土俵で戦わせたらどうなるか？
知っての通り、GPGPUがCPUのタスクを全部肩代わり出来るかって言うと全然そうじゃない。
性能以前に動きすらしないプログラムの方が多い。
逆にCPUにGPUの仕事やらせれば同じようにスケールするだろう。それがLarrabeeなわけで。

0362名無しさん＠そうだ選挙に行こう

2009/08/30(日) 11:54:27

http://www.macupdate.com/info.php/id/32266/opencl-benchmark
どうやらSnow LeopardにはOpenCLのGPUドライバだけじゃなくて
CPUドライバも含まれてるっぽいね
でも、Core2じゃない初代Core Duoでは使えないっぽい？

0363名無しさん＠そうだ選挙に行こう

2009/08/30(日) 11:58:43

>>350
伝送距離の話ではなくて、伝送帯域の話では？
DDRはドライバで、電圧が決まっているから、伝送距離が増えてもレシーバ端で受信電圧が下がるだけで、消費電力は変わらないと思うけど。
このあたりはアナログ回路のはなしなので、スレ違いすまん。

0364名無しさん＠そうだ選挙に行こう

2009/08/30(日) 12:45:18

>>363
おいおい。

0365名無しさん＠そうだ選挙に行こう

2009/08/30(日) 13:04:34

ちなみにRadeonなら
CPUシミュレートではあるが、一応LinuxとWindows上で
HelloOpenCL作れたよ。

9月10日にAMDから発表あるから
その後すぐに、ネイティブで実行できるんじゃないのかなぁ

0366,,・´∀｀・,,）っ-○○○ ◆???

2009/08/30(日) 18:23:56

>>363
無論物理的距離ではなくインターコネクトのコストが最大の問題だ

0367名無しさん＠そうだ選挙に行こう

2009/08/30(日) 18:33:21

さっさとWindows向けのOpenCL実装出してよね！
話ばっかで疲れちゃったよ。

0368名無しさん＠そうだ選挙に行こう

2009/08/30(日) 18:37:38

出力電圧一定で負荷が増えているのに
消費電力が増えないと思えるのが不思議だ。

0369デフォルトの名無しさん

2009/08/30(日) 20:31:26

>>368
スレ違いなので、最後。
出力は一定とは言っていない。
負荷が大きくなると受信側での電圧が下がる。つまり電流が減るということ。
だから消費費は変わらないと思うと言っただけ。

0370デフォルトの名無しさん

2009/08/31(月) 00:52:03

>>369
考えて見たら、送信側って定電流であることが多いから、電力は増えるね。最近高周波の勉強してるから、勘違いしてしまった。
アホですまん。

0371デフォルトの名無しさん

2009/08/31(月) 09:55:41

どんまいける

0372デフォルトの名無しさん

2009/09/01(火) 19:06:28

ワラタ
伝送距離が長くなったら、配線の抵抗分で流れる電流が減るので、
消費電力はわずかだが減ります。
こんなの中高生レベルで理解できる話だ。オームの法則すら理解してないんだな。

0373デフォルトの名無しさん

2009/09/01(火) 19:41:05

インピーダンスを理解してない中高卒は黙ってろ

0374デフォルトの名無しさん

2009/09/01(火) 19:43:46

インピーダンスや高周波を知らないから、
オームの法則だけで理解、説明できるような話を勘違いしてるんだろう。
所詮設計とかやったことない奴の妄言だなあ。

0375デフォルトの名無しさん

2009/09/01(火) 21:09:10

中学生相手にマジレスすんなよ

0376デフォルトの名無しさん

2009/09/01(火) 21:26:56

わかってないのは、>>373, >>375。
インピーダンスという言葉を知っているだけで中身を理解していない。

0377デフォルトの名無しさん

2009/09/01(火) 21:43:11

たらったらったらったインピーダンス♪

0378デフォルトの名無しさん

2009/09/01(火) 22:17:35

OSX 10.6

OpenCLで同じプログラムを動作させた場合
Nvidiaの方が処理速度100倍高速だね

0379デフォルトの名無しさん

2009/09/01(火) 23:16:58

顔文字忘れてるぞ

0380デフォルトの名無しさん

2009/09/01(火) 23:21:51

>>372
厳密に言うと、外付けメモリの配線抵抗なんて、DDRの内部終端抵抗に比べれば、
小さいし、抵抗のバラツキも大きいから気にすることないんだけどね。

0381デフォルトの名無しさん

2009/09/02(水) 21:50:54

でっていう

0382デフォルトの名無しさん

2009/09/06(日) 05:14:30

Windows7のGPU評価に専用グラフィックメモリと共有システムメモリとは別に
専用システムメモリ(当然0MB)ってのがあるけどこれってVistaにもあったっけ？
DX11世代カードだとVRAMをGPGPUプログラムのメインメモリとして扱えるようになるのかな

0383,,・´∀｀・,,）っ-○○○

2009/09/06(日) 05:26:48

カード上にスワップ用のDDR*が載るのかとｵﾓﾀ

0384デフォルトの名無しさん

2009/09/06(日) 10:28:22

いっそGPUに直接HDDをつけられるようにしてくれ。
スワップし放題っw

0385,,・´∀｀・,,）っ-○○○ ◆???

2009/09/06(日) 15:35:30

>>382
正体判明。
GMAみたいなオンボードチップではグラフィック用にメインメモリの一部が固定的に割り当てられる。
GMAの場合専用グラフィックメモリ0MBで、専用システムメモリ32～64MBくらいになる。

0386デフォルトの名無しさん

2009/09/06(日) 15:38:58

>>385
なーんだ…

0387デフォルトの名無しさん

2009/09/07(月) 15:05:33

オランダ監督のコメント
＞「オランダはもっとファン・ブロンクホルスト（左サイドバック。日本の右サイド）を探すべきだった。
＞彼のところにスペースがあった。日本は中に入っていくチームだったからね」
http://sportsnavi.yahoo.co.jp/soccer/japan/text/kaiken/200909060003-spnavi.html

オランダ監督は日本の右サイドに居て、真ん中に入ってスペースを作るやつが弱点だと指摘しているな

どう見ても中村俊輔ですｗｗｗｗｗｗ

0388デフォルトの名無しさん

2009/09/11(金) 08:35:39

RADEON　HD5870、825MHzで1600SPだとよ。
5870x2なら1ボードで倍精度1Tだぜ。

0389デフォルトの名無しさん

2009/09/11(金) 19:40:43

GPUのflops表記に意味は無い

0390デフォルトの名無しさん

2009/09/11(金) 21:00:33

>>389の脳細胞の数に意味が無い如く、と言うわけだな！

0391デフォルトの名無しさん

2009/09/11(金) 21:48:48

そう、幾ら数が増えようが
元の効率がだめなのと、すべてのSPを使いきれるわけではないからな
ATIのは

そういった意味でプロセッサとしては
Centaur設計のshaderを擁するS3に及ばないと言い切れる

0392,,・´∀｀・,,）っ-○○○ ◆???

2009/09/11(金) 22:20:26

1つの命令をうん百並列の演算ユニットにブロードキャストして命令発行するのに小回りきくわけないば

SSEはたかだか4並列、AVX～Larrabee世代ですら8～16並列に増える程度だ
汎用性を左右する演算粒度が違いすぎる。

0393デフォルトの名無しさん

2009/09/12(土) 07:56:27

>>391
S3のGPUのプログラミングアーキテクチャを云々できる資料って公開されてたか？
されてるのならクレ。

0394デフォルトの名無しさん

2009/09/12(土) 08:06:53

AMDはOpenCL取り止めか？
DirectXだけに注力するのか？

0395デフォルトの名無しさん

2009/09/12(土) 09:30:09

UNIX系OSのために、OpenCL対応はほぼ義務の状態にある。
Stream廃止というなら話は分かるが。

でもPhysXやHavokに相当する統一規格がないんだよな。
BulletがCompute Shaderベースになるといいんだが。

0396,,・´∀｀・,,）っ-○○○ ◆???

2009/09/12(土) 12:28:30

ないだろ。
*NIX自体のマーケットが小さいし、そこに割って入る中立なAPIを作ろうという第3の組織もない。

ならCUDAなりATI Streamなりの元々の独自APIで十分というわけだ

0397デフォルトの名無しさん

2009/09/12(土) 14:31:21

CUDAとOpenCLとDXCSの3つが
競合する規格になるのかな？

0398デフォルトの名無しさん

2009/09/12(土) 14:54:19

OpenCLとDXCSは競合しない。
DirectXとOpenGLの様に棲み分けられる。
CUDAはどっちともぶつかるからきついね。

0399デフォルトの名無しさん

2009/09/12(土) 15:01:24

>ATI StreamSDK 2.0 beta(Windows, CPU 利用)の
>OpenCL 実装だと、8 秒近くもかかってとてつもなく遅い！
>(SnowLeopard だと 0.0001 秒なのに…)
http://lucille.atso-net.jp/blog/?p=907

終わりだろｗ

0400デフォルトの名無しさん

2009/09/12(土) 15:31:31

こういう時Intelは静かに仕事こなすな

0401デフォルトの名無しさん

2009/09/12(土) 15:58:45

珍テルだからな

0402,,・´∀｀・,,）っ-○○○

2009/09/12(土) 16:07:48

AMDはSDK作っても原則無償提供だから人件費の分だけ赤字
そんなに人員割けるわけがない

片やIntelはソフト開発者だけで3000人体制だからな。
ハードだけでなくコンパイラやVTune売っても金を生み出せる企業だから

0403デフォルトの名無しさん

2009/09/12(土) 16:11:48

AMDのSDK作ってる人2人だけだよｗ

0404デフォルトの名無しさん

2009/09/12(土) 18:52:00

力の1000万パワーと技の1000万パワー、二人合わせて2000万パワーズ。
力と技のコンビネーションでさらに倍の4000万パワー。
大丈夫だ、2人でも1万パワー3000人相手なら十分に戦える。

0405デフォルトの名無しさん

2009/09/12(土) 21:24:22

とりあえず480gflopsが、35.2gflopsに迫られるのはどうかと思いました（マル）

0406デフォルトの名無しさん

2009/09/12(土) 21:30:36

どうがをわすれてました（○）
ttp://www.youtube.com/watch?v=pmBd9HQgTCQ
ttp://www.youtube.com/watch?v=pGnrBu3N2QE

0407デフォルトの名無しさん

2009/09/12(土) 21:42:50

動画貼るだけなら、自作板でやってろ。

0408デフォルトの名無しさん

2009/09/12(土) 21:45:26

>>407
あー？
じゃあおめーは数式でも張れや

0409デフォルトの名無しさん

2009/09/12(土) 21:55:40

得意の描画でもこんなもんか

0410デフォルトの名無しさん

2009/09/12(土) 21:56:46

いやぁ、数式だなんて高級な言葉知ってるインテリさんには敵わないやｗ

0411デフォルトの名無しさん

2009/09/12(土) 22:12:08

1600SPってことは
よくてarray 20で粒度変わらず
悪くてarray 10で粒度倍

0412デフォルトの名無しさん

2009/09/12(土) 22:13:16

結局今年もGrape-DRが最強ってことで決まりだな

0413デフォルトの名無しさん

2009/09/12(土) 22:19:33

ttp://www.4gamer.net/games/045/G004578/20080725028/
ttp://www.4gamer.net/games/045/G004578/20080725028/images/13.jpg

>なお，北米版のプレゼンテーションでは，SIMD Unitが16SPで構成され，
>計1600SPあるように見えるブロックダイアグラムが存在していたが
>――単なるうっかりミスなのか，次世代GPUなりなんなりのものを誤引用したのかは不明――

配線の問題からも、クラスタ数そのままでSP倍増、粒度倍増の可能性大

0414,,・´∀｀・,,）っ-○○○

2009/09/12(土) 22:43:14

ATIだけ汎用性とは逆方向に進んでるな

0415デフォルトの名無しさん

2009/09/12(土) 23:19:31

>>399
テクスチャをフィルするだけで8秒って
インタプリタ言語でベタに書いたってそんなには
かからないだろ。
デバイスドライバが動いてないのかな？

0416デフォルトの名無しさん

2009/09/12(土) 23:22:17

>>415
いや違う。
RadeonはOpenCLが苦手だから
処理がとてつもなく遅いらしい

0417デフォルトの名無しさん

2009/09/12(土) 23:28:42

そもそも2.0betaはRadeon使ってない。
x86で計算しているだけ。

0418デフォルトの名無しさん

2009/09/13(日) 03:53:01

そ、おなじCPU処理で8万倍の差があるの
AppleとAMDでは

When I run it on ATI Stream SDK 2.0 beta on Windows,
I got terribly slow performance: around 8 secs per frame!
(On SnowLeopard OpenCL(CPU version) it runs around 0.0001 secs per frame)

0419デフォルトの名無しさん

2009/09/13(日) 04:00:36

>>ATIだけ汎用性とは逆方向に進んでるな

これはある意味正しい選択では
使い物にならないGPGPUに力入れてコスト上げるより
低コストのままベンチスコア上げるほうが売れるだろうし
短期的にはね

そのまま行けばサウンドカードと同じ運命だろうけど

0420デフォルトの名無しさん

2009/09/13(日) 05:17:17

まあ、CPUの仕事はGPUじゃなくてCPUにやらせりゃいいじゃんというのは、妥当ではあるさね

0421デフォルトの名無しさん

2009/09/13(日) 08:24:45

>>418
それAMDの掲示板で質問してるやつ
いたけど削除されたよなｗ

0422デフォルトの名無しさん

2009/09/13(日) 13:08:48

もしかして今のバージョンのATi ILてVLIWの中身を明示的に指定できないんだろうか？
ざっとリファレンスを読んだだけなんで、俺がやり方を見落としてるだけかもしれないが。

0423デフォルトの名無しさん

2009/09/13(日) 13:44:45

>>422
ISAで書いてcalclAssembleObjectを使う。

0424デフォルトの名無しさん

2009/09/13(日) 14:16:37

GPUやCPUのGFLOPS値の一覧があるサイトはありませんか？

0425デフォルトの名無しさん

2009/09/13(日) 14:35:59

>>423
ｔｈｘ　結局底まで降りるわけか。まあ、面白そうだからいいけどさ。
仕事なんかでやらされる奴はたまらんだろうな。

0426デフォルトの名無しさん

2009/09/13(日) 15:55:43

いよいよきたっぽい
NVIDIA Forceware 190.89 released - NVISION
ttp://forums.laptopvideo2go.com/topic/25115-nvidia-forceware-190-89-released/
These look to be an OpenCL driver set.

0427デフォルトの名無しさん

2009/09/13(日) 17:31:20

AMD終わったなｗ

0428デフォルトの名無しさん

2009/09/13(日) 19:16:16

ゲーハーかと思った

0429デフォルトの名無しさん

2009/09/13(日) 21:36:26

今更言うことでもない

0430デフォルトの名無しさん

2009/09/14(月) 21:36:42

やっぱりCUDAは捨てるんだな。手を出さなくて正解だったぜ。

0431デフォルトの名無しさん

2009/09/14(月) 22:43:46

>>430
それは負け惜しみｗ
超並列化の苦労に比べればプラットフォーム間の移植などものの数ではない。
CUDAで５０倍高速化させたら快適すぎる。
CPU版が止まって見えて、元に戻れない。

0432デフォルトの名無しさん

2009/09/15(火) 02:00:30

>>431
なあ、教えてくれ。
なんでCPUに比べて50倍も速くなるんだ？
例えばGTX280とかって240SPだろ？
今の標準的なCPUは4コアだけど、GPUのクロックより2,3倍速いし、しかもSSEだと各コアで4並列できるだろ。
あくまでも単純計算では、5-7.5倍くらいにしかならないようにおもえるのだが。
メモリ帯域に関してもCPUはでかいキャッシュがあるし、仮にキャシュが効かないアプリとしても、
10倍程度だと思うんだ。そういうアプリなのかね？それともCPU版のコードがへたれなのか？
教えてくれ。

0433デフォルトの名無しさん

2009/09/15(火) 04:10:12

>>431ではないが横レス。
IPCとかスループットとかメモリ帯域とかもっと多くの要因があるからそんなに単純な話ではないが、
例えばSSII09のチュートリアルでは行列積の場合512x512で24倍速いだとか言ってたな。
具体的な実行環境は失念。
SIFTのデモはCPUだと2～3FPSしか出てないのが100FPS超えてたりとか、
問題とか条件によってはそんくらい行く。

0434デフォルトの名無しさん

2009/09/15(火) 06:49:36

まぁ、4coreだからって全部使って演算されたら堪らんからな。
CPUより速いとかよりも、CPUの負荷を減らせることも魅力だし。

0435デフォルトの名無しさん

2009/09/15(火) 07:43:32

CPUとGPUの比較をしてもあまり意味がなくて、結局、GPUはアクセラレータとして捉えるのが良いってことか。

0436デフォルトの名無しさん

2009/09/15(火) 09:25:00

>>432
CPUはクロックが速くてもメモリ帯域が遅すぎる
処理によっては100倍どころか2000倍も存在する

0437デフォルトの名無しさん

2009/09/15(火) 11:32:38

経験上その手の数字は信用できないんだよね。
GPUベンダーに都合のいい数字だけを言っているだけで
前提となる条件が一切不明。ソースだせと言いたい

0438デフォルトの名無しさん

2009/09/15(火) 12:09:15

GPUに適した処理が、50倍とか100倍超になるのは事実。

でもGPUに適した処理、っていうのは、画処理とかの、
大データに対して同一の演算を行うものだから、
CPUが行っている様々な処理の種類なかでは少数。
重たい処理ではあるけど。

そもそも、GPUの性能が50倍とかにならないのなら、
そもそもPCにグラフィックスチップいらないわけで。

0439デフォルトの名無しさん

2009/09/15(火) 12:10:08

そもそも、が被った。orz

0440デフォルトの名無しさん

2009/09/15(火) 12:29:53

そもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそも
そもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそも
そもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそも
そもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそも
そもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそも
そもそもそもそもそもそもそもぞもぞもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそも
そもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそも
そもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそも
そもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそも
そもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそも
そもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそもそも

0441デフォルトの名無しさん

2009/09/15(火) 14:28:29

ttp://i27.tinypic.com/5cdtsm.png
ttp://i28.tinypic.com/22zwc0.jpg
ttp://i30.tinypic.com/10icr5u.png
ttp://i28.tinypic.com/fduic7.png
ttp://i29.tinypic.com/2hnown6.png

無難な改良アーキテクチャっぽい

0442デフォルトの名無しさん

2009/09/15(火) 16:05:33

>>436
良い事考えた。コア毎に独立した爆速メモリ積んで、その容量内で処理が完結するように
すればいいんじゃね？100％近いキャッシュヒット率を稼ぎ出せればCPUでも

0443デフォルトの名無しさん

2009/09/15(火) 16:27:52

>>441
これはすごい
NVIDIAとCUDA終わったな

0444デフォルトの名無しさん

2009/09/15(火) 17:43:19

>>441
サンダーテクニカルなアーキテクチャにされるよりはいいよ。

0445デフォルトの名無しさん

2009/09/15(火) 19:18:38

>>438
>大データに対して同一の演算を行うもの
ここは少し誤解があるような。
CUDAはもっと柔軟性があるよ。
カーネルコードにスレッドIDに依存する処理を入れても遅くならない。
if文も遠慮なく使っていい。
粒度のアンバランスがあってもwarpSize=32がなんとかしてくれることが多いｗ

CUDAが使えないのは、スレッド間で依存関係があるとき
（あるスレッドが別のスレッドの結果を使うようなとき）
だけでそれ以外は何とかなる。

スレッド間でデータ独立でループが長く、
スレッド数＝数百、グリッド数＝数百以上とれれば性能を出すのは簡単。

さらに共有メモリー（スレッド間で共有する配列）が使えるアルゴリズムのときは
１００倍超の爆速になる。

食わず嫌いの人は、ドキュメントとサンプルコードと格闘してくれ。そうすれば何とかなるよ。

0446デフォルトの名無しさん

2009/09/15(火) 21:22:19

>>445
嘘言うな。if文なんて最適化のときに削るべき対象だろうが
branch（特にdivergent branch）が増えると明らかに速度が落ちるし
tid使って分岐させる場合、ハーフワープ単位で揃えないと遅くなる

0447デフォルトの名無しさん

2009/09/15(火) 21:29:40

100倍速くなるってｗ
CPUにどれだけ糞コード食わせているんだって言うｗｗｗ

0448デフォルトの名無しさん

2009/09/15(火) 21:44:32

>>447
CPUに十分最適化されたコード食わせていたとしても、物によっては100倍のオーダーも有り得るぞ
ただ、よっぽどCPUに不向きでGPUに向いてるアルゴリズムの場合に限られるが
普通は10倍～だな

■ このスレッドは過去ログ倉庫に格納されています