トップページ⇒tech
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/
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倍〜だな
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と差別化してきてるね。
■ このスレッドは過去ログ倉庫に格納されています