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/

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倍～だな

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

2009/09/15(火) 22:13:25

でもATIの実装は雪豹の2万倍遅いので
意味がないというわけですね

やっぱりIntelに期待するしかないのですね

ワカリマス

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

2009/09/15(火) 22:41:17

>>446-447
ネガティブなことを言うときりがないから。
性能はアルゴリズムによるから人それぞれ。
糞CPUコードって自己紹介か？
とにかくやってみろということだよ。

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

2009/09/15(火) 22:46:31

まぁ、CUDA限定の話はほどほどに。

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

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

>>440
一箇所「もぞもぞ」してるなw

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

2009/09/15(火) 22:54:16

50倍でも100倍でもいいけど、今後の最適化ポイントを探す参考にしたいから実例を挙げて欲しいなあ。

プロセッサはピーク性能出し切ってようやく10倍でしょ。
メモリはそもそも10倍も速くないでしょ。
メモリの性能に依存するなら10倍未満って事になるよ。
CPUがきちんと最適化されているならGPUが100倍になる理由なんて無いんだけど。

テーブルを引いてくる場合とかかな?
CPUだとテーブルを引く瞬間はSIMD化出来ないから。

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

2009/09/15(火) 22:58:27

CPUに8MBも高速低レイテンシのキャッシュ載っかってるのにそれが有効に使えてないってのはそれはそれで
問題外なような。

ローカリティとか意識してればGPUの1/50なんてことにならないぞ

しかしふと思った
やっぱCUDAって学生が力学とかの宿題解く分にはそこそこ有効なのかね。
書店でHPCプログラミングの本立ち読みしてたら、ああまさに大学生の宿題の応用だなと

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

2009/09/15(火) 23:00:27

GPUのプロセッサー性能は最新のCPUの1/5くらい。
それが240スレッドで動くから、結局50倍という計算。
もろもろのマイナス要因はあるが、バンド幅の大きさ、レジスタの多さなどの
プラス要因もあるから、うまく行けばトータルでその程度は出るという話。

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

2009/09/15(火) 23:01:09

>>453
GPUもGatherは遅いぞ
Half Warpぶんのベクトル長(512bit)に載っかるデータだけに関しては１サイクルのスループットで読み書きできる

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

2009/09/15(火) 23:02:08

> GPUのプロセッサー性能は最新のCPUの1/5くらい
> それが240スレッドで動くから、結局50倍という計算。

はぁ～？

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

2009/09/15(火) 23:05:07

1.3からdoubleがサポートされたが、ピーク性能はfloatの1/10だけど、
実際はいろいろなものに隠蔽されるから、速度低下は1/3-1/4くらいかな。
コンパイル時に-arch=sm_13が必要。
doubleがどうしても必要なときはためらわずに使ってもいい。

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

2009/09/15(火) 23:09:41

>>453
キャッシュラインの操作（GPUの場合は共有メモリだから厳密には違うけど）が明示的にできるか否かや
バス構成の違い、プロセスがTDMで走るかとかアーキテクチャそのものが違うわけで
アーキテクチャが変われば当然、適した問題も変わってくる
そういう2つを比較するんだから、単にデータシートから求まるピーク性能だけを持ってきても意味ないでしょ

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

2009/09/15(火) 23:10:18

OpenCLは文字列処理に向いてるのかね？

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

2009/09/15(火) 23:13:03

GPUを使う以上、文字列操作に向いてるって事はないだろう
SIMD的に規則正しく処理できるようなものならいけるかもしれないけど
普通、文字列操作ってifの塊だし

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

2009/09/15(火) 23:51:43

SSEならchar型16個を並列処理することができるし
SSE4.2でテキストサーチ用の命令が強化されてる。

GPUは1エレメントをchar*4のSIMDとして扱うような芸当はできないから
基本的に32ビットに拡張して扱うしかない

ハッキリ言って向いてない。

Larrabeeも整数は32ビット単位でしか扱えないようになってる。
汎用CPUと差別化してきてるね。

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

