GPGPU - GPUでプログラミング 50
ストーリー by yoosee
プログラミング言語はハードウェアの進化を乗りこなせるか 部門より
プログラミング言語はハードウェアの進化を乗りこなせるか 部門より
chiba-f 曰く、 "近年GPUの演算性能はCPUを上回り，その進歩の勢いは当分続きそうです．これを利用しない手はないと，GPUをCPUのように汎用目的で使おうと言うGPGPU (General Purpose GPU)なる動きが現れています．また，SIGGRAPH 2005ではこのGPGPUに特化したセッションが設けられました．MYCOM PC WEBには，このGPGPUについての解説とSIGGRAPH 2005のセッションを伝えるレポート「SIGGRAPH 2005 - GPUをCPU的に活用するGPGPUの可能性」が掲載されています．
現在，用途としてはGPUの特性から，(1) 巨大なデータを処理する，(2)各データ間の依存性は最低限である，(3)高い並列性をもって処理できる，と言った特質を持ったアプリケーションが考えられるそうです．GPUが汎用的に利用されるためにはそのためのプログラミング言語が必要ですが，CPUとは違ったアーキテクチャと言うことで，その実装は大変のようです．"
プログラミング入門書に載る (スコア:4, おもしろおかしい)
ポリゴンで描かれた"Hello World!"を表示させる
とかになるのでしょうか？
Re:プログラミング入門書に載る (スコア:0)
#↑をRogueと称するのには、個人的には抵抗があるが…
Re:プログラミング入門書に載る (スコア:2, 興味深い)
Re:プログラミング入門書に載る (スコア:0)
Pentium 4がサウンドサブCPUですかそうですか
Re:プログラミング入門書に載る (スコア:0)
GPUファンを制御することで鳴らします。
ファンレス品は別途ファンを増設してください。
……アレゲ？
Re:プログラミング入門書に載る (スコア:1, おもしろおかしい)
フロッピーディスクかハードディスクのシーク音でお願いします
#会社なのでAC
Re:プログラミング入門書に載る (スコア:0)
カツーン！カツーン！
ですか？＿|￣|○
＃体験者のみ＿|￣|○感を共有できるはず
Re:プログラミング入門書に載る (スコア:0)
せめてNethackを希望。
テキスト版は挫折。GUI版もいまいちだし。
必要なのは言語ではなく (スコア:3, すばらしい洞察)
スパコンの場合、コンパイラがfor文の並列性を解析して勝手に並列化してくれるので、プログラマは普通にプログラムを書いて、その後で最適化を妨げる書き方をしていればそれを書き換える、というのが一般的な手順でした。
この方式だとプロセッサに関する専門知識を(あまり)要求されないのでプログラマの負担が少なくて済みます。
難点は(スパコン用の)並列化をしてくれるコンパイラはたいていの場合とっても高価だった、ってことかw
＃あるいはカリカリに最適化してくれるコンパイラは大抵商用でそれなりの値段がするというのはもう過去の話?
最適化 (スコア:2, 参考になる)
最適化というのは要するにアーキテクチャの選択であるわけです。
その最適化するというのがコンパイラであるとは限りません。
ハードウェアが最適化するというアーキテクチャの種類もあります。
コンパイラ側がするのがVLIWというもので、ハードウェアが
するものがスーパスカラというものです。確かIntelの路線は
スーパスカラだったと思います。
ですから、必ずしもコンパイラが最適化を図るというわけでは
ありませんよ。まあ、GPUがVLIWかスーパスカラのどちらの
路線かは分かりませんけれども。
Re:最適化 (スコア:1)
フォロー感謝。 (スコア:1)
ItaniumがVLIWとは知っていましたが、おぼろげでした。
ありがとうございます。
Re:最適化 (スコア:1)
そうやって、いままで演算性能を上げてきたわけですから。
Re:必要なのは言語ではなく (スコア:0)
より重要なのは特定のプロセッサへの依存性が低くなって他のプロセッサへ移植しやすくなることではないでしょうか。
GPU(というより汎用ベクタプロセッサ)のアーキテクチャが標準化されるとも思えないので囲い込みはない方が良いと思う。
Re:必要なのは言語ではなく (スコア:0)
Re:必要なのは言語ではなく (スコア:0)
>正常なGPU は小さい間違いを作る。
が真なら興味深い意見です。
しかし、本当ですか？
それをディスプレイに出力する過程では、ビット単位の正確性はもしかしたら求められないのかもしれない、という
更新しつづけることの利点と欠点 (スコア:3, すばらしい洞察)
を上げてきたわけだが、こういう形で利用されると、しがらみが発生
してしまうやうな気がする。
コンパイラやトランスレータで、急速に変化しつづけるアーキテク
チャーをどこまでカバーできるだらふか？
Re:更新しつづけることの利点と欠点 (スコア:2, 興味深い)
そのまま代替するハードをまるごと作り込むことでアクセラレーションを
行っているのがありましたが、もしかするとMicrosoftの策定する仕様が
GPUのアーキテクチャと命令セットを規定するという方向になるのかもしれません。
Re:更新しつづけることの利点と欠点 (スコア:1)
GPUがしがらみを背負うというかMPU同様に互換性の問題を抱える。
GPUの互換性問題を解決するためにトランスレータ技術が発達。
トランスレータ技術が十分に熟成した時点でMPU向けに転用。
MPUも過去のしがらみから開放されてGPUと同程度には性能向上。
GPU/MPUに限らずとりあえず汎用性が見込めるナントカプロセッサ多数搭載のマルチプロセッサ構成でPC全体の処理速度が飛躍的に向上。
というのが理想的な気がするんだけど、そういう方向に進まない気がするのは何故だろう？
Re:更新しつづけることの利点と欠点 (スコア:1, 興味深い)
実行するときにコンパイルできます。
したがって、これを応用すればソース一本であとはコンパイラ任せが出来る。
なので、ハードウェアが勝手に進化してもついて行ける(はず
人より先を行こう (スコア:2, 興味深い)
そこで我々は一足先を行くPPU [srad.jp]での汎用処理ですよ。
まぁ、それはともかく、GPUを汎用処理に使うって発想は前々からちょくちょくありましたよね。何年か前ににnVidiaが処理言語を発表した時にも、「これじゃあCPUと変わらんねえ」なんてコメントが付いたのを思い出しましたよ。
せっかくだからもう一歩先を行こう (スコア:2, 参考になる)
http://www.ipa.go.jp/jinzai/esp/2004mito1/mdata/3-46.html
妖精哲学の三信
「だらしねぇ」という戒めの心、「歪みねぇ」という賛美の心、「仕方ない」という許容の心
Re:人より先を行こう (スコア:0)
Re:人より先を行こう (スコア:1)
Re:人より先を行こう (スコア:0)
Re:人より先を行こう (スコア:0)
歴史は繰り返す!? (スコア:2, 参考になる)
FM シリーズで遊んでた人にはサブCPU までしゃぶり尽くすってのは普通だったような。"YAMAUCHI"コマンドとかね。:)
あと、メガドライブなんかでもそんなのあったような気がするんですが。。。（覚えてる人います？）
#もとFM-11 ユーザ
Re:歴史は繰り返す!? (スコア:2, 参考になる)
あと、FDD内蔵型のPC-8801(mkII以降)は、FDD制御用のサブCPU(Z-80)があります。
で、PC-88版のシルフィードも、このサブCPUを酷使してました。
というわけで、GPGPUの力を見るにはゲームアーツに
ゲームを作ってもらうのがいいのではないかと思ってみたり…
Re:歴史は繰り返す!? (スコア:0)
FDC制御用のZ80互換CPUでしょ?
>で、PC-88版のシルフィードも、このサブCPUを酷使してました。
ファイルシステムの管理ぐらいじゃなかったっけ? あとなんかに使ってた?
Re:歴史は繰り返す!? (スコア:1)
本物のZ80じゃなくて互換品なのはその通りですが、
「FDCを通して、FDDを制御するためのCPU」ですから、「FDD制御用」と言っても間違いじゃないでしょう。
メインCPU(NEC μPD780C-1 = Zilog Z80A 非正規互換品) -[CPUバス]- パラレルインターフェース(μPD8255 = Intel 8255互換品)
-[パラレル通信]- パラレルインターフェース(μPD8255) -[CPUバス]- サブCPU(μPD780C-1)
-[CPUバス]- FDC(μPD765 これはNECオリジナル) -- FDD
って形ですね。
元々、パラレルポートを経由して接続していた外付けFDDをまるごと内蔵させたものだから、
こんな複雑な構成になっちゃったと。
> ファイルシステムの管理ぐらいじゃなかったっけ? あとなんかに使ってた?
もう20年ぐらい前に雑誌か何かで読んだ、うろ覚えな記憶ですが、
たしか、シルフィードはFD上にはデータを圧縮したものが記録されていて、
それをサブCPUで展開してからメインCPUに渡していたと思います。
Re:歴史は繰り返す!? (スコア:0)
>たしか、シルフィードはFD上にはデータを圧縮したものが記録されていて、
>それをサブCPUで展開してからメインCPUに渡していたと思います
Re:歴史は繰り返す!? (スコア:0)
>たんだろうか?
その利用法だとリアルタイムに圧縮してあるものを伸張するのですが、
当時のプロセッサにはLZHで利用している圧縮法は十分重い処理でしたし、
利用できた作業用メモリがどれだけあったかは
Re:歴史は繰り返す!? (スコア:0)
Re:歴史は繰り返す!? (スコア:0)
サウンド用のZ80ですか?
メーンの68Kに比べて非力ですし、あんまサウンド以外のことやらせてもメリットは少ないような気がしますが。
Re:歴史は繰り返す!? (スコア:1)
Re:歴史は繰り返す!? (スコア:0)
追加リンク (スコア:2, 参考になる)
GPUを汎用的に使おうと言う話が結構あると言うことは以下の記事で知りました：
5年後に“GPUスパコン”の時代がやってくる!? --- 後藤弘茂のWeekly海外ニュース [impress.co.jp](2003年12月26日)
去年開かれた最初のGPGPUのワークショップの記録です．この時点では名称はGP2(GPGP)でした：
ACM Workshop on General Purpose Computing on Graphics Processors [unc.edu]
実際にGPUやGPUベースのクラスタ（！）で計算している人たちがいます：
General-Purpose Computation on GPUs or a GPU Cluster [sunysb.edu](Visualization Lab at Stony Brook University)
URLは書きませんが，GPGPUのメーリングリストもあるようです．名称はGpgpu Info Page．
nVIDIAのGPGPUのページ：
GPGPU: Beyond Graphics [nvidia.com]
##お読みになって下さった方々へ．タレコミの文章がのたくっていて，済みませんでした．
Re:追加リンク (スコア:1)
http://www.bee-www.com/ [bee-www.com]
「ナビエストークス方程式の全ての計算がGPU上で行われています．
512^2でもインタラクティブに動くとは…GPU恐るべし．」
とのことです。
この文章を書いているマシンでは動かないので、私自身はまだ試していませんが。
Quartz Composer (スコア:0)
Re:Quartz Composer (スコア:1, 参考になる)
ただ、Quartz Composerも利用しているCore Imageという技術のなかに本トピックに関する技術があります。
Re:Quartz Composer (スコア:0)
Quartz Compositorの機能をGPUにやらせるのがQuartz Extremeで、いっそもう描画全てをプログラマブルなGPUにやらせてしまえというのがQuartz 2D Extremeです。
http://arstechnica.com/reviews/os/macosx-10.4.ars/14
大昔のAV Macですか (スコア:0)
なんでGPUなの? (スコア:0)
Cell使えばいいじゃん。
こっちの方がよっぽどプログラムするの楽じゃない?
Re:なんでGPUなの? (スコア:1)
GPU にしても、廉価だから使うという面があるし。
本来なら、倍精度を高速でこなせるものが望まれているはず。
こういうサブユニットを積んだ MPU を作りませんか？> Intel or AMD
Re:なんでGPUなの? (スコア:0)
そしてCellはついてないでしょう？
Cell増設して専用処理するくらいならCellなワークステーションを作ってもらったほうがましでしょう？
Re:なんでGPUなの? (スコア:0)
3DがいらないときはエンコProcessorとして働けるし。
#むしろ、後者に期待しているけど
Re:なんでGPUなの? (スコア:0)
Re:なんでGPUなの? (スコア:2, 興味深い)
私はCellをPPUの変わりに使うという発想の方が素直だと考えていますが，それでも近代的なPCには高速で高度なGPUが積まれていることを考えると悪い発想ではないかなと思います．
アプリケーションとしては，画像・音声関係の解析・エンコード・デコードなどがキラーアプリケーションになるかなぁと思ってます．
ぐぷぐぷぅ？ (スコア:0)
これ、なんて読んだらいいんですかね？
Re:ぐぷぐぷぅ？ (スコア:0)
「くぷぅ」？