12/10/13 00:49:49.97
分岐というか、単純に帯域の問題じゃね。
257:デフォルトの名無しさん
12/10/13 02:04:35.67
あのプレゼン見たけど、プログラミングに自信のある計算機寄りの人が、
てきとーに題材みつけてきて、計算機科学の研究として発表してる感じだった。
その結果が15%
258:デフォルトの名無しさん
12/10/13 02:37:46.42
計算目的よりも、tubameを生かすための作業やね。まあ察しはつくがw
259:デフォルトの名無しさん
12/10/13 03:38:41.47
>>252
蟻の巣からよく働く2割の蟻以外を取り除いても、
残った蟻の8割がなぜか怠け始めるんだそうな
260:,,・´∀｀・,,）っ-○○○
12/10/13 04:49:03.94
>>250
働いてないんじゃなくて何かしらがボトルネックになってFMACの稼働率が抑えられてるのでは？
メモリ帯域が足りてる場合でも同時命令発行数の制約でload/store命令と積和命令を
同時に実行できない、とか
（これは京のVenusアーキテクチャにもある制約）
261:デフォルトの名無しさん
12/10/13 16:36:04.21
唐突ですまんけど、AMDはファイル名通りのこういう資料があるけど
URLﾘﾝｸ(developer.amd.com)
nVIDIAはこういうの無いの？
262:デフォルトの名無しさん
12/10/13 18:21:13.66
>>249
効率はFLOPSに対する効率であって、気象系のアプリは
バンド幅律速だからLINPACKと比べること自体ナンセンス。
ちなみに15％は気象系のステンシルアプリとしては高い方。
263:デフォルトの名無しさん
12/10/13 18:24:01.07
>>257
そらまぁ、青木研究室の存在意義が「GPGPUでできることを広げる」
だからね。仕方ない。
NECのSXが沈没の今、京かGPGPUしか無いわけで･･･
それともBlueGeneを買うか？
264:デフォルトの名無しさん
12/10/13 18:27:15.78
FLOPSに対する効率だから、アルゴリズム自体の並列化効率以上にはなりえないわけか。
気象系のアプリというものの並列化効率がどんくらいなのか知らないけど（なんとなく高そうではあるが）。
265:デフォルトの名無しさん
12/10/13 18:51:02.05
>>264
うーん、微妙に違うな。
今時のアーキテクチャだとメモリがすごく遅いってのは知ってるだろ？
ちなみにメモリの速度はバンド幅って言う。
それに対して演算速度はムーアの法則でどんどん上がってる（上がってた）
から、バランスが全然とれてないんだ。だから、普通のCPUはキャッシュ階層を
深くして（L1、L2、L3とか）なるべくデータの再利用をしてる。
つまり、データをメモリから持ってきたら、なるべくそれを
使い回して計算したいわけ。
で、ここで問題になるのが、浮動小数点演算（FLOP）と、データ転送量の比。
業界だと byte/flops とか言われる。言い方を変えると、どれくらいデータの
使い回しが効くかってこと。
続く
266:デフォルトの名無しさん
12/10/13 18:52:43.77
承前
アプリの要求byte/flops高いと、せかっくデータを持ってきても
たいした計算をせずに、すぐに次のデータが必要になっちゃう。
データの使い回しが効かないんだ。これはイマドキの計算機にとってはキツい。
で、気象とか流体とかはそういうアプリなわけ。
だから、基本的に流体とかの計算は演算は余ってて、バンド幅がボトルネックになる。
これはアプリの特性だから仕方ない。
気象･流体屋さんは、未だに地球シミュレーター信者みたいな人が多い。
ちなみに、気象・流体系アプリは並列度だけで言ったらはものすごくあるよ。
ちなみにスレ的に言うと、GPUはGDDR５っていう容量が少ない代わりに
バンド幅が出る贅沢なメモリを搭載して、かつ大量のスレッドを使うことで
レイテンシを隠蔽してる。これがGPGPUが気象・流体計算に使える理由。
267:264
12/10/13 19:29:29.68
なるほど、つまり気象系のアプリはコンピュートバウンドではなくメモリバウンドのものが多い、と。
AMDのAPUの使い道の話になったときに、DDR3という制約に悲観的になってる人が少なそうだったから
世の中にはメモリバウンドのものは少数派なのかなあとも思ってたけど普通にあるんですね。
268:デフォルトの名無しさん
12/10/13 19:43:21.60
バンド幅と言うか、物理原理的にDRAMのセルは応答が現代のCPUの演算速度に対してずっと遅い。
だから、メモリセルを並列にして同時に読み出し・書き込みするしかないのが根底にある。それをやれDDRxだの、
何ビット同時にアクセス＝複数セルに同時アクセスでなんとかしてるね。
気象系や気体がどうのって言うよりも、規則正しく計算点を並べて偏微分方程式の数値近似式を一斉に走らせる
＝SIMDだのシェーダだの言ってる演算回路がみんな一斉に同じ計算式をやる場合が最大性能が出る。
三次元の方がそりゃ、並列度は高いだろうね。境界条件とか面倒くさそうだが。
こういう根本的なところはもう全然進歩しないなw
269:,,・´∀｀・,,）っ-○○○
12/10/13 20:27:18.96
bytes/flopsに関して言えば現状GPUはCPUより低いです。
ただbyte/sが数倍高くて、flopsが更に数倍高いというだけの話で。
Haswellあたりで、電力当たりFLOPS数はGPUとCPUは互角くらいになるのではという話も出ていますな。
270:デフォルトの名無しさん
12/10/13 20:32:24.78
TSVって、GPUみたいな爆熱チップでもできるの？
271:デフォルトの名無しさん
12/10/14 11:35:52.75
>>241
亀レスだけど、何のペナルティも無く普通のx86コアを50個
並べられるなら誰も苦労してないわけで･･･
272:デフォルトの名無しさん
12/10/14 12:44:22.63
DRAM内部のクロック
PC133 133MHz
DDR3-1600 200MHz
この間十数年・・・MRAMならもっと上がるかな？
273:デフォルトの名無しさん
12/10/20 09:38:39.11
GNU MPのGPGPU対応って、あんまりやってる人が居ないな。
274:,,・´∀｀・,,）っ-○○○
12/10/20 09:42:31.34
依存関係があってなかなか並列化しにくいからね。
もちろん並列度の高いコンピュータに適した数式に置き換えればいいんだが
CPU側もAVX, FMAなどでGPGPUの電力効率の優位も揺らぎつつあるからね
275:デフォルトの名無しさん
12/11/17 23:26:42.82
C++AMP調べてるとこなんだけど
textureでピクセル間を補間する方法がわからない。
ひょっとして自前でやらないといけないの？
「C++ AMP API は、サンプリング テクスチャのフィルター処理機能を提供されません。」
とはこのことなのかな。
276:デフォルトの名無しさん
12/11/18 21:58:01.39
c++ampにfloat_3のmadやfmaが無いね。 short vector typeのmadやsin, cos などの超越関数も用意してもらいたい。 swizzlingはできるみたい。 OpenCLの方がコードをコンパクトに書けるかな。次期版期待してます。