2009/09/16(水) 00:12:09

文字列処理は検索とコピーくらいしか並列化しようがないから、スカラの逐次処理との切替が素早くできる
CPU内蔵のSIMDで高速化するのが一番効率的なのです

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

2009/09/16(水) 00:13:21

だからデータシート云々言うんだったら実例挙げてごらんよ。
それが正しければへぇ、ってなるし、間違ってれば俺なり団子なりが訂正してやんよ。

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

2009/09/16(水) 00:18:56

スカートのチラリズムを計算したいんだが
方程式しらね
？

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

2009/09/16(水) 00:39:10

CPUで動くあるコードを持ってきたとする。でもそのままコンパイルするだけでは動かない。
結局、GPUを使う場合は、多少なりともGPUを意識したコードになり、
必然的にある程度最適化していると言うことで、同じ土俵ではないということ。

前とある学会であった発表で、GPU（G200）を使った結果がQX9650よりも８倍高速化されたというものだったが、
比較がなんとシングルコア。これだったらGPUを使わないでCPUを最適化してMPIでも使えと思った。
でも両方使えばもっとウマーだな。そういうことを考えていくとLarrabeeなりに行き着くのかな。

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

2009/09/16(水) 00:47:08

Cell Speed Challengeの参加者のレポートもそんなんばっかしだよ。

Core 2 QuadのSSEなし1コアに比べてCell（SPE6個・SIMD最適化）でこんだけ速くなりましたとか

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

2009/09/16(水) 00:53:37

まあ、がんばって最適化してみたら、思うように性能が出なくて、
仕方なしにリファレンスを変えるのは上等手段だしね。
やってきたことを如何に大げさに言うかが重要だからね。
嘘は言っていないから。

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

2009/09/16(水) 01:06:45

まあ、Core 2のSSEの性能と比較したらよっぽど都合が悪かったんだろうなぁと解釈した。
問題自体がCell向きとは言い難かったし。

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

2009/09/16(水) 01:36:52

両方使うというのは理想だけど
メモリ転送が遅すぎてどっちかでやったほうが速い。
これは並列化するアルゴリズムにもよるから
一概にはいえないけども。

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

2009/09/16(水) 01:57:48

>>466,470
実際にOpenMPとCUDAを併用して高速化を行った論文もあるぞ
CPU処理の初期データ生成を並列化するだけというものだから
俺たちからしたら知ってるよぉ！レベルの話だが

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

2009/09/16(水) 02:00:13

連投になるけどOpenCLはCPUやDSPのコードも書けるから
どっちも使うコードがメインになるのかな

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

2009/09/16(水) 02:19:47

CPUの場合も
OpenCLでやれば、SIMDの組み込み命令がどうだの
プリフェチがどうだの、考えなくていいんでしょ？
それに、CPUでfloat4やfloat4x4を扱うとき
どの環境も決定性に欠ける面もあるし、
OpenCLには期待しているのだけれど、、
とりあえずWindowsXPで動いてくれよ

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

2009/09/16(水) 02:19:50

>>471
CellやCUDAをきっかけにHPCに興味を持っていろいろと調べたり勉強しているのだが、
結構しょぼい論文が多い気がする。
コンピュータサイエンスにおけるHPCって以外とレベルは高くないのかな？
（そんなことはないと反論を希望したい。）
まあ、今までは特定の研究者しかさわれない分野が最近は一般レベルに落ちてきたら、
これからもっと発展するのか・・・な？

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

2009/09/16(水) 02:47:08

>>474
HPCってTOP500に代表されるように国際競争の場だから
外部の人間が自由に見れるような論文は当たり障りの無い内容が多いよ
TOP500の上位マシンは企業製で国家機関の管轄だし

このスレ的には例えば東工大が来年7月完成予定のTSUBAME2.0にCUDA採用を決めてて
その前段階としてベクトルマシンとGPUクラスタのワットパフォーマンスとかやってたけど
詳細な論文出てたっけな…

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

2009/09/16(水) 05:41:06

