08/10/05 15:58:52 KNap0rF0
※ 当スレは固定ハンドル非推奨となっております。
3:Socket774
08/10/05 16:00:37 AU8yjwvo
1時間エアロバイク漕ぎながら待ってたんですが
新スレ立たなかったので立てちゃいました。
4:Socket774
08/10/05 16:01:01 KNap0rF0
固定ハンドルで議論をしたい人、このスレッドで話題にするまでもない痴話喧嘩は
こちら↓
私の肛門もフェンスに強制終了させられそうです #3
ｽﾚﾘﾝｸ(jisaku板)
5:Socket774
08/10/05 16:09:48 WHIgITGQ
前スレの団子はあいかわらず酷いな。
Win32 fiberとかJITとか誰もそんな議論していないのに。
6:Socket774
08/10/05 16:11:52 YrFE5okz
どうでもいい方向に話を逸らして思考停止するのは常套手段。
7:MACオタ＞5-6 さん
08/10/05 16:15:27 IsV0akqP
>>5-6
私わ、その辺の資料に書いてある内容をそのまま引き写してきたような投稿より、団子さんの方が
面白いす。
8:Socket774
08/10/05 16:15:55 WHIgITGQ
自己レスだけど
>>957
> 上のLarrabeeの資料は、あくまでGPUの場合の話だな。
> Larrabeeも他のGPU同様quad単位で処理するようで、
> あるシェーダのコンテキストのquadを1xcoreに投入
> →(最大)4xHW Thread→(最大)4xFiber→(最大)64xstrands
> となるという説明とおれは理解した。
この(最大)4xFiberというのは同時に実行されるfiberの数を言いたかった。
typically 2-10というのは一つのシェーダがその数のfiberに分割されるという意味では？
64xStrandsの説明がつくのはこの解釈だけに思える。
そうでないならここの説明はどうする？＞MACオタ他、否定する人たち
いずれにせよ
> 4xHW Thread ＝ Fiber
> という言葉の理解は奇妙に思える。
は確かだけど。
誰もこのFiberがWin32 Fiberだとは思っていないよ。
9:Socket774
08/10/05 16:16:03 AU8yjwvo
資料読んでだいたいの事は把握したんですが、
?Saves live registers
?Saves the IP to resume at
?Jumps to the next fiber’s IP
?Next fiber restores live registers
?Gets texture result, continues shading
ってH/Wスレッドと併用しながら処理すると思うんだけど何命令ぐらい使うんでしょうか？
大半も命令のレイテンシが8以下って事なんで、それ以内で処理しきれないとデータハザード回避の意味はないですよね？
ちなみに長いレイテンシを隠蔽するのは4つのH/Wスレッドのコンテキストスイッチだけでは不十分なので、
Fiberと併用してレイテンシを隠蔽してALUを回し続けるとのこと。
また自己レスになりますがベクトルレジスタが少ないって前スレで投げましたがLarrabeeはR/W可能なL1があるのでまったく問題がないです。
勝手に他のGPUと同じようにL1はReadOnlyなのかと勘違いしました。
因みにLarrabeeの資料リンク↓
URLﾘﾝｸ(s08.idav.ucdavis.edu)
URLﾘﾝｸ(s08.idav.ucdavis.edu)
URLﾘﾝｸ(s08.idav.ucdavis.edu)
10:,,・´∀｀・,,）っ-○◎●
08/10/05 16:16:18 PiRb9Agc
>>5
だってFiberと名の付くものは同じ実装だと思い込んでる子がいるんだもの。
Win32 Fiberの話題を振って「これと同じす」と言ったのはMACヲタ
「別物」と言ってやってるのに聞かないから困りものだ。
11:,,・´∀｀・,,）っ-○◎●
08/10/05 16:17:53 PiRb9Agc
>>8
そんなことは俺も言ってない
1-4×HW Thread = n×Fiber
12:Socket774
08/10/05 16:17:57 WHIgITGQ
>>8
> この(最大)4xFiberというのは同時に実行されるfiberの数を言いたかった。
1つのコアあたりの話ね。
もちろん同じバイナリのfiberは他のコアでも動いているだろう。
13:Socket774
08/10/05 16:22:50 WHIgITGQ
>>11
それは団子が言った
> LarrabeeでいうところのFiberは同じ1コアで動かすべき4つまでのスレッドを纏めたものにすぎない。
を訂正するという意味？
14:,,・´∀｀・,,）っ-○◎●
08/10/05 16:23:45 PiRb9Agc
>>9
アドレッシングモード付き積和算で10クロックは軽く超えそうだよ
4HW Threadフルに使うケースでは命令レベルで、そこの資料にも書かれてる10並列のインターリーブは
多くの場合不要ではないかと。
オペレーションの命令レイテンシ×16÷各FiberのStrand数＋α
くらいが実際にインターリーブが必要なFiber数になるかと。
15:MACオタ＞8 さん
08/10/05 16:24:05 IsV0akqP
>>8
-----------------
64xStrandsの説明
-----------------
Strandわ"a program invocation that runs in one SIMD lane"す。レジスタを一つしか使わない
プログラムなんて無いすから、16-wide x 16-registers で256 strandsなんてことわ無いって
だけかと。
16:,,・´∀｀・,,）っ-○◎●
08/10/05 16:25:40 PiRb9Agc
>>13
それ自体は矛盾しないだろ？
スレッドとFiberの関係はどちらかに N : 1 対応するものではないということ。
17:Socket774
08/10/05 16:27:47 KNap0rF0
固定ハンドル使いは自己防衛に入りすぎて議論ができないやつが多いから非推奨
実質、このスレの名無しとレベル変わってないのはもう明らかなんだから名無しでかきこみゃ十分だろ。
>>8
64 strandsは単にLarrabeeのruntimeの仕様じゃねーの?
現時点で無理に正確な解釈を導きだそうとしなくてもいい。
2-10っていのはtypicallyなんて書いてない。
LarrabeeをGPUとして使う場合はTextureユニット数の制約もあるし、
その関係かもよ。
いずれにしろ団子みたいに何が何でも俺の妄想が真実だと強要するバカはいらない。
18:Socket774
08/10/05 16:30:37 WHIgITGQ
>>15
すまんが意味がわからない。
256じゃないから64という理屈？
19:MACオタ＞17 さん
08/10/05 16:31:31 IsV0akqP
>>17
--------------------
2-10っていのはtypicallyなんて書いてない。
--------------------
URLﾘﾝｸ(s08.idav.ucdavis.edu) (p.12-14, )
=====================
More Fibers running (typically 2-10, depending on latency to cover)
=====================
20:,,・´∀｀・,,）っ-○◎●
08/10/05 16:32:29 PiRb9Agc
>>16
いいや何度も言うが、Strand数は16×スレッド数だよ。
同じ命令コード列を～4スレッドでインターリーブして実行した方がコードキャッシュ容量の節約になるし
同じコアで動くスレッド間でのデータ交換にペナルティがない機構を十分に発揮するのに都合が良い。
21:MACオタ＞18 さん
08/10/05 16:33:58 IsV0akqP
>>18
-------------------
256じゃないから64という理屈？
-------------------
この辺の数値わ典型例の模様す。
64ってのわinelがLarrabee用に書いたコードで実際に存在するんだと思われるす。
22:Socket774
08/10/05 16:35:43 WHIgITGQ
>>16
いやいや
明らかに言ってること変わってますやんw
訂正するなら訂正してくれないと議論が混乱し続けるだけだよ
23:,,・´∀｀・,,）っ-○◎●
08/10/05 16:35:53 PiRb9Agc
16レジスタ全部使うとかどんだけ？
テンポラリすら確保できねーぞ。
せっかくVEXプリフィクスでNon Destructive Sourceレジスタ追加したのに意味ね-ｗｗｗ
24:,,・´∀｀・,,）っ-○◎●
08/10/05 16:39:54 PiRb9Agc
>>22
いいよ。正確に言おう
FiberはCPU時間を細粒度で時分割したものではある一方で
Threadに対する完全な従属関係ではない。
64 Strandなら同じコアで動く4スレッドで分割処理される。
最初から命令レベル並列に振るよりは、スレッドで分割するように振った方がコードサイズもレジスタも節約できる。
25:MACオタ＞団子 さん
08/10/05 16:40:58 IsV0akqP
>>20
--------------------
同じ命令コード列を～4スレッドでインターリーブして実行した方がコードキャッシュ容量の節約になるし
同じコアで動くスレッド間でのデータ交換にペナルティがない機構を十分に発揮するのに都合が良い。
--------------------
かつて同じことを想定した立場で書くと、リネーム無しで命令をインターリーブするためにわ使用
レジスタが重ならないようにすることが必須す。しかしプレゼン資料によると、
URLﾘﾝｸ(s08.idav.ucdavis.edu) (p.25)
=====================
- No hardware or OS support .no pre-emption
- Also called “coroutines”
=====================
ということで、レジスタウィンドウのようなハードウェアサポートも無く、既存の「コルーチン」と同じモノ
と記述があるす。またfiberわインターリーブでわ無く「スイッチ」が必要なことも明記されているす。
=====================
Fiber switch on texture request submission
- Saves live registers
- Saves the IP to resume at
- Jumps to the next fiber’s IP
- Next fiber restores live registers
- Gets texture result, continues shading
=====================
26:Socket774
08/10/05 16:42:41 KNap0rF0
>>19
同一スレッド内でlatencyをカバーするためにファイバが入れ替わり立ち替わりに動く。
典型的には2-10ファイバが入れ替わる。
他の数字は典型例ではないでしょう。
SW-managedなファイバが今のruntimeの仕様で64 strandsなら別に納得できるし。
>64 Strandなら同じコアで動く4スレッドで分割処理される
そもそも1 threadで10 fiber(160 strands+ ?)くらいは入れ替わってくれる図があるんだからその解釈はおかしいだろ。
27:MACオタ＞団子 さん
08/10/05 16:43:52 IsV0akqP
>>23
------------------
16レジスタ全部使うとかどんだけ？
------------------
Strandの単位わ、レジスタでわなくSIMDの1-wayす。つまり一つのSIMD命令で最大16-strandsが
処理できることになるす。(マスクアウトされて全データが有効でわ無いすけど。。。)
28:,,・´∀｀・,,）っ-○◎●
08/10/05 16:44:58 PiRb9Agc
＞かつて同じことを想定した立場で書くと、リネーム無しで命令をインターリーブするためにわ使用
＞レジスタが重ならないようにすることが必須す。
だからそれはJITにやらせることが可能だって。
公開中止になったSoftWireと同じことをやってるライブラリが既にあって
URLﾘﾝｸ(homepage1.nifty.com)
ここのboost::spiritを使った簡易電卓のサンプルでやってることがまさにそれだろ？
で、ついでだからコミット履歴も見てくれ
29:,,・´∀｀・,,）っ-○◎●
08/10/05 16:45:55 PiRb9Agc
>>27
16×16 = 256 Strandって言ったのはお前だろｗｗ
30:MACオタ＞団子 さん
08/10/05 16:46:18 IsV0akqP
>>28
リネームレジスタがあるOoOEコアと比較してわダメす。
31:Socket774
08/10/05 16:46:37 KNap0rF0
はあ、アホ固定コンビ疲れる。
また自己顕示で暴走しそうな展開になってきたな。
無理に確定的な結論だそうとするな。
32:,,・´∀｀・,,）っ-○◎●
08/10/05 16:46:46 PiRb9Agc
インオーダのAtomでも動くライブラリなんだけど。
33:MACオタ＞団子 さん
08/10/05 16:47:10 IsV0akqP
>>29
あなたわ『単位』が読めないすか？
34:MACオタ＞団子 さん
08/10/05 16:48:20 IsV0akqP
>>32
速度という観点わ何処へ？
35:Socket774
08/10/05 16:49:39 AU8yjwvo
たとえば
mad r0.xyzw, r1.xyzw, c0.xyzw, r0.xyzw
のシェーダー命令を16個のフラグメントに対して処理するときは
ｒ0 = 16個のr0.x要素
ｒ1 = 16個のr0.y要素
ｒ2 = 16個のr0.z要素
ｒ3 = 16個のr0.w要素
ｒ4 = 16個のr1.x要素
ｒ5 = 16個のr1.y要素
ｒ6 = 16個のr1.z要素
ｒ7 = 16個のr1.w要素
として、Larrabeeのベクトルユニットだと
mad r0,r4,c0.x,r0
mad r1,r5,c0.y,r1
mad r2,r6,c0.z,r2
mad r3,r7,c0.w,r3
#16要素のswizzleの書き方がわからん
みたいになるわけだよね？
シェーダーは4要素が基本だから16strandx4要素で64strandになってるんじゃないかと思ったんだけど
まったく検討違いかもしれない。
36:,,・´∀｀・,,）っ-○◎●
08/10/05 16:51:02 PiRb9Agc
コア全体で各スレッド16本、64本のSIMDレジスタがある。
これが足りないと思うか？
レジスタ番号はJITコンパイルするときまで決めなくていいんだぜ？
Native C/C++やアセンブラを使ったプログラミングモデルでも
Fiberなんてものが利用できると思ってるから混乱するんじゃね？
37:,,・´∀｀・,,）っ-○◎●
08/10/05 16:55:29 PiRb9Agc
>>35
64個の互いに独立なデータに同じ処理をするとして
vfmaddps zmm0, zmm1, zmm2, zmm3
vfmaddps zmm4 zmm5, zmm6, zmm7
vfmaddps zmm8, zmm9, zmm10, zmm11
vfmaddps zmm12, zmm13, zmm14, zmm15
なんてやんなくても、4つのスレッドで同じ
vfmaddps zmm0, zmm1, zmm2, zmm3
を実行したほうがコード量もレジスタも節約できるじゃないの。
前者が必要なのは同一ファイバー内のStrandを処理するときでなくて
HWスレッドで隠蔽できないレイテンシを生めるため、複数のFiberを処理する必要があるとき。
38:MACオタ＞団子 さん
08/10/05 16:59:15 IsV0akqP
>>36
GPUのレジスタ数と比べてみれば如何すか？例えば、
URLﾘﾝｸ(pc.watch.impress.co.jp)
----------------------
G80では、Streaming Multiprocessor(SM)当たりのレジスタ数は8,192本だった。
----------------------
固定機能を持たないLarrabeeでの必要レジスタ数わ、どうなることやら。。。
39:MACオタ＠補足
08/10/05 17:02:00 IsV0akqP
スカラコアのNvidiaのGPUだと比較がマズいすかね。。。
URLﾘﾝｸ(pc.watch.impress.co.jp)
-------------------
Xbox 360 GPUは、合計で24,576本のベクタレジスタを持つ。
-------------------
40:Socket774
08/10/05 17:02:53 ToBxbpc8
>>35
それだと16strands
1strandは、1ピクセル(4要素)に対応する
4要素はそれ以上分割しても意味がないでしょ
41:Socket774
08/10/05 17:05:03 ToBxbpc8
もちろん、単純な64要素のベクトルとして見るなら64strand
42:,,・´∀｀・,,）っ-○◎●
08/10/05 17:05:06 PiRb9Agc
>>38
ぜんぜん問題ないね。
x86はロードと論理・算術演算を1命令で行える。
キャッシュと大規模レジスタファイルどっちが有利かなど、判断しかねるよ。
既存GPUはキャッシュが小さいからLUTが使えないという
グラフィック処理に強く依存してるが故の欠点は前スレでも指摘したよね。
43:MACオタ＞40 さん
08/10/05 17:07:46 IsV0akqP
>>40
Strandsの分割法わ不明すけど、
----------------
1strandは、1ピクセル(4要素)に対応する
----------------
4要素をSIMDで計算するやりかたと、1要素づつ計算するという分割が考えられるす。
後者の方がプログラムとしてわ、自由度が大きかったりするすかね。。。
44:Socket774
08/10/05 17:08:21 KNap0rF0
あの～、strandは1要素(スカラ値)に対する処理の流れ何で、1 pixel or vertexに対応する単位ではないの。
512bitのSIMDレジスタは、16 strandsに対応するってことまでは殆どわかってる話なんだが。
各スレッド16本だったら256 strandsだけど、お前らもう混乱してるだろ。
45:,,・´∀｀・,,）っ-○◎●
08/10/05 17:10:03 PiRb9Agc
＞ Xbox 360 GPUは、合計で24,576本のベクタレジスタを持つ。
コア全体で384KBか。
その代わりキャッシュは小さい。
LarrabeeのL2キャッシュは16コアで4MBじゃなかったかな？
L1は全コア合計1MBくらい？
46:Socket774
08/10/05 17:10:05 ToBxbpc8
>>43
Data-Parallelism on Larrabee
・Key ideas of data parallel programming
- Define an array (grid) of parallel program invocations
- Define groups within the grid that can share on-chip memory
・Mapping program invocations on Larrabee
- Strand: a program invocation that runs in one SIMD lane
Strandは論理的なプログラムの単位なので、
典型的なシェーダプログラムなら、サブピクセルに分割できません
47:Socket774
08/10/05 17:12:15 KNap0rF0
one SIMD lane == 32bit scalar
の意味。
vertex (3～4要素), vector register(16要素)
ではありません。
48:Socket774
08/10/05 17:14:39 ToBxbpc8
>>47
パックドピクセルという考え方じゃないよね
1ピクセルは4つのスカラ値であって、4要素のベクトルじゃない
49:MACオタ＞団子 さん
08/10/05 17:15:37 IsV0akqP
>>42
-------------------
キャッシュと大規模レジスタファイルどっちが有利か
-------------------
団子さんの想定するインターリーブ方式ファイバだと大規模レジスタの方が「有利」かと。
50:Socket774
08/10/05 17:22:45 ToBxbpc8
>>8
> この(最大)4xFiberというのは同時に実行されるfiberの数を言いたかった。
> typically 2-10というのは一つのシェーダがその数のfiberに分割されるという意味では？
> 64xStrandsの説明がつくのはこの解釈だけに思える。
> そうでないならここの説明はどうする？＞MACオタ他、否定する人たち
小町算乙
51:,,・´∀｀・,,）っ-○◎●
08/10/05 17:26:17 PiRb9Agc
>>49
昔みたいにレジスタが高速なメモリだった時代ならね。
レジスタにもバッファが必要になったり、もうわけわからんよ。
52:Socket774
08/10/05 17:26:18 ToBxbpc8
>>24
> Threadに対する完全な従属関係ではない。
違う
> 64 Strandなら同じコアで動く4スレッドで分割処理される。
違う
たのむから数字にだけこだわって資料を読まないのは止めてくれ
53:Socket774
08/10/05 17:27:13 KNap0rF0
むしろ1 Fiber == 1 Vertex or Pixelの方が計算あうな。
使わないところは適当マスクしながら切り替えるとして。
まあ、妄想の域をでていかなから続報待ちだが。
54:,,・´∀｀・,,）っ-○◎●
08/10/05 17:27:19 PiRb9Agc
お前の「違う」には根拠が無い
55:MACオタ
08/10/05 17:31:01 IsV0akqP
実際のところ、Intelわ"Wide variety of scheduling algorithms"を謳っているすから、ハードウェア
スレッドの中で、どのように複数のファイバを埋め込むかわ、命令単位でも関数単位でも自由に
可能す。
命令単位の混在も、単なるインターリーブでなくファイバごとの所要リソースや優先度に応じて
ダイナミックに切り替えることを想定しているんじゃないすかね。ファイバAで3命令->ファイバB
1命令->ファイバC 2命令。。。とか。
ただ良く判らないのわ、レジスタ数少な目のx86でこのような点を売りにしていることだけす。
団子さんの書いているように、メモリを引数に取れる点と2引数のISAわ所要レジスタの削減
に有用すけど。。。
56:,,・´∀｀・,,）っ-○◎●
08/10/05 17:33:16 PiRb9Agc
JITを通したあとはダイナミックでもなんでもないんだが。
自己書き換えのペナルティはIntelアーキテクチャリファレンスマニュアルあたりでも参考に。
57:Socket774
08/10/05 17:34:37 ToBxbpc8
>>53
どういう計算したのかしらんが、基本的には1 strand == 1 Vertex or Pixelでいい
- Strand: a program invocation that runs in one SIMD lane
^^^^^^^^^^^^^^^^^^^^^^
- Fiber: a SW-managed context that runs 16-64 strands
1 Fiberが1 Vertexだとすると、Strandが意味を持たなくなる
>>54
ギャラリーに注意を促しておかないとな
58:Socket774
08/10/05 17:35:06 KNap0rF0
>>53は間違い。
>ただ良く判らないのわ、レジスタ数少な目のx86でこのような点を売りにしていることだけす。
ファイバもソフトで管理されるという定義がされているだけで、
レジスタやらIPやらは切り替えることになってるんだが。
レジスタが少ない方が有利なのは代わりない。
ファイバをいかにうまく扱えるかはIntelの用意するソフト環境次第。
59:MACオタ＠補足
08/10/05 17:35:18 IsV0akqP
もう一つ疑問点わ、近年のx86の進歩が計算結果のフォワーディングによってレジスタの不足を
補っている点す。演算結果の代入先をメモリにしておけば、直後の命令わレジスタの使用無しに
高速に結果を取得できるす。
ところがファイバ等で直後の命令が別のコンテキストに属すとなると、上記の効用わ失われるす。
Pentiumのような旧世代コアを採用した理由もこの辺にあるすか？
60:,,・´∀｀・,,）っ-○◎●
08/10/05 17:36:28 PiRb9Agc
>>55いつの情報だ？
Larrabeeの新命令がAVXと同じくVEXプリフィクスを使った3～4レジスタオペランドフォーマットであることは
散々言ってるわけだが
つーか、べつに引数が多いとレジスタ所要量が多くなるわけではない。
srcとdestに同じ値を指定できないわけじゃないだろ？
61:Socket774
08/10/05 17:37:52 ToBxbpc8
> レジスタが少ない方が有利なのは代わりない。
liveなレジスタだけ保存/復帰すればいいので、レジスタの数は関係ないよ
62:MACオタ＞58 さん
08/10/05 17:38:03 IsV0akqP
>>58
アーキテクチャレジスタが多いなら、スイッチの頻度を減らせる or 同時進行のファイバ数を
増やせる筈す。
63:,,・´∀｀・,,）っ-○◎●
08/10/05 17:39:12 PiRb9Agc
>>59
モダンなx86アーキテクチャでの浮動小数演算みたいな高レイテンシの命令は
インターリーブを前提としたタグインデックス方式ですけど。
無知もたいがいに。
64:Socket774
08/10/05 17:39:25 KNap0rF0
計算結果のフォワーディングは汎用プロセッサ向けの実装だと思ってる。
GPUみたいなレンダリングパイプラインいちどにワーッとやって終わり。
結果はすぐにor未来永劫使わないのを前提に進化してきたジャンルなわけで。
65:MACオタ＞団子 さん
08/10/05 17:40:57 IsV0akqP
>>60
---------------------
AVXと同じくVEXプリフィクスを使った3～4レジスタオペランドフォーマット
---------------------
それ一般の算術命令も全て3-4引数にするすか？アキュミュレータ命令わ全て廃止とわ
聞いていなかったすけど。。。
66:,,・´∀｀・,,）っ-○◎●
08/10/05 17:42:19 PiRb9Agc
>>65
x86古来のスカラ命令はそのままだよ。
なんでワイドベクトルを処理するのに非SIMD命令を使う必要がある？
67:,,・´∀｀・,,）っ-○◎●
08/10/05 17:43:43 PiRb9Agc
AVXで3～4オペランド化したのはSSEだけっての忘れたか？
68:Socket774
08/10/05 17:50:28 ToBxbpc8
そもそも、1thread上で2-10fibersが動くということは、少々のことでは埋められないレイテンシーがあるわけで
ファイバースイッチのオーバーヘッドなんて気にしても仕方がないんじゃねーの
69:MACオタ＞団子 さん
08/10/05 17:50:40 IsV0akqP
>>67
アキュミュレータわ「演算機能付メモリ」という概念すから、SIMDでも一緒かと。
AVXに関してわ調べてみたすけど2引数のADDPDと3引数のVADDPDというような形で
並立するんじゃないすか？
70:Socket774
08/10/05 17:51:41 WHIgITGQ
どうも64xStrandが釈然としないなー
そもそもStrandという概念はどういう意図で作られたものなのだろう？
16way中の1wayを単位にする意図がわからん。
71:Socket774
08/10/05 17:52:07 KNap0rF0
>>62
じゃあ単純にレジスタ数が多少少なかろうが、
ファイバがあったの方がよかったってだけだろう。
72:,,・´∀｀・,,）っ-○◎●
08/10/05 17:53:12 PiRb9Agc
＞ファイバースイッチ
RIPレジスタが直列に並んだ命令列の次の命令を指すのを
「スイッチ」なんて言うのか？ｗｗｗｗ
あたまわりーｗｗｗ
73:MACオタ＞70 さん
08/10/05 17:54:27 IsV0akqP
>>70
------------------
16way中の1wayを単位にする意図がわからん。
------------------
ベクトルを処理の単位にすると、SIMDの幅とぴったり合わない場合に無駄が生じるからす。
74:Socket774
08/10/05 17:55:29 ToBxbpc8
>>70
よく読みましょう
Data-Parallelism on Larrabee
・Key ideas of data parallel programming
- Define an array (grid) of parallel program invocations
- Define groups within the grid that can share on-chip memory
・Mapping program invocations on Larrabee
- Strand: a program invocation that runs in one SIMD lane
StrandはData parallel programの論理的な最小単位ということですね
コネクションマシンの仮想プロセッサ(のプログラム)みたいなもん
75:,,・´∀｀・,,）っ-○◎●
08/10/05 17:56:39 PiRb9Agc
>>69
ADDPDは「レガシーSSE」
AVXなのはVADDPDな
資産はそのまま使えるけど新フォーマットに徐々に移行してくださいね、がIntelのお達し。
新たに書くコードにおいてレジスタを破壊してもいい場合はaddpd xmm0, xmm1を使うじゃなくて
vaddpd xmm0, xmm0, xmm1を使えってこと。
76:Socket774
08/10/05 17:58:40 KNap0rF0
>>70
Strand
Strand
Strand
Strand
Strand
Strand
Strand
Strand
Strand
Strand
Strand
Strand
Strand
Strand
16-wide vector unit
Strandという概念は今ある資料だけでは正直理解できん。
1スカラ要素を追跡して一体なんの意味があるのかねぇ。
3Dグラフィックスプログラミングをやっているやつなら
Intelの資料は今のところ完全じゃないとおもって続報待ちするのが吉。
77:,,・´∀｀・,,）っ-○◎●
08/10/05 18:00:36 PiRb9Agc
JITのやってることに幻想を抱いてる奴はGoogleのJavaScriptエンジンのソースを嫁。
Javaでもいいけどな。
78:Socket774
08/10/05 18:01:36 YrFE5okz
>>75
後方互換を気にしない場合は、じゃないの
79:Socket774
08/10/05 18:01:41 WHIgITGQ
>>73
いやそれはわかるよ。
でもLarrabeeであってもHLSLとか使う限りシェーダプログラマは4要素ベクターを基本に処理を書くよね。
できっとLarrabeeのシェーダコンパイラがうまく16way使うように並び替えてくれるんだろう。
つまりそれってプログラマからは見えないところだよね。
64xStrandという何か意味的に同質のものが64並列化されてるように思える。
そのあたりに不自然を感じるのよ。
80:Socket774
08/10/05 18:03:03 KNap0rF0
ぶっちゃけ、1 Strand == 1 pixel or vertex
16 wayの図は間違いだと思いたい。
81:Socket774
08/10/05 18:03:52 WHIgITGQ
>>76
> Strandという概念は今ある資料だけでは正直理解できん。
> 1スカラ要素を追跡して一体なんの意味があるのかねぇ。
そう、おれもそう思う。
82:Socket774
08/10/05 18:04:34 KNap0rF0
1 strand == 1 scalar ～ 1 pixel or vertex
で変動だったら理解できるんだが、例によって計算が合わない気が。
83:,,・´∀｀・,,）っ-○◎●
08/10/05 18:05:58 PiRb9Agc
>>78
必要なら、両方を書いてCPUID見てブランチすればいいじゃない。
後方互換のために使うななんて言ってたらいつまでも移行は進まない。
84:Socket774
08/10/05 18:07:58 KNap0rF0
多数あるstrandの中から1 strandを切り出して他と組み合わせたりする。
まあ要するにpermuteするってこと?? そのために用意した概念っていうならまあ理解できるな。
85:Socket774
08/10/05 18:08:43 YrFE5okz
>>83
それはつまりMACオタの言うところの並立じゃん
86:,,・´∀｀・,,）っ-○◎●
08/10/05 18:10:20 PiRb9Agc
>>82
Scatter/Gather命令ってのがあって、任意のアドレスから16個の要素を引っ張ってきたり
逆に分解してストアする命令があってだな。
座標がx, y, zならそれぞれxだけ、yだけ、zだけでベクトルを再構成する。
87:Socket774
08/10/05 18:10:58 ToBxbpc8
>>79
> 64xStrandという何か意味的に同質のものが64並列化されてるように思える。
複雑なシェーダプログラムは16way=16strandsに、
簡単でレジスタもちょっとしか使わないものは16wayを4つで64strands、で納得いかない？
>>81
>>82
どこにそんなに引掛ってるのかわからんのだが、
ふつうプログラマって、1ピクセルについてどうこう、とアルゴリズムを考えるんじゃないの？
Strandに対応するプログラムはコンパイル後にはないと思う。
言語によってはソースではstrandのプログラムを書くものがあるかもしれない。
(C*やData-parallel Cみたいな感じ)
88:MACオタ＞70 さん
08/10/05 18:12:00 IsV0akqP
>>79
Larrabeeに関してわ、ソフト次第でどうとでも書ける訳すから、SiggraphのIntelのプレゼンわ
一例に過ぎないと思っておけば良いす。
------------------
シェーダプログラマは4要素ベクターを基本に処理を書くよね。
------------------
スカラプロセッサでもベクトル処理わ可能す。16-strandsの例わ512-bit SIMDを16個のスカラ
プロセッサとして使用する例と読めば良さそうす。
ベクトル内の要素を取捨選択するための機能わ、ハードウェア的に用意されているす。
89:,,・´∀｀・,,）っ-○◎●
08/10/05 18:14:27 PiRb9Agc
>>85
いいや。並立の考え方がそもそも違う。
彼の場合は、「オペランド指定できるレジスタに制限があるほうがレジスタが節約できる」
と思ってて、同じコードシーケンスで併用するものと解釈してるっぽいので。
別に3～4オペランドだからってsrcとdestに同じ値を指定して破壊したらいけないわけではない。
90:Socket774
08/10/05 18:15:19 KNap0rF0
いやいや、ID:WHIgITGQは、3Dグラフィックスのプログラミングにおいて、
1要素だけを操作したり入れ替えたりという行為は殆ど意味がないし実際やらないから
strandの意味するところに疑問をいだいてるんだと。
団子のいうようにScatter/Gatherでメモリ配置を大規模に入れ替えるというレアケースの
ための概念ならまあ理解できる。
91:MACオタ＞90 さん
08/10/05 18:22:17 IsV0akqP
>>90
-----------------
3Dグラフィックスのプログラミングにおいて、1要素だけを操作したり入れ替えたりという
行為は殆ど意味がないし実際やらないから
-----------------
Strandわプログラムの単位で、データの単位じゃ無いす。単一のSIMD演算で実行しないという
だけで、1-wayのStrandで複数要素を扱うプログラムわ可能す。
92:Socket774
08/10/05 18:22:52 ToBxbpc8
けっきょく、Strandなるものを導入しているのは
「Data-parallel programにおいては」
・ハードウェアのSIMD幅などはあまり意識しないでくださいよ
・ベクトルレジスタの要素は同じ種類にしてくださいよ、パックドピクセルみたいなのはやめてくださいね
と主張したいということでしょう
データパラレル用APIやコンパイラが存在して、そうなっているのかもしれないけど
93:,,・´∀｀・,,）っ-○◎●
08/10/05 18:22:56 PiRb9Agc
別にレアでもなんでもないぞ。たとえばグレースケール変換なんかじゃしょっちゅうやること。
94:Socket774
08/10/05 18:24:46 ToBxbpc8
MACオタが正しく理解している(T_T)
StrandというのはData-parallelism用語で、20年以上前からあるので、それをそのまま使ったんでしょう
95:Socket774
08/10/05 18:26:48 WHIgITGQ
>>88
64Strandってのが、例えば本当に64Pixel/Vertexのことで、
4要素ベクトルも全部スカラーに分解して、
1Fiber内で64個分並列化する可能性のことを言ってる？
それなら筋は通るけど、ありえないよなぁと思う。
>>90
そうなのよ。
わざわざStrandっていう概念を出すことの必要性に疑問を感じてる。
名前的にもThread(糸)、Fiber(繊維)、Strand(髪)と似てるんだから
概念的にある実行シーケンスの単位の一つのように思える。
でもその実体がSIMDの1wayということが釈然としない。
96:Socket774
08/10/05 18:33:00 KNap0rF0
>Strandわプログラムの単位で、データの単位じゃ無いす。単一のSIMD演算で実行しないという
>だけで、1-wayのStrandで複数要素を扱うプログラムわ可能す。
この2行は最初からわかっているし納得できるんだが。
そもそもSIMD演算で性能を発揮することが前提のLarrabeeでStrandで複数要素を扱うメリットが理解できん。
Scatter/Gather命令で計算しやすいようにデータのレイアウトを高速に変更できるってのが特徴ってなら理解できる。
>>93 3Dゲーでリアルタイムにデータ要素を入れ替えるのは全体の計算量からいったらごくわずかだろ。
単にruntimeとかで扱い安い概念としてのStrandだと思う。
97:,,・´∀｀・,,）っ-○◎●
08/10/05 18:33:35 PiRb9Agc
>>95
高級言語とアセンブラの関係、あるいなP6以降のx86命令セットアーキと内部アーキの違い。
ソフトGPUは極度に抽象化されてるんだよ。
98:,,・´∀｀・,,）っ-○◎●
08/10/05 18:35:37 PiRb9Agc
>>95
加えて、釈然としない人のために、ネイティブのSIMDをダイレクトに使うための手段を用意してるんだから
気に入らないならそっちを使えばいい。俺はそのつもりだし。
99:MACオタ＞96 さん
08/10/05 18:37:07 IsV0akqP
>>96
----------------
そもそもSIMD演算で性能を発揮することが前提のLarrabeeでStrandで複数要素を扱う
メリットが理解できん。
----------------
GPU的用途でわ、「同じ演算」を行う対象が山ほどあるすから、横に並べてSIMD演算でも、
1-wayのStrandを大量に処理しても同じ効率になるのだと思われるす。
100:Socket774
08/10/05 18:39:10 KNap0rF0
う～わかってないなあ。
2D画像処理とか科学技術計算とかなら理解できるけど、
3Dゲームのグラフィックスの計算で、4要素とかのベクトルデータをバラに考えるケースなんて
殆ど存在しないって。
まあ、知らないのだからいいや。次に興味のある話題までROMってるわ。
101:,,・´∀｀・,,）っ-○◎●
08/10/05 18:41:12 PiRb9Agc
というか、言ってしまえばLarrabee＝GPUエミュレータ
102:Socket774
08/10/05 18:43:29 KNap0rF0
>3Dゲームのグラフィックスの計算で、4要素とかのベクトルデータをバラに考えるケースなんて
>殆ど存在しないって。
そもそもGPUが3Dゲーに異常進化できたのもこの前提があるからなんだけど。
Larrabeeはそこからちょっと距離を置いているように見えるが、
やはりGPUの代替えとして使う限りにおいて、4要素のpixel/vertex, 16要素のtransform行列
あたりの処理の考えはこれまでのGPUからあまり変わってないように見える。
103:Socket774
08/10/05 18:44:41 WHIgITGQ
>>97>>98
つまり高級言語ではプログラマはStrandという単位でプログラムを記述する、
それがコンパイラによって最終的にSIMDの1wayに還元されるということ？
その情報のソースはある？
104:,,・´∀｀・,,）っ-○◎●
08/10/05 18:46:16 PiRb9Agc
>>100
その4要素がx, y, z, wとして、バラさないといけないケースならしょっちゅうある。
IntelがSSE4でdppsをサポートするまで内積とるのすら
シャッフルが必要だったし。
クォータニオンの回転も並列実行するにはばらさないと無理
105:Socket774
08/10/05 18:48:37 KNap0rF0
>>104
それはCPU側の話だろ。
今は元々GPU側の処理メインの話してるんだが。
Larrabeeがでても今までCPU側がやってたことは当分CPUでやることになるって。
106:,,・´∀｀・,,）っ-○◎●
08/10/05 18:52:23 PiRb9Agc
>>105
ならそれがGPU側でできてしまうLarrabeeはゲームにも強いことになるね。
107:Socket774
08/10/05 18:56:32 KNap0rF0
そりゃ一応今までのGPUよりも融通が利くのがLarrabeeなのだから
使いようによっては面白いものが出来るんだろう。でも性能は高くないと思う。
3DゲーのベンチではGPUばかりが注目されているけど、
ベンチではない3DゲーでのCPUの計算量はバカにはならないことは
DirectXでなんかつくったことのあるやつならわかると思う。
108:MACオタ＞107 さん
08/10/05 19:02:58 IsV0akqP
>>107
-----------------
でも性能は高くないと思う。
-----------------
これに関してわ、多少なりとも明らかになるのが一年以上先の話す。
109:,,・´∀｀・,,）っ-○◎●
08/10/05 19:03:56 PiRb9Agc
Havokみたいな物理演算やるにも、GPUでできないことをCPUにやらすためにいちいちデータ交換するより
GPUだけでやってしまったほうが有利でしょ。サーフェイス作って転送なんて馬鹿らしいことやる必要ない。
110:MACオタ＞団子 さん
08/10/05 19:10:16 IsV0akqP
>>109
豪華な仕様で高性能という単純な時代わ終わっているす。
111:,,・´∀｀・,,）っ-○◎●
08/10/05 19:20:12 PiRb9Agc
nVIDIAもIntelもやろうとしてることは同じ。座標計算などCPUでやってた処理をほぼすべて
GPUでやれるようにする。各社がそれぞれ２大物理演算エンジンを買い取ったのはそのため。
AMDはGPU-CPU間のデータ転送レイテンシを短縮するためにFusion構想を打ち出した。
GPU-CPU間のデータ転送が遅いことがネックってのはどこの会社も認識してるわけだ。
112:Socket774
08/10/05 19:31:07 AU8yjwvo
大量のデータ並列化が可能な場合は16個のvertex/pixelで16waySIMDを各要素ごとにそれぞれの要素を入れて、
命令の並びがscalarに見えるように処理するのが一番ALU的に無駄が少ないと思うんだけど。
といってもその辺は自由だからアイデアがあったら各自実装すればいいだけだね。
個人的にはフラグメントシェーダーからフレームバッファとZの参照が可能、A-Buffer実装可能、リアルタイムレイトレに一番近づいてる、
ってだけでも興味がわくけどな。intelならメモリ帯域とキャッシュ周りの性能が足引っ張ることもなさそうな予感がしてる。
唯一ボトルネックになりえるのがテクスチャユニットで、話で聞いた限りでも間違いなく足を引っ張ると思う。
LarrabeeってMCMでうまいこと繋げられるようになってるのかね？なってるならハイエンドも狙えるんじゃないかな。
113:Socket774
08/10/05 19:34:56 hpAFqnz6
>>100
> 3Dゲームのグラフィックスの計算で、4要素とかのベクトルデータをバラに考えるケースなんて
あるって。しかもNVIDIAもATiもそれを考えて作ってるでしょ。
NVIDIAはSIMDだろうがなんだろうが全部ばらして独立したスカラプロセッサで処理してるんでしょ？
ATiに関してはR600のISAのドキュメントを読んでごらんよ。
URLﾘﾝｸ(developer.amd.com)
R6xx Family Instruction Set Architecture
Figure 4-3. ALU Data Flow
114:Socket774
08/10/05 19:36:23 ToBxbpc8
>>100
> 3Dゲームのグラフィックスの計算で、4要素とかのベクトルデータをバラに考えるケースなんて
ぼくちゃんあのね、あれは Data-Parallelism on Larrabee というセクションの記述なの
ちゃんと読もうね
データパラレル的でなくグラフィックスをやりたいのなら、団子と一緒に頑張ってくれ
115:Socket774
08/10/05 19:39:19 KNap0rF0
Larrabeeでハイエンドの性能はねらえないでしょ。
性能って速度のことをいってるわけだけど。
LarrabeeってLarrabeeにしか容易にできなさそうなことをやればGPUよりも速くて、
従来型のゲームグラフィックスだとローエンドのGPUにも劣るとかそんな感じだと思うけど。
単純に今あるようなベンチでミドル～ハイエンドのスコアを期待しているなら、
多分Larrabeeがでるときにアンチスレッドでバカ騒ぎする厨房と化すのは目に見えているな。
そもそもLarrabeeって単体よりもCPUにGPUのやっていた仕事を取り込む方向なわけで。
116:,,・´∀｀・,,）っ-○◎●
08/10/05 19:40:52 PiRb9Agc
実際DirectX使ってれば内積とか座標回転なんてしょっちゅう使うぞ。
Intelはどっちに転んでもいいようにCPU側のSIMD命令の大幅強化をはじめました。
117:Socket774
08/10/05 19:42:11 KNap0rF0
ID:AU8yjwvo以外はあまり3Dゲーム処理には詳しくないみたいだね。
そもそもstrandという概念をなぜfiberやthreadなどの概念と並べて説明する価値があったのかという話で、
一応>>113とか>>114とかの言いたいことは理解できるけど、軸がぶれすぎ。
118:Socket774
08/10/05 19:42:18 hpAFqnz6
団子も嫁って。
内積は一命令で済むぞ。
119:Socket774
08/10/05 19:44:09 Pzd6tsBX
GPU自体がDXと共に途上過程にあるため
既存の概念でパフォーマンス云々言っても仕方ない気もするが
なんせ登場まで最低でも一年以上もあるのだし
GPUの構造も現在よりもDX11向けに変更されて
ある程度GPGPU向けに最適化される可能性もあるわけだし
いずれにしろ、楽しみではあるね
現存するGPUでは、たとえばDX10にいち早く対応したnvidiaよりも
さらにDX10に最適化した仕様で、GSの高パフォーマンスを誇ったATIだが
そのGSのパフォーマンスを、S3（のローエンド）がさらに超えてしまう場面があるし
（物量がものを言うものは除く）
URLﾘﾝｸ(jp.youtube.com)
ここの動画(DXSDKサンプル)だと、radeon HD4870が88?fps位でHD2600proが23fps
440GTXが50fpsとなっているようだ（なんで440だけ音楽違うんだよ）
うちの3870と4670じゃ45-48fps位だから、どんな構造になってんのかねChromeは
理論パフォーマンスでは劣っても、構造がそういった世代向けに最適化されている場合
他社のハイエンドGPUすら凌いでしまう場合は、ヒョットシタラあるかもね
（ただし、それより古い世代のパフォーマンスは知りませんよ）
120:,,・´∀｀・,,）っ-○◎●
08/10/05 19:45:54 PiRb9Agc
>>118
知ってるよ。内積命令なんて初歩の初歩だもんな。
クォータニオンは？
Intelもなかなか対応してくれないんだよね。
121:Socket774
08/10/05 19:48:24 KNap0rF0
ちなみに計算幾何学の基礎がないやつが3Dゲームを作ると、
いちいち個々の要素を1次元配列にコピーして取り出してみたりとか
無駄なことをやってくれる。
同人ゲーまでは許されるけど、さすがに洋ゲーの主流ではこんなコードは書いてないと思う。
122:,,・´∀｀・,,）っ-○◎●
08/10/05 19:50:50 PiRb9Agc
クォータニオン扱ってる大学少ないのが嘆かわしい。
D3DXでサポートされてから専門学校ではチョコチョコ始まったのかな？
回転マトリクスなんかよりよっぽどスマートなんだがなぁ
123:Socket774
08/10/05 19:52:47 ToBxbpc8
>>117
君はゲーム以外のことを知らないし、視野も狭すぎる
(ゲームのことも怪しいが)
しばらくROMれば？
124:Socket774
08/10/05 19:57:05 KNap0rF0
いや、視野がせまいのはフェンス君の方だと思うよ。
なんでもかんでもアーキテクチャの歴史と結びつけないで欲しい。
strandは20年前からある用語だとか、
Data-Parallelism on Larrabeeってところにかいてある。
それは理解できるんだが、LarrabeeをGPUとして使用したときに
strandという単位になんの意味があるの?っていうところが発端なんだけど。
で、Larrabeeは従来型のGPUより柔軟性があるから云々という話をしてる。
125:Socket774
08/10/05 20:00:19 ToBxbpc8
しかし、ほとんど正解なのに、なんで理解できんのかな
よりにもよってMACオタは正しく理解しているし…
文面だけ読めば理解できると思うんだが、余計な思い込みが邪魔してるんかね
126:,,・´∀｀・,,）っ-○◎●
08/10/05 20:01:54 PiRb9Agc
>>115
> そもそもLarrabeeって単体よりもCPUにGPUのやっていた仕事を取り込む方向なわけで。
Larrabeeに取り込むのはCPUのSIMD命令に取り込むのと同義だぜ。
Intelの最終構想はあくまでこれだもんね。
URLﾘﾝｸ(pc.watch.impress.co.jp)
このへんではLarrabeeはハッキリと「IA++」という呼び方をしている。
URLﾘﾝｸ(www.custompc.co.uk)
「IA++」は全x86のヘテロジニアスマルチコア構想を打ち出したときにゲルたんが言ったスモールコアの呼称と同じ。
127:Socket774
08/10/05 20:06:53 ToBxbpc8
>>124
> それは理解できるんだが、LarrabeeをGPUとして使用したときに
> strandという単位になんの意味があるの?っていうところが発端なんだけど。
実体としてFiberにまとめられてしまったイメージしか湧かないということだろうけど
プログラミングモデルに意味を見出せないのなら、それまでだね
いくら説明しても無駄だし、君も永遠に理解できない
128:,,・´∀｀・,,）っ-○◎●
08/10/05 20:09:15 PiRb9Agc
逆にGPUとして使ったとき以外にStrandに意味はない。
C/C++で使う場合はただの512bitのSIMDユニットの載ってるマルチコアCPUだ。
129:Socket774
08/10/05 20:29:21 KNap0rF0
>>127
全然理解できん。俺がなんか極端な勘違いしているとかなら別だが、
Larrabeeも結局スタートラインは今のGPUが処理しているゲームグラフィックスと
同じ内容を扱うことからはじまるんだが。
Larrabeeの提唱する新しいプログラミングモデルが効果を発揮するのは、
従来型のGPU処理から離れていく未来の話でしょ。
その上でstrandはこう使えるというのなら意味はあるけど。
何が理解できていないのでしょうか?
130:MACオタ＞129 さん
08/10/05 20:44:36 IsV0akqP
>>129
------------------
何が理解できていないのでしょうか?
------------------
理解できていないとわ思わないすけど、有体に言えばStrandに関してわ気にする必要が無いす。
グラフィックプログラマわ、個々のピクセルなりバーテックスなり、ポリゴンなりに適用する
プログラムを書けば良いす。
それを誰かが対象物全てに適用するようにファイバなりStrandなりに展開してくれる訳すけど、
その世界わ数学的な処理とわ別に汚い世界す。
131:Socket774
08/10/05 20:54:29 KNap0rF0
なんとなくわかってきた。
俺はどっちかっていうと、Larrabeeの命令セットはSSEが長くなっただけみたいな仕様で
最終的な処理は従来のSIMDをグラフィックスの計算に適用するときの扱いと大して変わらないと思ってるんだけど。
そこまでばらばらにStrandには展開されないと思ってる。
Intelの資料にはFiberがGPUのShaderに相当すると書いてあるから、柔軟にスケジュールされるのはFiberの方だと思うが。
132:MACオタ＠補足
08/10/05 20:55:52 IsV0akqP
ちなみに、コレわ当人が理解していない場合の典型的反応す。
>>127
---------------------
いくら説明しても無駄だし、君も永遠に理解できない
---------------------
通常の返答わ、「済みません。判ってるつもりだったんだけど、説明できるほど詳しくなかった。」じゃ
ないすかね(笑)
133:Socket774
08/10/05 20:55:52 hpAFqnz6
>>120
> 知ってるよ
知ってるんなら内積を「バラさないといけないケース」に挙げるなって。
クォータニオンの積はALU命令が7個になったよ。
0
x: MUL_e T0.x, R0.x, R1.y
y: MUL_e T0.y, R0.y, R1.x
z: MUL_e T0.z, R0.x, R1.w
w: MUL_e T0.w, R0.x, R1.z
t: MUL_e T1.x, R0.z, R1.x
1
x: MUL_e T2.x, R0.y, R1.z
y: MUL_e T1.y, R0.w, R1.y
z: MUL_e ____, R0.z, R1.w
w: MUL_e T1.w, R0.w, R1.x
t: MUL_e ____, R0.w, R1.z
2
x: ADD ____, PV3.z, -PS3
y: MUL_e ____, R0.z, R1.y
z: MUL_e ____, R0.y, R1.w
w: ADD ____, T0.x, T0.y VEC_021
t: ADD T0.x, T0.w, T1.x
3
x: ADD ____, T0.z, T1.w
y: ADD ____, PV4.x, PV4.w
z: ADD ____, T2.x, -PV4.y
w: ADD ____, T1.y, -PV4.z
t: MUL_e T0.z, R0.x, R1.x
4
x: ADD T0.x, PV5.z, PV5.x
y: ADD ____, PV5.w, T0.x
t: MOV R2.y, PV5.y
5
x: DOT4_e ____, R0.y, R1.y
y: DOT4_e ____, R0.z, R1.z
z: DOT4_e ____, R0.w, R1.w
w: DOT4_e ____, (0x80000000, 0.0f).x, 0.0f
t: MOV R2.z, PV6.y
6
x: ADD R2.x, T0.z, -PV7.x
w: MOV R2.w, T0.x
134:Socket774
08/10/05 20:58:31 hpAFqnz6
ミス。PV?とPS?は全部-2してくれ。ずれちゃった。
135:Socket774
08/10/05 21:04:15 ToBxbpc8
>>132
また都合のいい所だけ引用してイチャモンつけるんだから
正しくはこう
> プログラミングモデルに意味を見出せないのなら、それまでだね
> いくら説明しても無駄だし、君も永遠に理解できない
136:Socket774
08/10/05 21:05:46 Lq1xkIVD
PXはCore 2 Duo E8500よりも優秀
Xbox 360のCPUは、Wii と同様に PowerPC をベースにしたプロセッサだが、
3コアで動作クロック3.2GHz を内蔵する。同 CPU は、並列処理においてIntelのコンシューマー向け CPU で最速の
Core 2 Duo E8500（2コア／3.16GHz）を超える性能を持つ
137:MACオタ＞135 さん
08/10/05 21:18:39 IsV0akqP
>>135
捨て台詞にまで文句を付けられると出てきちゃうすね(笑)
Larrabeeのプログラミングモデルの話題に参加している段階で、
----------------------
プログラミングモデルに意味を見出せない
----------------------
ってのが当てはまらないのわ自明す。
138:Socket774
08/10/05 21:33:45 KNap0rF0
>>133
それはAMDATIのshader実装はこうなっていますと説明してるだけ。
nVIDIAやATIもGPGPU的な進化をしているので、いままでより柔軟性がある実装にかわってきていることは不思議ではない。
おれは従来の3Dゲー処理でわざわざ1要素の例を一度抽出してしまった方が都合がよい処理は殆どないといってるの。
ATIやnVIDIAもHPCとか従来の処理にとらわれない用途を模索した結果の実装だとおもうけど。
139:Socket774
08/10/05 21:53:20 AU8yjwvo
strandってインテルが現在実装している16waySIMDの性能を引き出すDXとOGLの実行レイヤーを解説するのに使ってるだけでしょ？
実際セミナーではstrandやfiberについての解説がなくて、16waySIMDについて既存のハードウェアに照らし合わせて、
4要素以下ののベクトルに対して処理するとき無駄が多すぎる！みたいな勘違い(？)をした人が結構いたみたい。
このハードウェアはintelが提供するDXレイヤーを使わずに独自の実装を許容するわけで、
その場合strandの概念に縛られる必要はまったくない。
16waySIMD、4H/Wスレッド、scatter&gatherと自由なswizzleを使えるメモリアクセスと読み書きが可能なL1/L2キャッシュを使って
好きにプログラムすればいい。当然BinningもFiberも必須ではない。
ただFiberは性能を引き出す上で避けては通れないかなと思うけど。
140:,,・´∀｀・,,）っ-○◎●
08/10/05 23:10:13 jHPZNbsT
>>139
おもしれーｗｗｗ
だが実際は制約は同じっていう。
ただ、Fiber相当のことはネイティブやる場合、ただのソフトパイプライニングでしかない。まじで。
141:Socket774
08/10/05 23:18:23 WHIgITGQ
>>139
それはわかってるって。
strandってどう理解すればいいのか教えてくれよ。
一から例のLarrabeeの資料読み直して見たけど
「Advanced Rendering on Larrabee」に
When strand reads memory...
という記述があるんだけど、いかにも実行系的な書き方だ。
単なるSIMDの1wayという存在ではなさげ。
一方
「Software is the New Hardware」で
We call each of these shaders a “fiber”
という記述もある。
つまりshaderはstrandに対応するわけではない。
ちなみfiberについて
Also called “coroutines”
とある。
この時点でMACオタが正しくて、団子の最初のFiberの主張は間違っていることがわかる。
(>>24で彼なりに訂正したとおれは理解している。)
142:Socket774
08/10/05 23:33:35 KNap0rF0
>>141
? Strand: a program invocation that runs in one SIMD lane
1つのSIMD lane(==32bit scalar値)に対する呼び出し = Strand
Strandはdataそのものではない
143:Socket774
08/10/05 23:41:50 KNap0rF0
Strandをどれだけ有効活用できるかはRuntimeばかりではなく、
Larrabeeの命令セットに深く依存してる。
IntelがStrandという概念を持ちだしている限り、
多分LarrabeeのISAや回路実装はStrandをうまく扱えるようにつくってある。
ID:AU8yjwvoのいうとおり、プログラマ次第で何でもできるといえばそうなのかもしれないが、
実際は性能が出る範疇でしか自由に出来ないから手法はある程度決まってくるかと。
本当につかうかわからないもののための万能なISAや万能な回路実装は自分の首を絞めるだけだから。
144:Socket774
08/10/05 23:44:47 WHIgITGQ
>>142
では例えばshaderで3要素ベクトルの内積があったとして
なにがstrandになるの？
145:,,・´∀｀・,,）っ-○◎●
08/10/05 23:45:58 jHPZNbsT
>>141
それはどうも。
ただ、MACヲタの間違いは俺は認めていない。
APIとして提供されるFiberは関数を順番に呼び出すだけの昔ながらのスケジューラ以外のなんでもない。
Larrabeeがやるのは、JITコンパイル時のソフトウェア・パイプライニング。
Larrabeeの場合１つのスレッドで最大の64 Strandを扱うわけではない
64 strandを扱う場合は同じコアで動く4つのスレッドでレイテンシを埋める。
均等に振れば、たとえばレイテンシ：スループット8：1のSIMD命令ならどのスレッドも8：4となり、
もうひとつくらいのファイバーとインターリーブするだけでレイテンシが埋められる。
図を描くか。
→クロックサイクル
スレッド1 ■■■■■■■■ファイバー１[0-15]
スレッド2 ■■■■■■■■ファイバー１[16-31]
スレッド3 ■■■■■■■■ファイバー1[32-47]
スレッド4 ■■■■■■■■ファイバー１[48-63]
スレッド1 ■■■■■■■■ファイバー2[0-15]
スレッド2 ■■■■■■■■ファイバー2[16-31]
スレッド3 ■■■■■■■■ファイバー2[32-47]
スレッド4 ■■■■■■■■ファイバ－2[48-63]
・・・・・・・・・・・・
これを各スレッドからみると単に2つのフローを交互に実行するだけに見える。
各スレッドが使うレジスタ数も均等に消費するので経済的。
で、FiberあたりのStrand数が少ないと、命令のレイテンシに応じて、
インターリーブするファイバーのほうを増やさないといけない。
x64アーキテクチャは各レジスタが4ビット、つまり16本しかないないのでできるだけ節約したい。
64 Strandがベストということになるね。
146:Socket774
08/10/05 23:46:19 ToBxbpc8
いや、ランタイムにはstrandという実体は存在しないんだって
スケジューリングの最小単位がfiberでしょ
147:Socket774
08/10/05 23:48:56 hpAFqnz6
>>138
よく見てほしい。4要素全部同じレジスタから読んでるのなんて頭の2つだけでしょ。
でも実際に書いたコードはBrook+でこんな感じなのさ。
kernel void hoge(float4 A<>, float4 B<>, out float4 C<>)
{
float a = A.x;
float b = B.x;
float3 U = A.yzw;
float3 V = B.yzw;
float ab = a*b;
float uv = dot(U,V);
float3 aV = a * V;
float3 bU = b * U;
float3 UxV1 = U.yzx * V.zxy;
float3 UxV2 = U.zxy * V.yzx;
float3 UxV = UxV1 - UxV2;
C.x = ab-uv;
C.yzw = aV+bU+UxV;
return;
}
これをSSEみたいな制約をつけて書いたとしたらどれだけになると思う？
クォータニオンの例だけじゃない。HDRFormats10のHDRFormats10.fxをGPUSAに喰わせて見ればわかる。
ソースレジスタはてんでばらばら。1命令中に4つのレジスタ使ってる場合もある。
148:Socket774
08/10/05 23:49:41 KNap0rF0
>>144
その回答は俺よりも他の連中が得意なんじゃないの?
俺は一貫して、Strandという概念はLarrabeeを従来のGPU用途以外にも展開できることを想定して
用意した概念であって、従来の3Dゲームグラフィックス用途に対してはあまり意味のない
概念だと思っているから。その点では君とはかなり共通した認識みたいだが。
149:,,・´∀｀・,,）っ-○◎●
08/10/05 23:50:03 jHPZNbsT
> kernel void hoge(float4 A<>, float4 B<>, out float4 C<>)
<>を見るとメタプログラミングの変態の血が騒ぐんだぜ
150:Socket774
08/10/05 23:50:11 ToBxbpc8
> スレッド1 ■■■■■■■■ファイバー１[0-15]
> スレッド2 ■■■■■■■■ファイバー１[16-31]
Fiberはこんなふうにスレッドに跨がらねーの
どうして皆こう思い込みが激しいんだ
151:Socket774
08/10/05 23:51:54 KNap0rF0
>>146
ランタイムでスケジューリングするときにstrandという概念があって
最終的なnativeコードでは実体がないとおもってたが違うのか。
152:,,・´∀｀・,,）っ-○◎●
08/10/05 23:52:13 jHPZNbsT
>>150
思い込みが激しい奴だな。スレッドに完全従属である必要はない。
153:Socket774
08/10/05 23:52:56 ToBxbpc8
>>147
この例みたいなArray of Structuresじゃなくて、Structure of ArraysなのがLarrabeeのData-parallelism
どうしてもAoSでやりたきゃTask-level Parallelismというモデルも用意されているから、そっちを使いな
154:,,・´∀｀・,,）っ-○◎●
08/10/05 23:55:26 jHPZNbsT
ファイバーはStrand数に応じてスレッドで分割実行される。
これを否定するのはAtomのlfenceはNOPじゃない！なみの思い込みでしかない。
なぜ「フェンス君」なんて言われてるかわかるだろ？
ご自分が思い込みで壮大な誤爆をしたの忘れた？
155:Socket774
08/10/05 23:58:52 ToBxbpc8
>>144
1つの3要素ベクトルの内積を計算するプログラムが1strand
156:,,・´∀｀・,,）っ-○◎●
08/10/05 23:59:24 jHPZNbsT
4スレッドでファイバーを水平分割して実行するモデルの何が合理的かって
同じ命令列を実行するだけでいいので命令キャッシュが節約できる。
レイテンシを埋めるためのレジスタも節約できる。
縦割りだとどうしてもコードサイズ・レジスタ数に無駄が生じるからな。
157:Socket774
08/10/06 00:01:15 ooDOnZoT
フェンス君の言っていることがわからん。
SoAだったら外積のときはStrandはどうなるやら?
158:Socket774
08/10/06 00:02:14 ToBxbpc8
>>154
1. AtomのlfenceはNOP ←団子の主張
2. AtomのlfenceはNOPかどうか不明 ←おれの主張
3. AtomのlfenceはNOPではない
団子は論理学の素養がないので、2.の選択肢があることを理解できない
そういうわけで何回おれが訂正しても、おれは3.だと主張している
159:Socket774
08/10/06 00:02:20 ooDOnZoT
まさか内積と外積のときでいちいちデータを並び替えるのか?
どっとも3Dゲーでは頻発だが。
無知な俺におしえてたもれ。
160:Socket774
08/10/06 00:03:14 EqalDJCL
>>153
俺は実際に「3Dゲー処理」とやらで4要素がバラけるのはよくあることだと言う例を
>>138に対して示してるんであって、Larrabeeがどうこうってのは知らないんだが。
161:,,・´∀｀・,,）っ-○◎●
08/10/06 00:05:49 Gjt1lbWv
>>158
お前は分析すらしてないだろｗｗ
妄想でものを言うな
162:Socket774
08/10/06 00:06:17 ooDOnZoT
>>160
俺(>>138)は>>138に書いているとおり、
1要素に対する操作(=Strand)をわざわざ抽出してメリットがあることは殆どない
といっているだけで、実際GPUで計算されるときにばらけるとかそういう話はしてないんだが。
そりゃGPUの実装の問題でしかない。
163:,,・´∀｀・,,）っ-○◎●
08/10/06 00:06:40 Gjt1lbWv
>>159
そうだよ。しょっちゅう並び替えるよ。
164:Socket774
08/10/06 00:08:33 ooDOnZoT
じゃあ従来の3Dゲー処理では使えないモデルだね。
並び替えで時間をくわれて話にならない。
やっぱHPC向けなんだろ。
165:Socket774
08/10/06 00:08:41 Zrg1b2Ja
Fiberの切り替えって単純に避けられないデータハザードとかテクスチャの読み込み待ちなんかで
どうしてもALUが遊ぶ場合に例のドキュメントの手順を踏んでパイプライン埋めますってだけでは？
Fiber切り替えはHWスレッドの切り替えと違ってノーペナルティでは出来ないとすると、
どうしようもないとき以外はFiberのスイッチはしないと思うんだけど。
166:,,・´∀｀・,,）っ-○◎●
08/10/06 00:12:07 Gjt1lbWv
>>165
x86コードに落とし込んだときにファイバーの「スイッチ」なんてものは存在しないの
ソフトパイプライニングして交互に実行するだけ。
ただアーキテクチャレジスタが少ないのでインターリーブは最小限にしたほうがいい。
167:Socket774
08/10/06 00:12:14 sZHTe2uz
>>165
正解
ファイバーの切り替えは静的に見積りができるレイテンシーの隠蔽に使う
コンテクストスイッチと見積ったレイテンシーの有利なほうを選べるでしょ
ただし、コンテクストスイッチのペナルティはレイテンシーに隠れるけどね
168:,,・´∀｀・,,）っ-○◎●
08/10/06 00:14:01 Gjt1lbWv
ファイバーのインターリーブも隠れるわボケ
169:Socket774
08/10/06 00:15:03 EqalDJCL
>>162
だからちゃんと例示したものは読んで下さいよ。
HDRエンコードどかデコードとかはバラけるんですけど。
ほかにもクックトランス反射はベクトル演算なんて4回ほどの
内積と1回のスカラ倍で、後は全部スカラ演算だし。
Larrabee云々の話は知らんがな。
170:Socket774
08/10/06 00:15:14 sZHTe2uz
>>166
インテルの資料にファイバーはコルーチンだって書いているのに、どうしてそう強情をはれるんだ
171:,,・´∀｀・,,）っ-○◎●
08/10/06 00:17:59 Gjt1lbWv
>>170
抽象的な概念に踊らされすぎです。
コンパイル時に1つの直列なコードに変換されます。
x86レベルでも本当にコルーチンとして展開されてると思うのか？
call/retのクロック数考えてみろよ。レイテンシの隠蔽以前の問題だから。
172:Socket774
08/10/06 00:19:33 sZHTe2uz
> call/retのクロック数考えてみろよ。レイテンシの隠蔽以前の問題だから。
call/retって何？
173:Socket774
08/10/06 00:21:09 sZHTe2uz
？Fiber switch on texture request submission
？Saves live registers
？Saves the IP to resume at
？Jumps to the next fiber’s IP
？Next fiber restores live registers
？Gets texture result, continues shading
174:Socket774
08/10/06 00:22:32 sZHTe2uz
団子よ、お前が妄想を書き散らすのは勘弁してやるが
せめてインテルの資料は尊重してくれ
175:,,・´∀｀・,,）っ-○◎●
08/10/06 00:25:09 Gjt1lbWv
知らないならいいよ。
ちなみに今のIntelコンパイラはインライン展開可能かつ並列実行可能な関数は展開して
同じ命令列の中でインターリーブして実行することもできます。
ためしにアセンブリの出力みてみましょう。
静的コンパイルだろうと実行時コンパイルだろうとやることは変わらない。
静的の方がやれることは多いけど
176:Socket774
08/10/06 00:26:04 igaDDIad
>>155
> >>144
> 1つの3要素ベクトルの内積を計算するプログラムが1strand
では積の部分を3wayで一気に計算せずに1wayだけ使って
スカラー的に1stepづつ計算するわけ？
(で16個の内積を並列に計算することで16wayを埋めると？)
177:,,・´∀｀・,,）っ-○◎●
08/10/06 00:27:45 Gjt1lbWv
>>173
あのさー、それ真の意味でタスク切替。
ファイバーを交互実行する仕組みでのインターリーブとはまったく別物。
178:Socket774
08/10/06 00:29:01 ooDOnZoT
>>169
それを1スカラ要素に着目するとどうエレガントなコードに変身するのか説明してくれよ。
お前だけ全然別の話してるぞ。
179:Socket774
08/10/06 00:31:02 EqalDJCL
>>178
そりゃ違う話してるよ。>>100への反論続けてるのなんて俺だけでしょ。
180:Socket774
08/10/06 00:32:23 ooDOnZoT
>4要素とかのベクトルデータをバラに考えるケースなんて殆ど存在しない
この部分ってのは1要素に対する1連の操作を抽出してもメリットは殆ど内って意味。
キミが書いているのは全然違う話だって。レジスタやALUなんて今の話に関係ねーよ。
181:Socket774
08/10/06 00:33:16 sZHTe2uz
>>177
？Fiber switch on texture request submission
182:Socket774
08/10/06 00:35:40 sZHTe2uz
>>176
概念的にはだいたいその通り
4要素ベクトルを処理するのが、strand
4要素ベクトルのベクトルを処理するのが、fiber
183:Socket774
08/10/06 00:36:46 ooDOnZoT
で、たとえば内積に続いて外積を計算するときは
SoAではどうするの? >ID:sZHTe2uz
184:,,・´∀｀・,,）っ-○◎●
08/10/06 00:36:59 Gjt1lbWv
>>181
> ？Fiber switch on texture request submission
テクスチャリクエスト
どこにリクエストする？
メモリだろ？
その間に別の処理をやってしまおうってだけ。
レジスタ退避復帰が伴うので普通のOSのコンテクストスイッチと同じだよ。
185:,,・´∀｀・,,）っ-○◎●
08/10/06 00:41:56 Gjt1lbWv
レジスタを二重に持つことでレジスタ退避・復帰を伴わずにやってしまうのがItanium2のCGMT
しかしLarrabeeの場合はレジスタファイルを多重に持つのは既にFGMTでやってしまってるので
あまりリソースを取れない。だから退避が必要なんだ。
1スレッドあたりのレジスタ数がそんなに多くないので退避してしまっても
たいしたペナルティにならない。逆にね。
186:Socket774
08/10/06 00:42:15 ooDOnZoT
外積のあと内積だな。
SoA的にはオペランドを縦割りだあらかじめ全部抽出しといて
一気にかけ算だけバーっとかでやるとかになるんだろうけど。
187:Socket774
08/10/06 00:47:33 EqalDJCL
>>180
> この部分ってのは1要素に対する1連の操作を抽出してもメリットは殆ど内って意味。
実装の部分ではあるんじゃない？
GeForceは抽出してるわけじゃないけど実際1要素ごとにばらばらにして演算するわけだし。
と思ってるから今までISAや実装の話と、実際のエフェクトの話をしてた。
スレの流れから逸脱してるのはわかってるし団子叩きの邪魔になってるのもわかるんだけど、
まあ許しておくれ。
188:Socket774
08/10/06 00:52:00 ooDOnZoT
今1要素ごとにばらばらにするってことが問題なんじゃなくて、
ある1要素に注目してそれに対する操作という考えで、
コードを書くor自動でスケジュールすることに意味があるのかという話。
同じところに積和を何百万、何億回とひたすら計算を繰り返すジャンルなら理解できるが、
3Dゲーみたいにころころ計算内容がリアルタイムにころころかわるジャンルには向いてないと思う。
レイトレーシングのコードはよくしらないからわからん。
189:Socket774
08/10/06 00:55:05 ooDOnZoT
>>188の書き込み内容は微妙だがまあいいや。
190:Socket774
08/10/06 00:56:14 sZHTe2uz
Strandはベクトル演算の1ALU OPの複合化したやつとでも思えばいいのかな
ベクトルと同様に、Fiberにまとめるのをコンパイラやランタイム任せにすれば、境界条件のマスクを考えなくてもいい
ただし、アーキテクチャ上からも逐次方向の局所性を利用しないと性能がでないので、純粋なベクトルモデルではなく、
Strandの導入になったと
191:Socket774
08/10/06 01:02:03 igaDDIad
おれは今日の議論でLarrabee(のD3D実装は)
shader上のベクトル演算も一旦スカラーに展開して、
それを並列に並べてベクトル演算器に流すと理解した。
つまりG80のさらにその先を行くわけか。
ステップ数は増えるが、確かに並列度は高くなって演算器を有効に
使えるのかもしれない。
しかし結果トータルでパフォーマンスはあがるのか？
分岐やテクスチャフェッチはどうなるのか？
そのあたりまだよくわからない部分はある。
レスくれた皆サンキュー、寝る。
192:Socket774
08/10/06 01:02:53 ooDOnZoT
なんだか散々だな。
結局団子の1ファイバ 4スレッドの解釈は間違いだったとことでいいんだろ。
腹切りよろしく >> 団子
そして俺は寝る。
193:,,・´∀｀・,,）っ-○◎●
08/10/06 01:12:30 Gjt1lbWv
AoS/SoA変換を重点的に攻めてきたのはAVXもLarrabee新命令も同じ
特にAVXは熱い！やばい！間違いない
前にも書いたけどxmm1, xmm2, xmm3, xmm4のベクトルからxmm5で指定した
4つの要素を取り出してxmm0に格納するのにこれだけでおｋ
(ただしこれはxmm6をテンポラリに使う）
vpermil2ps xmm1, xmm1, xmm2, xmm5, 2
vpermil2ps xmm6, xmm3, xmm4, xmm5, 3
vpor xmm0, xmm0, xmm6
これならマトリクス演算も高速に出来るってわけだ。
194:,,・´∀｀・,,）っ-○◎●
08/10/06 01:13:39 Gjt1lbWv
>>192
はい？
散々言ってるけどハードウェアスレッドとソフトウェアスレッドの意味を混同してね？
195:,,・´∀｀・,,）っ-○◎●
08/10/06 01:25:20 Gjt1lbWv
そこで説明されてる「ファイバースイッチ」そのものは普通のOSでのコンテクストスイッチと同じこと
何百クロックも何千クロックも待たされるからこその。
16ビット時代はフロッピーディスク初期化中に他の作業できなかったろ？
プリエンプションでフロッピー初期化中でも別の作業ができるようになった。
アレと同じ理屈
命令間のレイテンシを埋めるためのインターリーブはまた別個で必要
196:Socket774
08/10/06 01:27:01 +Q6OMh3e
>>193
任意の要素をゼロクリアできる分だけ
32bit要素の並び替えに関してはAltiVecのvpermより使いやすいってことかいな
197:,,・´∀｀・,,）っ-○◎●
08/10/06 01:38:19 Gjt1lbWv
>>196
そう、抽出用のパターンテーブルが1つで済む。
AltiVecは3つ目のオペレーションにvpermを使うにせよvselに使うにせよ
もう一個ビットパターンを用意しないといけない。
同じ目的の命令はAMD SSE5にもpermpsというのがあるが
こっちはAltiVecの劣化版に毛が生えたようなの。
198:,,・´∀｀・,,）っ-○◎●
08/10/06 01:46:36 Gjt1lbWv
で、フェンス君の言ってたスレッドよりファイバを使えのなぞ発言ってさ
テクスチャフィルみたいな待ち時間が多い処理は
ハードウェアスレッド切替を使うんじゃなくてファイバコンテクストそのものを退避して
別のコンテクストに切り替えろ
ってこと？
なら納得。
CPUとして使う場合でテクスチャフィルなんて使うのか甚だ疑問だが
199:MACオタ＞196-197 さん
08/10/06 01:47:02 pdu9F3SC
>>196
--------------------
任意の要素をゼロクリアできる分だけ
32bit要素の並び替えに関してはAltiVecのvpermより使いやすいってことかいな
--------------------
CELl SPEのShuffle Byte命令も任意要素を0, 0xFF, 0x80に設定できるす。
200:MACオタ＞団子 さん
08/10/06 01:56:46 pdu9F3SC
>>198
-----------------
テクスチャフィルみたいな待ち時間が多い処理は
ハードウェアスレッド切替を使うんじゃなくてファイバコンテクストそのものを退避して
別のコンテクストに切り替えろ
-----------------
レイテンシが不定な処理わ、データが来たところで自動的に再開できるSMTを利用するのが得策す。
ところで、この謎発言わ撤回したすか？fiberわSMTスレッドの上位の単位で無いし、「4つ」という
制限も無いことわ明らかにされたかと思うす。
==================
847 名前：,,・´∀`・,,）っ-○●◎ 投稿日：2008/10/05(日) 00:21:59 ID:PiRb9Agc
[略]
LarrabeeでいうところのFiberは同じ1コアで動かすべき4つまでのスレッドを纏めたものにすぎない。
==================
201:,,・´∀｀・,,）っ-○◎●
08/10/06 01:57:09 Gjt1lbWv
それ全然vpermil2psより優位な要素じゃないんですけど。
vpermil2ps/vpermil2pdでは、imm8[1:0] で指定する2ビット値によって、第3ソースで指定した
パターンのうち、最上位ビットが立ってるほうをゼロクリアするか、あるいは立ってないほう
をクリアするか選択できる。
シミュレータで動かした限りにおいてもSPEのアレよりだいぶ便利だ
202:Socket774
08/10/06 01:57:40 +Q6OMh3e
>>199
ほんとだ。確かに要素指定には5bitしか使わないから
残りの3bitを使えばフォーマットを変えずに拡張できるね。
でも4ベクトルから任意の要素を取り出して並べ替えようとすると、
やっぱり2つ制御ベクトルが要るね。2ベクトルだと1つで済むけど。
このあたりをAVXはimmidiateを使ってうまくやってる感じ。32bit以下には使えないけどw
SSE5のも見てみたが、こっちは0以外にもセットできるけど
やっぱり4ベクトルから取り出そうとすると制御ベクトルが2個要るのは同じだな
203:Socket774
08/10/06 01:59:32 +Q6OMh3e
おっとかぶったw
204:,,・´∀｀・,,）っ-○◎●
08/10/06 02:00:02 Gjt1lbWv
>>200
何が？
で、ファイバーのスイッチは普通のOSにおけるプロセスを切り替える仕組みと何が違うのかな？
プロセスには（ソフトウェア）スレッドが従属するが。
205:MACオタ＞団子 さん
08/10/06 02:02:49 pdu9F3SC
>>204
-----------------
普通のOSにおけるプロセスを切り替える仕組み
-----------------
「普通のOS」というのがWindowsやLinux, Mac OS Xのような用途のOSを意味するなら、ページテーブル
の切り替え等、はるかに複雑な処理を必要とするす。
ファイバのスイッチと比較できるのわ、関数呼び出し程度でわ？
206:,,・´∀｀・,,）っ-○◎●
08/10/06 02:05:21 Gjt1lbWv
XSAVE/XRESTORで全部退避復帰する必要があるんですけど
関数呼び出しで退避が必要なレジスタは一部です
207:MACオタ＞201-202 さん
08/10/06 02:06:08 pdu9F3SC
>>201-202
SPE ISA、VMX-128の改善点、反省点を含めた新SIMD ISAわVSXとしてPOWER7に実装される
予定す。Altivecの正統進化がどのようなものになるか、楽しみにして欲しいす。
208:MACオタ＞団子 さん
08/10/06 02:09:21 pdu9F3SC
>>206
----------------
関数呼び出しで退避が必要なレジスタは一部です
----------------
Larrabeeのファイバのスイッチも退避レジスタわ使用している分だけと書いてあるす。
================
- Saves "live" registers [""わ、MACオタ注]
================
209:MACオタ＞団子 さん
08/10/06 02:13:18 pdu9F3SC
ところで、後藤氏がLNIと将来のx86拡張についての記事を書いているすよ。
Gelsinger氏とのインタビューを交えて。
URLﾘﾝｸ(pc.watch.impress.co.jp)
210:,,・´∀｀・,,）っ-○◎●
08/10/06 02:16:32 Gjt1lbWv
まあ、使ってないレジスタは退避しないという方針に基づいても、
汎用レジスタ16本とSIMDレジスタ16本、マスクレジスタ、EFLAGSにMXCSRなど
諸々は基本的に退避しないといけないな。
FP/MMレジスタの退避はまあ使わないなら必要なさそうだな、
関数コールとは違ってABIを規定できない筈だし（するのか？）
211:,,・´∀｀・,,）っ-○◎●
08/10/06 02:21:10 Gjt1lbWv
>>209
だから言ったとおりじゃん。
Larrabeeのコアはヘテロジニアスマルチコアにおける「IA++」と同じものだって。
ちなみにゲルたんがいってることは4年前に後藤自身が解説したこととなんら変わってない。
SSEと共存できないだとか、いや、共存できるだとか、後藤が一人で混乱してただけで
Intelは一貫してたわけだ。
212:MACオタ＞団子 さん
08/10/06 02:23:54 pdu9F3SC
>>210
なんとなく見積もりが違う気がするすけど。。。
-----------------
関数コールとは違ってABIを規定できない筈だし（するのか？）
-----------------
Larrabeeわ目的が異なるスレッド(orタスク)が併走する設計になっていないす。
(例えば4つのSMTわMMUを共有するため、スレッド間のメモリ空間の独立性の自由度わ低い)
演算リソースわユーザーコードで占有され、タスクのスケジューリングも自前で行うすから、
ABIも必須でないす。こういう点でもCELL SPEと各コアの使い方わ近いかと思われるす。
213:MACオタ＞団子 さん
08/10/06 02:26:36 pdu9F3SC
>>211
記事でわAVXが妙に無視され気味な訳すけど、その辺気にならないすか？
スケジュール通りなら、2010より数年間AVXとLNIが並立するというISAの分離が発生するすけど。。。
214:MACオタ＠訂正
08/10/06 02:28:47 pdu9F3SC
>>212で少し記述間違えたす。
誤: 4つのSMTわMMUを共有するため
正: 4つのSMTわTLBを共有するため
215:,,・´∀｀・,,）っ-○◎●
08/10/06 02:37:37 Gjt1lbWv
> つまり、256-bitと512-bitのずれは、時間軸上のずれに過ぎず、
> PC&サーバー向けCPUもいつかは追いつくことになる。
さて、問題あるかね？
LarrabeeでSSE/AVXをサポートしないとも言ってない。
特にAVXについては、LNIでVEXエンコーディングを用いる以上
デコードできてしかるべきだし、やれるんじゃないの？
まあ「絶対サポートする」と強弁する気はないが。
後藤はLNIがVEXエンコーディングって事実はまだ把握してないようだが
なんとなくは気づいてるような。「命令は固定長にするのが望ましい」とかな。
216:MACオタ＞団子 さん
08/10/06 02:49:18 pdu9F3SC
>>215
----------------
256-bitと512-bitのずれは、時間軸上のずれに過ぎず、
----------------
マーケティングトークわ別にして、Intelわ論文で「512-wideはグラフィック市場のための選択」と
公言しているす。
(Siggraph Larrabee論文より)
--------------------------
We chose a 16-wide VPU as a tradeoff between increased computational density and the
difficulty of obtaining high utilization for wider VPUs. Early analysis suggested 88%
utilization for typical pixel shader workloads if 16 lanes process 16 separate pixels one
component at a time, that is, with separate instructions to process red, green, etc., for 16
pixels at a time, instead of processing multiple color channels at once.
--------------------------
217:,,・´∀｀・,,）っ-○◎●
08/10/06 03:10:51 Gjt1lbWv
3byte版のVEXのm-mmmmフィールドは5ビット（32種類）あって
SSE*の再定義とAVXの新命令のために3つ（0F, 0F38, 0F3Aのエイリアス）
使ってるが、あと29個も残っている。
こいつとVEX.Lフィールドとの組み合わせで、いくらでも命令を定義できる。
将来的にISAの均質化を目標としているのならAVXまでのSIMD命令も
Larrabee（IA++）側でサポートしないといけない。
もちろん、統合までにやる話であって、最初の世代ではすべてやる必要も無いんだが
じゃあ、最初の実装のLarrabeeで128bit/256bitのSIMDをサポートしないとして
その理由は何よ？
積和算にしろシャッフルにしろ、全部Larrabeeにインプリメントされた機能で実装できそうだ。
専用ハードがないならないでマイクロコード実装でもいいんだけどな。
SSEが64bit SIMD
Sandy Bridgeでも256bit AVXは内部的に128bit命令を2個実行するだけの実装にとどまってる。
まあ、あれはAVXを実装したCPUですら無条件でサポートされるものではないことは
マニュアルにて示唆されてるが。
SSE4.1を無効にしたWolfdaleコアがあるように、マーケティング上の理由で
ローエンドCPUでは無効にするとかそういう類のものになりそうだが
218:,,・´∀｀・,,）っ-○◎●
08/10/06 03:13:22 Gjt1lbWv
後半書き直し
最初のPentium IIIからPentium 4においてSSEが64bit SIMD×2で実装されてたように
Sandy Bridgeでも256bit AVXは内部的に128bit命令を2個実行するだけの実装にとどまってる。
LNIでもAESくらいならサポートしない理由はある。テーブルが複雑だし。
まあ、あれはAVXを実装したCPUですら無条件でサポートされるものではないことは
マニュアルにて示唆されてるが。
汎用CPUではSSE4.1を無効にしたWolfdaleコアがあるように、マーケティング上の理由で
ローエンドCPUでは無効にするとかそういう類のものになりそうだが
219:MACオタ＞団子 さん
08/10/06 03:53:53 pdu9F3SC
>>218
-------------------
Sandy Bridgeでも256bit AVXは内部的に128bit命令を2個実行するだけの実装にとどまってる。
-------------------
また根拠の無い話を(笑)
反証にわソースがあって、"Terra Terra Terra"プレゼンでわ、Gesher (Sandy Bridge)のコアあたり
のDP Flops/cycle/core=7とあるす。8の誤植かどうかわ別にして、「サイクルあたり4-wide x 2 (積和)」
じゃないと到達できない数字す。
220:,,・´∀｀・,,）っ-○◎●
08/10/06 03:58:29 Gjt1lbWv
古い記事見たら、LarrabeeにVEX使うことは後藤は既に気づいてた。
URLﾘﾝｸ(pc.watch.impress.co.jp)
> また、512bitsや1,024bitsといったベクタ長の拡張も容易になる。
> Intelが、2008年末から2009年にかけて投入する予定のメニイコアCPU「Larrabee(ララビー)」は、
> AVXの命令フォーマット拡張の上に乗っている可能性が高い。
> AVXには、今後、毎世代命令セットを大きく拡張して行く、Intelの戦略が根幹を伺うことができる。
あと、ここ注目。
> 「5バイトバージョンの2つ目のペイロードはフルではない。将来の拡張のために3ビットが残されている。
> 3bitsあれば、1,000以上の新命令を加えることができる。新しいフィーチャ、新しいレジスタ、
> 新しいベクタ長。ほとんどなんでも加えることができる」(Valentine氏)。
m-mmmmフィールドは5ビットあるのに「3ビット」とはなんぞや？
これが間違いではないとすれば、5ビット32通りの中に0F, 0F38, 0F3Aフィールドがあるのではなく、
3ビット＋2ビット（Reserved, 0F, 0F38, 0F3A）と考えてることになる。
それならそれで1000命令以上といったのはおかしいわけだが。
ちなみに後藤はここでも暗にVEX方式であるべきだと説いているようだ。
URLﾘﾝｸ(pc.watch.impress.co.jp)
> Intelは、Larrabee拡張命令のフォーマットの詳細については明らかにしてない。
> しかし、想定できる点がいくつかある。まず、命令フォーマットはデコードしやすいものでなければ
> ならない。x86命令のデコード時の複雑さの多くは、x86命令が可変長であることに起因している。
> この問題を軽減するためには、Larrabee拡張命令を、固定長にすることが望ましいと推定される。
この記事で
> MMX Pentium以降のMMX/SSE系の拡張命令は、サポートしないと推測される。
なんてトンデモなことを言った理由は、むしろVEXプリフィクスの合理性を主張したいからな気がした。
実際には、MMX/SSEが使ってきた2byte Opcode空間はMMX以前から使われてきたしLCP＋2byte Opcodeなんてのはザラ。
SSEの命令フォーマットがデコードできない理由にはならない。「遅い」ならまだわかる。
221:MACオタ
08/10/06 04:09:18 pdu9F3SC
余談すけど、今回の後藤記事の内容のヒドさに、私わ落胆したす。
かつて後藤氏わ、素朴な質問をぶつけて相手に詳しく語らせることで、自身の素養の無さにも
かかわらず良いインタビューをモノにしていたす。（ちなみに、逆のスタイルが本田雅一氏で、
話を聞くより自分の意見を売り込もうとしてるんじゃ無いかと思われるようなやり方す。)
ところが今回の記事、まるで自分の憶測の裏付けを必死でGelsinger氏に求めているとしか
思えないような代物す。これでわ記事自体、都合のいい言葉だけを引用しているような
バイアスがかかっている疑念すら出てくるす。
222:,,・´∀｀・,,）っ-○◎●
08/10/06 04:10:35 Gjt1lbWv
>>219
また妄想を
128ビットである理由は俺のサイトにも書いている通り
256bitに作用するシフト命令が無い時点でネイティブ256ビットはありえないんだよ。
7が誤植で実は8でしたという思い込みはできても
実は4でしたというほうへの思い込みはできないのはおめでたいとしか。
GesherはSandy Bridgeを特定して指すという前提がそもそもおかしい。
AVXをサポートするgmmintrin.hには、FMAのIntrinsicsも含まれている。
元のGesher New Instrunctions（GNI）はFMAまでのサポートを含んでいたことがわかっている
FMAをサポートする次の世代も含めてGesherだ
そして、7DPという数字については、128bit FMA＋ 128bit Dot-Productで7でも計算が合う。
ばかだなぁFUCKヲタは。
223:MACオタ＞団子 さん
08/10/06 04:16:33 pdu9F3SC
>>222
何度か書いているすけど、
-------------------
俺のサイトにも書いている通り
-------------------
議論の相手や聴衆が、自分と同じ情報を持っているという思い込みわ、勘弁して欲しいす。
それわそれとして、
-------------------
128bit FMA＋ 128bit Dot-Productで7でも計算が合う。
-------------------
内積のような高級命令ってシングルサイクル・スループットなんすか？
224:,,・´∀｀・,,）っ-○◎●
08/10/06 04:37:03 Gjt1lbWv
IntelコンパイラのSSE組み込み関数のヘッダファイルはCPUの開発コード名を冠してる
SSE3 pmmintrin.h (Prescott)
SSSE3 tmmintrin.h (Tejas)
SSE4.1 smmintrin.h (Swing)
SSE4.2 nmmintrin.h (Nehalem)
AES/CLMUL wmmintrin.h (Westmere)
AVX/FMA gmmintrin.h (Gesher)
Tejas/SwingはNetBurstがロードマップに存在した時代の死んだコードネームです。
Gesherも死んでSandy Bridge/IvyBridgeは後釜なんじゃないの？
Intelが開発コードを変えるのは気分じゃなくて何かしらアーキテクチャ定義に
変更があったからではないかな？
事実、GesherではFMAまでをサポートする予定でgmmintrin.hが定義されたのに
Sandy Bridge・Ivy Bridgeあるいはその次の世代という段階的なサポートになってしまってる。
> 内積のような高級命令ってシングルサイクル・スループットなんすか？
おまえはドリームキャストを馬鹿にしたな
もとい、水平加算を伴う命令は将来シングルサイクルスループットでできるようにすることは
開発者向けには前々から公約にしてたよ。
「Gesher」というコードネームが消えた今となっては真相は誰も知らないわな。
つーか、あの資料の該当ページを抹消したのにも何かしらロードマップ上の理由があったと思ってるが。
225:MACオタ＞団子 さん
08/10/06 04:53:48 pdu9F3SC
>>224
-----------------
Gesherも死んでSandy Bridge/IvyBridgeは後釜なんじゃないの？
-----------------
思い込みに合わせて現実を改変するのも勘弁して欲しいす。一応風数ソースで。
URLﾘﾝｸ(pc.watch.impress.co.jp)
=================
Sandy Bridgeは、もともとはヘブライ語のコードネーム「Gesher(ゲッシャ)」で呼ばれていた。
GesherからSandy Bridgeへと変わったのは、技術的な内容の変化があったからではなく、
名称だけだという。
=================
URLﾘﾝｸ(www.atmarkit.co.jp)
=================
32nmプロセスの2世代目（新しいマイクロアーキテクチャを採用）の開発コード名が従来の
Gesher（ゲッシャー）からSandy Bridge（サンディ・ブリッジ）に変更されたが、こうしたコード名の
変更は「靴下を替えるように、頻繁にあること」だという。
=================
もう少し詳しい理由わ、こちら。
URLﾘﾝｸ(www.theregister.co.uk)
=================
Gesher - 'bridge' in Hebrew - is also the name of an Israeli political party.
We wondered how long Intel would stick near the semi-charged name and have now learned
the answer -- about seven months.
=================
226:,,・´∀｀・,,）っ-○◎●
08/10/06 05:03:54 Gjt1lbWv
で、7は誤植で8だという根拠は？
7は誤植だという一方で8が真実だというのはずいぶん都合がいい考え方だなぁ
4GHzで28GFLOPSとも書いてあったぞ。
227:,,・´∀｀・,,）っ-○◎●
08/10/06 05:05:55 Gjt1lbWv
URLﾘﾝｸ(xtreview.com) /images/davis.pdf
これだろ？
先に出るLarrabeeのベクトル長が8か16かも曖昧な資料が根拠になにを妄想してるのかなFUCKくんは
228:,,・´∀｀・,,）っ-○◎●
08/10/06 05:09:15 Gjt1lbWv
FMAがSandy Bridgeで実装されないことそのものがロードマップの修正だと思わんかね？
Intelの*mmintrin.hでサポートされる組み込み関数の使える命令がCPU世代をまたがったことは一度も無い。
229:,,・´∀｀・,,）っ-○◎●
08/10/06 05:30:14 Gjt1lbWv
Sandy Bridge世代ではいまだに内部128bitである根拠
◎AVXではメモリアドレッシングで指定されたソースに対しミスアラインロードを許容するが、
SIMDユニットがネイティブで256ビットをサポートするとすれば、アラインメント補正処理を
ユーザーに開放したvpalignrの256bit版がないのはおかしい。
シフト・ローテート処理が128ビットのままでは、スループット的にアンバランスが生じる。
◎256bit化の対象となってる浮動小数演算は、SIMD演算ユニットが内部128bitのまま256ビット版を使う
・命令レイテンシ隠蔽のため引き伸ばすだけでも実効性能は伸ばせる。
・SandyBridge世代においてもなお16バイト/clkまでしかないらしい命令フェッチ帯域の節約になる。
まあ俺はどっちでもいいよ。
内部256bitといい続けることで恥をかくのはお前だけだから。
230:MACオタ＞団子 さん
08/10/06 05:49:29 pdu9F3SC
>>229
前者わ興味深い指摘だと思うす。今後わ、最初にこういう論拠を示してから自説を展開するように
お勧めしたいモノす。
後者に関してわ、何度も現実に裏切られているのでわ？
231:MACオタ＠補足
08/10/06 05:55:43 pdu9F3SC
>>227
少しだけ補足す。
-----------------
先に出るLarrabeeのベクトル長が8か16かも曖昧な資料
-----------------
"Terra Terra Terra"のp.16のブロック図に"SIMD-16"とあることから、この時点で16(512-bit)-wideわ
確定していたことが判るす。従ってDP flopsの未確定部分わ、この時点で積和命令を実装するか
否かが確定していなかったことを示すす。
232:,,・´∀｀・,,）っ-○◎●
08/10/06 07:11:08 Gjt1lbWv
じゃあ、palignr の256bit版が存在しないのを「誤植」だとでも思っておきなよ。
VEX.L=1にすると未定義例外が出るってハッキリ書いてあるんだがな。
たとえばAltiVecｔのvpermが先頭64ビットまでしか作用しなかったらきっと
理不尽だと思うだろうけどそれと似たようなもんだよ。
233:,,・´∀｀・,,）っ-○◎●
08/10/06 07:14:21 Gjt1lbWv
全部誤植でAVXのベクタ長は1024ビットかもしれないよ
極論言うとMACヲタの妄想はそういうことだ
234:Socket774
08/10/06 07:21:47 +Gr7A0as
実物が無い以上
全部妄想です
235:Socket774
08/10/06 07:28:18 kNki4HP2
xmmレジスタが登場してから演算器が128ビットになるまでを考えると128*2の可能性は大きいな。
同業者の状況を見るに、急いで新昨日で巻き返さないといけないなんて状態でもないし。
236:Socket774
08/10/06 09:32:50 xPkVE/H5
7DPで28GFLOP資料が間違ってるという一方でそれを根拠に
237:Socket774
08/10/06 09:59:29 xPkVE/H5
7DPで28GFLOPS＠4GHzという資料が数字が間違ってるという一方で
それが根拠にネイティブ256bitだというのは苦しいわな。
256bitでない根拠にならなりうるが。
間違ってると言った数字を根拠にする理屈はありえない。
ちなみに積和＋内積で7DPを満たせるってのはム板でも議論されてた。
64bit SIMDではあるがK7ではE3DNow!によって内積をスループット1クロックで行えていた。
別に困難でもないんじゃないの？パイプライン段数増えていいなら。
238:,,・´∀｀・,,）っ-○◎●
08/10/06 11:07:36 Gjt1lbWv
URLﾘﾝｸ(software.intel.com)
もう既に。中の人に近いところではAVXのパフォーマンスについて議論がなされてるよ。
AVX-256での行列積のスループットはSSE2の1.4～1.6倍程度だそうだ。
ざっと概算しても新命令のvpermil2psの効果分＋3オペランド数増加分程度の
スループット向上しか得られてない。
これは内部128ビットのままである証拠にならないかな？
MACヲタも無根拠な256ビット幻想なんて捨てて
Intel謹製のパイプラインシミュレータでスループットの検証してみれば？
239:,,・´∀｀・,,）っ-○◎●
08/10/06 12:04:19 Gjt1lbWv
むしろSandyBridgeって乗算命令って2ポートで発行できるようになってないか？
FMA＋DotProductで7DPを実現するスタイルだと、乗算だけに限っては既存のCore 2ファミリの
2つの浮動小数ユニットのどちらでも2DP/4SPの乗算が可能になる。
まあ、加減算とは排他になるが。
240:,,・´∀｀・,,）っ-○◎●
08/10/06 12:20:40 Gjt1lbWv
でだ
FMUL/FADDとある２つの演算機の両方に乗算・加減算を実装してどちらでも加算・乗算を発行できる
ような形にすれば、既存のSSEコードでも若干性能向上が期待できる。
それに、新命令のFMAのパフォーマンスという観点でも1つの実行ポートに両方の演算ユニットが
ぶら下がってるほうが性能を出しやすい。
256bitでのパフォーマンスが伸びてないというより、レガシーを含めた128bit SIMDでの
パフォーマンスを若干ながらも伸ばすアプローチを採るのはそれなりに意味はある。
いじょ。
フォローしておくと256bit SIMDでも相当速いよ。シミュレーションの通りなら
今のCore 2と比べてざっと2倍ってのは嘘じゃない。
単に256bitじゃないと恩恵が無い実装にはしなかっただけでしょ。
241:Socket774
08/10/06 21:20:32 ooDOnZoT
とりあえず、この手の話で
団子 >>> MACオタ
なのはよくわかった。
今日の団子はいつもよりかなりまともな理屈をならべているな。
242:Socket774
08/10/06 21:30:52 ooDOnZoT
つーか、団子は正直、拡張命令ネタだけでいい。他はいらん。
243:Socket774
08/10/06 21:56:38 ooDOnZoT
対戦成績表'08
ﾅﾏｴ 10/6
---------------------------------------------------------------------
団子 ○
オタ ●
10/6 AVXの実装など
244:,,・´∀｀・,,）っ-○◎●
08/10/07 01:05:22 Aeh0Wlge
MACヲタとかってさ
まさかとは思うんだけど
AVXの128bit SIMDを使うと、256ビットの上位128bitも毎回ゼロクリアしないといけないから
256ビットでないといけないとか
思ってないよな？
まあ俺も最初はそう思ったよ。
でも、よくよく考えたらさ
むしろ、YMM下位(XMM)のみの演算ではYMM上位が常に0と決まってるからこそ、
上位のゼロクリア処理をサボって256bit未満の幅のSIMDユニットでも効率的に処理できるわけだよね。
fxchやxorゼロクリアでレジスタリネーミングのヒントとして解釈するのと同じで。
AVXのマニュアルには、レガシーSSEを使うと、YMMの上位をゼロクリアせずそのまま残すから偽の依存関係が発生するとある。
逆に言うと、AVX-128を使ってるときはYMM上位の依存関係が常に解消されてるってことなんだよね。
そりゃそうだ、結果が常に0なんだから。
その値をソースにとるAVX-256の命令あるいはレジスタ退避命令に遭遇するまで、実際にゼロクリアをする必要すらない。
で、レガシーSSEをなんでYMMの上位をゼロクリアしない仕様としたのかって、
そりゃおそらく、AVX-256との併用時に依存関係を故意に発生させて、性能出なくするためだよ。たぶん。
まさに飴(AVX)と鞭(SSEと同時利用することに対するペナルティ)。
そうまでしても、プリフィックスが付き捲って複雑怪奇な命令フォーマットとなってしまったSSEを整理したい。
245:Socket774
08/10/07 07:06:44 z3zv0nRE
larrabeeってDX11世代のGPUやOpenCLで使った場合のGPUに対して
余程のパフォーマンス的アドバンテージが無い限り
結局ニッチな仕様のGPUで終わるんじゃないのかい？
246:Socket774
08/10/07 08:10:27 RBYU5KK8
ところがCPUに内蔵されるようになる予定だから話はちょっとこじれる。
247:Socket774
08/10/07 11:59:50 ikSGh2Nd
それはAMDがやろうとしてる事と
何が違うの
248:Socket774
08/10/07 12:07:47 AXOmBY8z
どうせCPUに内蔵されるから、単体カードとしてのLarrabeeはぼろぼろでも、
CPUに内蔵されたら、今と同じでシェアだけは高い可能性があるってことじゃね？
249:Socket774
08/10/07 12:28:34 Jbkrm287
マリオと抱き合わせでクソゲーを買わされたトラウマが…
250:Socket774
08/10/07 12:34:13 z395BKc1
>>247
ポイントは全部x86。
同じ命令セットで汎用スカラ処理が得意な大きなコアとSIMDだけは得意な特化型コアが並立する。
で、ワークロードに応じて最適なコアを選んで実行するようになる。
AMDのやろうとしてることの最終構想はCPUのSSE命令をGPUでやること。
現実にはGPUの大量の演算ユニットだけあってもSSE命令の供給が間に合わなければ意味がない。
CPU内蔵のFPUすら、持て余してる時間が多い。
フロントエンドやスケジューラにどれだけトランジスタつぎ込んでるか考えれば
AMDがやろうとしてることがいかに無謀で馬鹿げてるかは。
251:Socket774
08/10/07 13:05:15 ikSGh2Nd
適切なコアの判断は何処でやるの？
252:Socket774
08/10/07 14:10:41 Qxng3wLy
並列計算プログラミングを勉強している者ですが、質問があります。
Dual CoreとQuad CoreのCPUを用いてバックトラッキングの速度計算をやっているのですが、
実際のマルチコア対応演算プログラム（例えば、将棋や囲碁など）だと、
Dual CoreとQuad CoreはSingle Coreの物と比べてどのような処理をやっているのでしょうか？
253:Socket774
08/10/07 22:47:24 z395BKc1
>>251
OSのカーネルじゃね？
XP/VistaのカーネルはRDPMCでプロファイルとってコンテクストの割り当てを最適化する
機構を既に備えている。
現状、SMTで論理プロセッサが複数あるCPUで、同一物理CPUかを判定したり、
メモリ階層を考慮した最適化くらいはOS側でやってくれる。
IntelとMSは共同でメニーコアの研究やってるからなんらかの解決策は出してくるでしょ
254:Socket774
08/10/07 23:16:45 lzSJaurJ
ララビーのコア1個1個はOSから
それぞれCPUとして認識されるっての？
255:Socket774
08/10/07 23:33:09 z395BKc1
GPUではなくずっと先の話だ。
256:,,・´∀｀・,,）っ-○◎●
08/10/08 01:57:04 0Yot2dF8
>>252
「バックトラッキング」って言葉の意味がわかってるなら話は単純だが
複数のコアあるなら、その分だけスレッド起こして各枝の探索に割り当てていけばよくね？
257:MACオタ
08/10/08 07:46:16 Iaqsra3B
IBMがDunnington対抗でPOWER6搭載サーバーのミドル～ローレンジで搭載コア数を2倍にしたす。
単純にソケット数を2倍にした模様。
URLﾘﾝｸ(www-03.ibm.com)
-------------------
As the world's most popular midrange server, the IBM Power 570, now offers more energy
efficiency and consolidation options with new processor cards that double the number of
cores in the same system footprint.
-------------------
過去の情報でわ
「POWER6+でコア倍増(MCM?)」ｽﾚﾘﾝｸ(jisaku板:850番)
「実わ実装密度倍増？」ｽﾚﾘﾝｸ(jisaku板:45番)
ときて、結局POWER6でソケット数倍増という形で実現しているす。POWER6+って順調に遅延しているか、
Dunnington対抗で、製品投入を急いだという感があるす。
ただし、ミドルレンジのPOWER570にもハイエンドと同じPOWER6/5GHzを投入しているすから、搭載
チップ数倍増と合わせて、POWER6自体の歩留まりわ上がっていそうす。POWER6+登場前の在庫
整理の可能性もあるので、POWER6+がいつ登場する(or しない)かわ、注目す。