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/

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と差別化してきてるね。

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ユーザの中では少数派だし。
ましてや、プログラミングするわけでもないし。

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