>>475
そんなことねーよｗｗｗ

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

2009/09/16(水) 07:12:36

少なくとも私の業務は企業機密に属するから紹介できないがな。
実装運営部隊ではOpenMPは嫌われていてpthreadで実装したがるのだが、
研究部隊であるうちではOpenMPもcudaもなんでもありで実験に使っている。
勿論、intelにも協力してもらっているのでtbbを意識した最適化も行なっている。

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

2009/09/16(水) 07:47:28

TBBで書いておくと勝手にGPGPUしてくれるライブラリってない？

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

2009/09/16(水) 08:22:10

>東工大が来年7月完成予定のTSUBAME2.0にCUDA採用を決めてて

無駄なことをするもんだ

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

2009/09/16(水) 08:24:11

スパコンではなくGPGPUでという前提だと、現状ではCUDA以外に使えるもんがないからしょーがないべ

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

2009/09/16(水) 08:35:01

その前程自体がおかしい

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

2009/09/16(水) 10:54:47

>>480
TSUBAMEはスパコンだが

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

2009/09/16(水) 12:50:58

>>477
「自称エリートのR&Dが糞コードを書く」の法則ですね

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

2009/09/16(水) 12:56:07

馬鹿ほど法則を乱造するの法則

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

2009/09/16(水) 13:54:11

メタすぎっぞオイ

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

2009/09/16(水) 13:56:48

ああ、メタメタやな

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

2009/09/16(水) 16:02:19

メメタァ

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

2009/09/17(木) 00:15:35

>>475
思うに、そういった狭い範囲での競争だから余り飛び抜けた様な内容があるのかな？
どちらかというとお金をかけまくって、ハードの進歩に依存しているような気がする。
スパコンベンチマークにしても未だにLINPACKとかでやっているのがそういったことを
表している様な気がしてならない。そろそろ、HDエンコードxxxxxxxxxxxMfps！とか
やってみた方が一般人には分かりやすいのではないかな？

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

2009/09/17(木) 01:11:12

一般人が使ったり知る必要がない気がする。
動画のエンコ・デコードや、3Dゲームですら、
PCユーザの中では少数派だし。
ましてや、プログラミングするわけでもないし。

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

2009/09/17(木) 07:05:09

そのとおり

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

2009/09/18(金) 07:29:19

GT300は4.8TFなんだなすげーな

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

2009/09/18(金) 09:08:10

理論値でなく実効値？

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

2009/09/18(金) 10:25:33

>>491
それが本当だとすると出回ってるダイサイズのデータと考え合わせると、
単位チップ面積あたりのFlops数が大体R870と並ぶ事になるわけで、
噂どおり、かなりアーキテクチャを弄ってるようだな。

>>492
ないない。

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

2009/09/18(金) 19:11:48

G300のスペックの情報なんて見たことないが

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

2009/09/18(金) 19:12:55

英語だとそれなりに出てくる。まあ、噂話レベルだが。

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

2009/09/18(金) 19:51:20

4.8TFlopsったらGT200の5倍弱だろ？
演算性能の水増しが簡単なラデでさえあの性能で300平方超えてるのにそんな真似できるんか？

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

2009/09/18(金) 20:04:44

サンプルチップの良品率が2%を切っているという愉快な噂も流れているし、
40nmで余裕が出来た発熱マージンを全部使い切った超巨大チップにしてるんじゃないの？

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

2009/09/18(金) 20:53:31

GT200の時点でGPGPUメインの「時代が付いて来い」設計だからなあ

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

2009/09/18(金) 21:29:15

GPU会社だけあってGPUの将来が見通せてたんだよ
お絵かきだけじゃもたないってさ

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

2009/09/18(金) 21:33:41

ATIはオートンが居なくなってから
2000,3000,4000,5000と4世代もアーキ更新なしか
AMDは本当にモノを作れない会社だな

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

2009/09/19(土) 00:20:12

4.8TFってすげーよな
でもこれってデュアルなんじゃねーの？

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

