GPGPU#5

[1 デフォルトの名無しさん 2010/08/15(日) 21:47:50]

GPGPUについて語りましょう

前スレ
GPGPU#4
http://hibari.2ch.net/test/read.cgi/tech/1255256230/l50

関連スレ
OpenCLプログラミング#1
http://hibari.2ch.net/test/read.cgi/tech/1228891105/l50
【GPGPU】くだすれCUDAスレ pert3【NVIDIA】
http://hibari.2ch.net/test/read.cgi/tech/1271587710/l50

参考リンク
総本山? 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/

[2 デフォルトの名無しさん 2010/08/15(日) 21:55:10]

＞998 ：デフォルトの名無しさん [↓] ：2010/08/15(日) 21:51:01
＞と言いつつAgeiaの中の人も今じゃAMDにいるからなぁ
＞とんだ詐欺師なのかねあの人

金です。

nvにとっちゃすでに用済みで、要らない子

[3 デフォルトの名無しさん 2010/08/15(日) 21:56:26]

専用設計とはいえPPUは58gflopsしかないんだが

[4 デフォルトの名無しさん 2010/08/15(日) 23:08:03]

基本的には、GPGPUが得意な処理を "適切なサイズ" に並列分割して
その分割された小包の集団をどかっとCUDAに押し込んでやると、分割が上手ければ
それなりに速く結果が出る。ただ、GPGPUで効率が出る並列化は簡単ではない。Larrabeeがこけたのもここ。

しかもC++のCUDA方言は不思議挙動だったりで、技術者がCUDAに習熟して十分な速度が
出せるようになるまでの時間を考えると、結構経費がかかる。だから、相当大きな話、というか
CUDAのX86@Intel CPUに対するワットパフォーマンス優位性が技術者の勉強代をカバーできる規模で無いと
わざわざわけわからん方言を勉強したくない。しかも、この方言は、いつまで有効かも怪しい。

だから、ほとんどの用途では、Nehalem-Ex とか、速いCPU乗せたマシンを増やした方が良い。
他のプログラムが、"全部" 速くなりますからねｗ

[5 デフォルトの名無しさん 2010/08/16(月) 00:00:44]

今後のCPUコアの高速化が鈍化するから
その対策として出てきたのがCPUのマルチコア化と
グラボのGPGPUとしての活用なわけで・・・

大部分の人には上位CPUなんて必要ないのと同様に
大部分のアプリにもGPGPUなんて必要ない。

６コアもGPGPUも本当に必要な人・アプリが使えばいいだけ

[6 デフォルトの名無しさん 2010/08/16(月) 11:53:00]

大部分って、静的WEBページを見るだけのユーザーのことか？ｗ
そんなもん無視でいいだろｗ

[7 デフォルトの名無しさん 2010/08/16(月) 23:36:42]

WEBブラウズだろうがオフィスアプリだろうが
音楽・動画再生だろうがゲームだろうが大部分のアプリには
高価な上位CPUも高速なGPGPUも必要じゃないだろ。

そこそこヘビーな自分でも4コア(疑似8コア)や
1TFLOPS以上のGPUをフル活用できるのは全PC作業の１割程度だし

[8 デフォルトの名無しさん 2010/08/18(水) 18:34:14]

LAMEとかiTunesとかで、GPGPUが効けばもっと広がると思うんだけど…
やる気無いですよねぇ

[9 デフォルトの名無しさん 2010/08/18(水) 20:00:08]

やる気程度で速くなってくれるなら今ごろみんな取り掛かってるだろうよ

[10 デフォルトの名無しさん 2010/08/18(水) 23:32:04]

LAME（音声の非可逆圧縮）程度じゃ処理が軽すぎるし
条件分岐も少なくないからCPUで計算したほうがいい。

映像編集ソフトですらエフェクト処理がメインでエンコードにはGPGPUが使えなかったりする。

iTunes（映像再生ソフト）にGPGPUとして使うなんて問題外。
大人しくOpenGLやDirect2DなんかでGPUとして活用すべき。
リアルタイムで映像にエフェクト処理を加えながら再生したいなら別だがiTunesの仕事じゃないｗ

[11 デフォルトの名無しさん 2010/08/19(木) 01:06:20]

ATI Stream使ってエンコードして負荷軽減してるソフトなかったけか？

[12 デフォルトの名無しさん 2010/08/19(木) 07:21:50]

>>11
PowerDirector？

[13 デフォルトの名無しさん 2010/08/19(木) 07:22:32]

エンコードに使うなら売りは速度ではなく品質にすべき。
データ転送がボトルネックなのだから
単位データあたりの演算量を増やさなきゃメリットが無い。

[14 デフォルトの名無しさん 2010/08/19(木) 11:52:21]

演算量が増えてもプログラムのフローが複雑になるようでは

[15 デフォルトの名無しさん 2010/08/19(木) 14:52:07]

>>14
どんだけ複雑になったって、大量に並列実行できればGPGPUにとってアドバンテージがある。
データに対して演算量が少なすぎると転送や処理待ちばかりになってパフォーマンスが上がらない。
だから問題は複雑性よりもデータの相互依存性とデータに対する演算量の少なさ。

[16 デフォルトの名無しさん 2010/08/22(日) 07:57:15]

複雑性ってなに？

[17 デフォルトの名無しさん 2010/08/22(日) 13:20:37]

文脈から鑑みるに、プログラムの複雑さじゃないの？

もっと端的に言ってしまえば分岐命令の数

[18 デフォルトの名無しさん 2010/08/22(日) 13:29:10]

この場合、相互依存性と複雑性は同義だと思うけどね。

[19 デフォルトの名無しさん 2010/08/22(日) 15:16:18]

>>18
この場合は違う。
>14 はそのつもりで発言しているのかも知れないが、>13 は違う。

[20 デフォルトの名無しさん 2010/08/22(日) 18:36:09]

そう言い切るのなら、どう違うかまでを説明せんといかんよ。