2009/09/19(土) 01:59:06

シェーダユニット数だけ見ると, AMD の圧倒的優勢に見えるんだけど...

RadeonHD一万円級 : 800 units
GeForce最上位 : 320 units

GeForce はなぜメモリバス幅が 448bit と中途半端なんだ?

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

2009/09/19(土) 02:00:56

AMDとかいうウンコの話はこのスレでは必要無い

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

2009/09/19(土) 02:10:38

>>503

げふぉとかいうクソの話はこのスレでは必要無い.

アンチラデ厨がいるぞ.

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

2009/09/19(土) 08:30:22

デコーダに連なるユニット全て1コアとカウントすれば

ﾗﾃﾞｵｿ・・・ワイドSIMD×VLIWの10コア
GT200・・・ワイドSIMDの30コア

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

2009/09/19(土) 08:57:52

AMDがBulletを: 新 masafumi's Diary
ttp://masafumi.cocolog-nifty.com/masafumis_diary/2009/09/amdbullet-7c91.html

無料同士で正面衝突かよ。共通規格は遠いなあ・・・

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

2009/09/19(土) 08:57:53

R800世代でも20coreか

nvは非x86のlarrabeeになりそうだし
方向性としてはモノを作れないAMDだけが明後日方向を向いてとりこのされてる感じだな
カークの言葉を借りれば、粗悪な大量のピクセルを目指して

次世代以降もIntelとnvidiaのにらみ合い
AMDは蚊帳の外

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

2009/09/19(土) 10:29:44

GeForce GTX 280の演算性能は933GFLOPS、Radeon HD 4870は
1.2TFLOPS(1200GFLOPS)であり、このスペックだけを見ると
Radeon圧倒的優勢に見えるが、一般的なGPGPUアプリケーションは
GeForceアーキテクチャの方が高効率に演算リソースが利用され
ハイパフォーマンスが期待できる。それではRadeonがダメなのかというと、
そんなことはなく、うまくSIMDユニットをフル活用するように
アプリケーションを構成できさえすれば、1.2TFLOPSの性能が発揮できることだろう。

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

2009/09/19(土) 10:33:44

お絵かき専門のどうしようもない代物だということだな

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

2009/09/19(土) 10:35:47

>>508
VLIWじゃ無理
RadeonはGeforceと同一の
アーキテクチャにしないと負ける

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

2009/09/19(土) 10:38:15

一般的なGPGPUアプリケーションってシェーダ効率以前の問題で、
GPU側で処理する粒度が小さすぎて、足回りの差が出ているだけ。
演算性能の殆ど無駄にして、CPUよりは速いレベルで喜んでいるのが殆ど。

50倍、100倍速くなるもともとGPGPU向けのアプリケーションの場合
逆に演算の汎用性なんか殆ど関係なく、最適化すれば
単純に素の演算性能に見合った実効性能がでる。
でかい密行列同士の積とか、Nbodyみたいな奴ね。

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

2009/09/19(土) 10:56:24

じゃあGrapde-DRでいいじゃん

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

2009/09/19(土) 11:03:11

Grape-DRは、素の演算性能が低いから
メイン用途のNbodyでGPU相手に太刀打ちできそうにない。

で、GPGPUより汎用性高いとかいう理屈で正当化する
必要に迫られたわけだ。

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

2009/09/19(土) 11:04:24

GPGPUなんてプログラムまともにかけねーじゃん

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

2009/09/19(土) 11:05:22

メモリ帯域狭いしな

利権・・・じゃなかった理研の人的にはLarrabeeはそれなりに前評判良いらしいけど

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

2009/09/19(土) 13:01:30

ATIは粒度でかすぎ
16*5*4=320
nv
8*4=32

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

2009/09/19(土) 13:04:05

charが計算できないものはゴミ

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

2009/09/19(土) 15:08:57

intelとnv
まだ両者とも物が無いんだよな

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

2009/09/19(土) 15:13:22

>>518
intelのは来月開発版貰えるだろ

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