CPUアーキテクチャについて語れ Part.13

おいお前らいい加減、無能なAMD房・Intel房・GKに振りまわされず、
エンコ時間がどうとかPIがどうとかPS3がどうとかじゃなく、
CPUコアのアーキテクチャについて語りましょう。

x86/RISC/CISC/スーパースカラ/VLIW/MIMD/SIMD
等について語ってもよし、
各SPUの汎用レジスタ128本のCell B.E.マンセー、
x86なワンチップスパコンのLarrabeeマンセー、
時代はGPGPUだ！、Sunは漢の浪漫！、龍芯(笑)、
昔々8086の時代は(以下略・・・等もよし。

さあ、不毛な争いを止めてCPUアーキテクチャについて語ろう！

前スレ
CPUアーキテクチャについて語れ 12
http://pc11.2ch.net/test/read.cgi/jisaku/1214999146/l5

【過去スレ】
Part 1　http://pc5.2ch.net/test/read.cgi/jisaku/1082357989/
Part 2　http://pc7.2ch.net/test/read.cgi/jisaku/1101041110/
Part 3　http://pc7.2ch.net/test/read.cgi/jisaku/1139046363/
Part 4　http://pc7.2ch.net/test/read.cgi/jisaku/1151732227/
Part 5　http://pc9.2ch.net/test/read.cgi/jisaku/1159238563/
Part 6　http://pc9.2ch.net/test/read.cgi/jisaku/1169393906/
Part 7　http://pc11.2ch.net/test/read.cgi/jisaku/1172923824/
Part 8 http://pc11.2ch.net/test/read.cgi/jisaku/1178140550/
part 9 http://pc11.2ch.net/test/read.cgi/jisaku/1186887760/
part10 http://pc11.2ch.net/test/read.cgi/jisaku/1202913839/
part11 http://pc11.2ch.net/test/read.cgi/jisaku/1214999146/
part12 http://pc11.2ch.net/test/read.cgi/jisaku/1219884494/

自作板CPU系スレッド 現行スレ案内＆過去ログ保存サイト
http://cpu.jisakuita.net/

※ 当スレは固定ハンドル非推奨となっております。

1時間エアロバイク漕ぎながら待ってたんですが
新スレ立たなかったので立てちゃいました。

固定ハンドルで議論をしたい人、このスレッドで話題にするまでもない痴話喧嘩は
こちら↓

私の肛門もフェンスに強制終了させられそうです #3
http://pc11.2ch.net/test/read.cgi/jisaku/1223185986/

前スレの団子はあいかわらず酷いな。
Win32 fiberとかJITとか誰もそんな議論していないのに。

どうでもいい方向に話を逸らして思考停止するのは常套手段。

>>5-6
私わ、その辺の資料に書いてある内容をそのまま引き写してきたような投稿より、団子さんの方が
面白いす。

自己レスだけど

>>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だとは思っていないよ。

資料読んでだいたいの事は把握したんですが、
?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の資料リンク↓
http://s08.idav.ucdavis.edu/lefohn-programming-larrabee.pdf
http://s08.idav.ucdavis.edu/forsyth-larrabee-graphics-architecture.pdf
http://s08.idav.ucdavis.edu/pharr-advanced-rendering-on-larrabee.pdf

>>5
だってFiberと名の付くものは同じ実装だと思い込んでる子がいるんだもの。
Win32 Fiberの話題を振って「これと同じす」と言ったのはMACヲタ
「別物」と言ってやってるのに聞かないから困りものだ。

>>8
そんなことは俺も言ってない

1-4×HW Thread = n×Fiber

>>8
> この(最大)4xFiberというのは同時に実行されるfiberの数を言いたかった。

1つのコアあたりの話ね。
もちろん同じバイナリのfiberは他のコアでも動いているだろう。

>>11
それは団子が言った
> LarrabeeでいうところのFiberは同じ1コアで動かすべき4つまでのスレッドを纏めたものにすぎない。
を訂正するという意味？

>>9
アドレッシングモード付き積和算で10クロックは軽く超えそうだよ

4HW Threadフルに使うケースでは命令レベルで、そこの資料にも書かれてる10並列のインターリーブは
多くの場合不要ではないかと。

オペレーションの命令レイテンシ×16÷各FiberのStrand数＋α
くらいが実際にインターリーブが必要なFiber数になるかと。

>>8
　　-----------------
　　64xStrandsの説明
　　-----------------
Strandわ"a program invocation that runs in one SIMD lane"す。レジスタを一つしか使わない
プログラムなんて無いすから、16-wide x 16-registers で256 strandsなんてことわ無いって
だけかと。

>>13
それ自体は矛盾しないだろ？
スレッドとFiberの関係はどちらかに N : 1 対応するものではないということ。

固定ハンドル使いは自己防衛に入りすぎて議論ができないやつが多いから非推奨
実質、このスレの名無しとレベル変わってないのはもう明らかなんだから名無しでかきこみゃ十分だろ。

>>8
64 strandsは単にLarrabeeのruntimeの仕様じゃねーの?
現時点で無理に正確な解釈を導きだそうとしなくてもいい。
2-10っていのはtypicallyなんて書いてない。
LarrabeeをGPUとして使う場合はTextureユニット数の制約もあるし、
その関係かもよ。

いずれにしろ団子みたいに何が何でも俺の妄想が真実だと強要するバカはいらない。

>>15
すまんが意味がわからない。
256じゃないから64という理屈？

>>17
　　--------------------
　　2-10っていのはtypicallyなんて書いてない。
　　--------------------
http://s08.idav.ucdavis.edu/lefohn-programming-larrabee.pdf (p.12-14, )
　　=====================
　　More Fibers running (typically 2-10, depending on latency to cover)
　　=====================

>>16
いいや何度も言うが、Strand数は16×スレッド数だよ。

同じ命令コード列を〜4スレッドでインターリーブして実行した方がコードキャッシュ容量の節約になるし
同じコアで動くスレッド間でのデータ交換にペナルティがない機構を十分に発揮するのに都合が良い。

>>18
　　-------------------
　　256じゃないから64という理屈？
　　-------------------
この辺の数値わ典型例の模様す。
64ってのわinelがLarrabee用に書いたコードで実際に存在するんだと思われるす。

>>16
いやいや
明らかに言ってること変わってますやんw
訂正するなら訂正してくれないと議論が混乱し続けるだけだよ

16レジスタ全部使うとかどんだけ？
テンポラリすら確保できねーぞ。

せっかくVEXプリフィクスでNon Destructive Sourceレジスタ追加したのに意味ね-ｗｗｗ

>>22
いいよ。正確に言おう

FiberはCPU時間を細粒度で時分割したものではある一方で
Threadに対する完全な従属関係ではない。
64 Strandなら同じコアで動く4スレッドで分割処理される。
最初から命令レベル並列に振るよりは、スレッドで分割するように振った方がコードサイズもレジスタも節約できる。

>>20
　　--------------------
　　同じ命令コード列を〜4スレッドでインターリーブして実行した方がコードキャッシュ容量の節約になるし
　　同じコアで動くスレッド間でのデータ交換にペナルティがない機構を十分に発揮するのに都合が良い。
　　--------------------
かつて同じことを想定した立場で書くと、リネーム無しで命令をインターリーブするためにわ使用
レジスタが重ならないようにすることが必須す。しかしプレゼン資料によると、
http://s08.idav.ucdavis.edu/forsyth-larrabee-graphics-architecture.pdf (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
　　=====================

>>19
同一スレッド内でlatencyをカバーするためにファイバが入れ替わり立ち替わりに動く。
典型的には2-10ファイバが入れ替わる。
他の数字は典型例ではないでしょう。
SW-managedなファイバが今のruntimeの仕様で64 strandsなら別に納得できるし。

>64 Strandなら同じコアで動く4スレッドで分割処理される
そもそも1 threadで10 fiber(160 strands+ ?)くらいは入れ替わってくれる図があるんだからその解釈はおかしいだろ。

>>23
　　------------------
　　16レジスタ全部使うとかどんだけ？
　　------------------
Strandの単位わ、レジスタでわなくSIMDの1-wayす。つまり一つのSIMD命令で最大16-strandsが
処理できることになるす。(マスクアウトされて全データが有効でわ無いすけど。。。)

＞かつて同じことを想定した立場で書くと、リネーム無しで命令をインターリーブするためにわ使用
＞レジスタが重ならないようにすることが必須す。

だからそれはJITにやらせることが可能だって。
公開中止になったSoftWireと同じことをやってるライブラリが既にあって

http://homepage1.nifty.com/herumi/soft/xbyak.html

ここのboost::spiritを使った簡易電卓のサンプルでやってることがまさにそれだろ？

で、ついでだからコミット履歴も見てくれ

>>27
16×16 =　256 Strandって言ったのはお前だろｗｗ

>>28
リネームレジスタがあるOoOEコアと比較してわダメす。

はあ、アホ固定コンビ疲れる。
また自己顕示で暴走しそうな展開になってきたな。
無理に確定的な結論だそうとするな。

インオーダのAtomでも動くライブラリなんだけど。

>>29
あなたわ『単位』が読めないすか？

>>32
速度という観点わ何処へ？

たとえば
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になってるんじゃないかと思ったんだけど
まったく検討違いかもしれない。

コア全体で各スレッド16本、64本のSIMDレジスタがある。
これが足りないと思うか？
レジスタ番号はJITコンパイルするときまで決めなくていいんだぜ？



Native C/C++やアセンブラを使ったプログラミングモデルでも
Fiberなんてものが利用できると思ってるから混乱するんじゃね？

>>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を処理する必要があるとき。

>>36
GPUのレジスタ数と比べてみれば如何すか？例えば、
http://pc.watch.impress.co.jp/docs/2008/0716/kaigai453.htm
　　----------------------
　　G80では、Streaming Multiprocessor(SM)当たりのレジスタ数は8,192本だった。
　　----------------------
固定機能を持たないLarrabeeでの必要レジスタ数わ、どうなることやら。。。

スカラコアのNvidiaのGPUだと比較がマズいすかね。。。
http://pc.watch.impress.co.jp/docs/2005/0914/kaigai212.htm
　　-------------------
　　Xbox 360 GPUは、合計で24,576本のベクタレジスタを持つ。
　　-------------------

>>35
それだと16strands

1strandは、1ピクセル(4要素)に対応する
4要素はそれ以上分割しても意味がないでしょ

もちろん、単純な64要素のベクトルとして見るなら64strand

>>38
ぜんぜん問題ないね。
x86はロードと論理・算術演算を1命令で行える。
キャッシュと大規模レジスタファイルどっちが有利かなど、判断しかねるよ。

既存GPUはキャッシュが小さいからLUTが使えないという
グラフィック処理に強く依存してるが故の欠点は前スレでも指摘したよね。

>>40
Strandsの分割法わ不明すけど、
　　----------------
　　1strandは、1ピクセル(4要素)に対応する
　　----------------
4要素をSIMDで計算するやりかたと、1要素づつ計算するという分割が考えられるす。
後者の方がプログラムとしてわ、自由度が大きかったりするすかね。。。

あの〜、strandは1要素(スカラ値)に対する処理の流れ何で、1 pixel or vertexに対応する単位ではないの。
512bitのSIMDレジスタは、16 strandsに対応するってことまでは殆どわかってる話なんだが。
各スレッド16本だったら256 strandsだけど、お前らもう混乱してるだろ。

＞　Xbox 360 GPUは、合計で24,576本のベクタレジスタを持つ。

コア全体で384KBか。
その代わりキャッシュは小さい。

LarrabeeのL2キャッシュは16コアで4MBじゃなかったかな？
L1は全コア合計1MBくらい？

>>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は論理的なプログラムの単位なので、
典型的なシェーダプログラムなら、サブピクセルに分割できません

one SIMD lane == 32bit scalar
の意味。
vertex (3〜4要素), vector register(16要素)
ではありません。

>>47
パックドピクセルという考え方じゃないよね
1ピクセルは4つのスカラ値であって、4要素のベクトルじゃない

>>42
　　-------------------
　　キャッシュと大規模レジスタファイルどっちが有利か
　　-------------------
団子さんの想定するインターリーブ方式ファイバだと大規模レジスタの方が「有利」かと。

>>8
> この(最大)4xFiberというのは同時に実行されるfiberの数を言いたかった。
> typically 2-10というのは一つのシェーダがその数のfiberに分割されるという意味では？
> 64xStrandsの説明がつくのはこの解釈だけに思える。
> そうでないならここの説明はどうする？＞MACオタ他、否定する人たち

小町算乙

>>49
昔みたいにレジスタが高速なメモリだった時代ならね。
レジスタにもバッファが必要になったり、もうわけわからんよ。

>>24
> Threadに対する完全な従属関係ではない。
違う

> 64 Strandなら同じコアで動く4スレッドで分割処理される。
違う

たのむから数字にだけこだわって資料を読まないのは止めてくれ

むしろ1 Fiber == 1 Vertex or Pixelの方が計算あうな。
使わないところは適当マスクしながら切り替えるとして。
まあ、妄想の域をでていかなから続報待ちだが。

お前の「違う」には根拠が無い

実際のところ、Intelわ"Wide variety of scheduling algorithms"を謳っているすから、ハードウェア
スレッドの中で、どのように複数のファイバを埋め込むかわ、命令単位でも関数単位でも自由に
可能す。
命令単位の混在も、単なるインターリーブでなくファイバごとの所要リソースや優先度に応じて
ダイナミックに切り替えることを想定しているんじゃないすかね。ファイバAで3命令->ファイバB
1命令->ファイバC 2命令。。。とか。

ただ良く判らないのわ、レジスタ数少な目のx86でこのような点を売りにしていることだけす。
団子さんの書いているように、メモリを引数に取れる点と2引数のISAわ所要レジスタの削減
に有用すけど。。。

JITを通したあとはダイナミックでもなんでもないんだが。
自己書き換えのペナルティはIntelアーキテクチャリファレンスマニュアルあたりでも参考に。

>>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
ギャラリーに注意を促しておかないとな

>>53は間違い。

>ただ良く判らないのわ、レジスタ数少な目のx86でこのような点を売りにしていることだけす。
ファイバもソフトで管理されるという定義がされているだけで、
レジスタやらIPやらは切り替えることになってるんだが。
レジスタが少ない方が有利なのは代わりない。
ファイバをいかにうまく扱えるかはIntelの用意するソフト環境次第。

もう一つ疑問点わ、近年のx86の進歩が計算結果のフォワーディングによってレジスタの不足を
補っている点す。演算結果の代入先をメモリにしておけば、直後の命令わレジスタの使用無しに
高速に結果を取得できるす。

ところがファイバ等で直後の命令が別のコンテキストに属すとなると、上記の効用わ失われるす。
Pentiumのような旧世代コアを採用した理由もこの辺にあるすか？

>>55いつの情報だ？
Larrabeeの新命令がAVXと同じくVEXプリフィクスを使った3〜4レジスタオペランドフォーマットであることは
散々言ってるわけだが

つーか、べつに引数が多いとレジスタ所要量が多くなるわけではない。
srcとdestに同じ値を指定できないわけじゃないだろ？

> レジスタが少ない方が有利なのは代わりない。

liveなレジスタだけ保存/復帰すればいいので、レジスタの数は関係ないよ

>>58
アーキテクチャレジスタが多いなら、スイッチの頻度を減らせる or 同時進行のファイバ数を
増やせる筈す。

>>59
モダンなx86アーキテクチャでの浮動小数演算みたいな高レイテンシの命令は
インターリーブを前提としたタグインデックス方式ですけど。
無知もたいがいに。

計算結果のフォワーディングは汎用プロセッサ向けの実装だと思ってる。
GPUみたいなレンダリングパイプラインいちどにワーッとやって終わり。
結果はすぐにor未来永劫使わないのを前提に進化してきたジャンルなわけで。

>>60
　　---------------------
　　AVXと同じくVEXプリフィクスを使った3〜4レジスタオペランドフォーマット
　　---------------------
それ一般の算術命令も全て3-4引数にするすか？アキュミュレータ命令わ全て廃止とわ
聞いていなかったすけど。。。

>>65
x86古来のスカラ命令はそのままだよ。
なんでワイドベクトルを処理するのに非SIMD命令を使う必要がある？

AVXで3〜4オペランド化したのはSSEだけっての忘れたか？

そもそも、1thread上で2-10fibersが動くということは、少々のことでは埋められないレイテンシーがあるわけで
ファイバースイッチのオーバーヘッドなんて気にしても仕方がないんじゃねーの

>>67
アキュミュレータわ「演算機能付メモリ」という概念すから、SIMDでも一緒かと。
AVXに関してわ調べてみたすけど2引数のADDPDと3引数のVADDPDというような形で
並立するんじゃないすか？

どうも64xStrandが釈然としないなー
そもそもStrandという概念はどういう意図で作られたものなのだろう？
16way中の1wayを単位にする意図がわからん。

>>62
じゃあ単純にレジスタ数が多少少なかろうが、
ファイバがあったの方がよかったってだけだろう。

＞ファイバースイッチ

RIPレジスタが直列に並んだ命令列の次の命令を指すのを
「スイッチ」なんて言うのか？ｗｗｗｗ
あたまわりーｗｗｗ

>>70
　　------------------
　　16way中の1wayを単位にする意図がわからん。
　　------------------
ベクトルを処理の単位にすると、SIMDの幅とぴったり合わない場合に無駄が生じるからす。

>>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の論理的な最小単位ということですね
コネクションマシンの仮想プロセッサ(のプログラム)みたいなもん

>>69
ADDPDは「レガシーSSE」
AVXなのはVADDPDな

資産はそのまま使えるけど新フォーマットに徐々に移行してくださいね、がIntelのお達し。
新たに書くコードにおいてレジスタを破壊してもいい場合はaddpd xmm0, xmm1を使うじゃなくて
vaddpd xmm0, xmm0, xmm1を使えってこと。

>>70
Strand
Strand
Strand
Strand
Strand
Strand
Strand
Strand
Strand
Strand
Strand
Strand
Strand
Strand
16-wide vector unit

Strandという概念は今ある資料だけでは正直理解できん。
1スカラ要素を追跡して一体なんの意味があるのかねぇ。
3Dグラフィックスプログラミングをやっているやつなら
Intelの資料は今のところ完全じゃないとおもって続報待ちするのが吉。

JITのやってることに幻想を抱いてる奴はGoogleのJavaScriptエンジンのソースを嫁。
Javaでもいいけどな。

>>75
後方互換を気にしない場合は、じゃないの

>>73
いやそれはわかるよ。
でもLarrabeeであってもHLSLとか使う限りシェーダプログラマは4要素ベクターを基本に処理を書くよね。
できっとLarrabeeのシェーダコンパイラがうまく16way使うように並び替えてくれるんだろう。
つまりそれってプログラマからは見えないところだよね。
64xStrandという何か意味的に同質のものが64並列化されてるように思える。
そのあたりに不自然を感じるのよ。

ぶっちゃけ、1 Strand == 1 pixel or vertex
16 wayの図は間違いだと思いたい。

>>76
> Strandという概念は今ある資料だけでは正直理解できん。
> 1スカラ要素を追跡して一体なんの意味があるのかねぇ。

そう、おれもそう思う。

1 strand == 1 scalar 〜 1 pixel or vertex
で変動だったら理解できるんだが、例によって計算が合わない気が。

>>78
必要なら、両方を書いてCPUID見てブランチすればいいじゃない。
後方互換のために使うななんて言ってたらいつまでも移行は進まない。

多数あるstrandの中から1 strandを切り出して他と組み合わせたりする。
まあ要するにpermuteするってこと??　そのために用意した概念っていうならまあ理解できるな。

>>83
それはつまりMACオタの言うところの並立じゃん

>>82
Scatter/Gather命令ってのがあって、任意のアドレスから16個の要素を引っ張ってきたり
逆に分解してストアする命令があってだな。


座標がx, y, zならそれぞれxだけ、yだけ、zだけでベクトルを再構成する。

>>79
> 64xStrandという何か意味的に同質のものが64並列化されてるように思える。

複雑なシェーダプログラムは16way=16strandsに、
簡単でレジスタもちょっとしか使わないものは16wayを4つで64strands、で納得いかない？

>>81
>>82
どこにそんなに引掛ってるのかわからんのだが、
ふつうプログラマって、1ピクセルについてどうこう、とアルゴリズムを考えるんじゃないの？

Strandに対応するプログラムはコンパイル後にはないと思う。
言語によってはソースではstrandのプログラムを書くものがあるかもしれない。
(C*やData-parallel Cみたいな感じ)

>>79
Larrabeeに関してわ、ソフト次第でどうとでも書ける訳すから、SiggraphのIntelのプレゼンわ
一例に過ぎないと思っておけば良いす。
　　------------------
　　シェーダプログラマは4要素ベクターを基本に処理を書くよね。
　　------------------
スカラプロセッサでもベクトル処理わ可能す。16-strandsの例わ512-bit SIMDを16個のスカラ
プロセッサとして使用する例と読めば良さそうす。

ベクトル内の要素を取捨選択するための機能わ、ハードウェア的に用意されているす。

>>85
いいや。並立の考え方がそもそも違う。
彼の場合は、「オペランド指定できるレジスタに制限があるほうがレジスタが節約できる」
と思ってて、同じコードシーケンスで併用するものと解釈してるっぽいので。
別に3〜4オペランドだからってsrcとdestに同じ値を指定して破壊したらいけないわけではない。

いやいや、ID:WHIgITGQは、3Dグラフィックスのプログラミングにおいて、
1要素だけを操作したり入れ替えたりという行為は殆ど意味がないし実際やらないから
strandの意味するところに疑問をいだいてるんだと。
団子のいうようにScatter/Gatherでメモリ配置を大規模に入れ替えるというレアケースの
ための概念ならまあ理解できる。

>>90
　　-----------------
　　3Dグラフィックスのプログラミングにおいて、1要素だけを操作したり入れ替えたりという
　　行為は殆ど意味がないし実際やらないから
　　-----------------
Strandわプログラムの単位で、データの単位じゃ無いす。単一のSIMD演算で実行しないという
だけで、1-wayのStrandで複数要素を扱うプログラムわ可能す。

けっきょく、Strandなるものを導入しているのは

「Data-parallel programにおいては」
・ハードウェアのSIMD幅などはあまり意識しないでくださいよ
・ベクトルレジスタの要素は同じ種類にしてくださいよ、パックドピクセルみたいなのはやめてくださいね

と主張したいということでしょう
データパラレル用APIやコンパイラが存在して、そうなっているのかもしれないけど

別にレアでもなんでもないぞ。たとえばグレースケール変換なんかじゃしょっちゅうやること。

MACオタが正しく理解している(T_T)

StrandというのはData-parallelism用語で、20年以上前からあるので、それをそのまま使ったんでしょう

>>88
64Strandってのが、例えば本当に64Pixel/Vertexのことで、
4要素ベクトルも全部スカラーに分解して、
1Fiber内で64個分並列化する可能性のことを言ってる？
それなら筋は通るけど、ありえないよなぁと思う。

>>90
そうなのよ。
わざわざStrandっていう概念を出すことの必要性に疑問を感じてる。
名前的にもThread(糸)、Fiber(繊維)、Strand(髪)と似てるんだから
概念的にある実行シーケンスの単位の一つのように思える。
でもその実体がSIMDの1wayということが釈然としない。

>Strandわプログラムの単位で、データの単位じゃ無いす。単一のSIMD演算で実行しないという
>だけで、1-wayのStrandで複数要素を扱うプログラムわ可能す。
この2行は最初からわかっているし納得できるんだが。
そもそもSIMD演算で性能を発揮することが前提のLarrabeeでStrandで複数要素を扱うメリットが理解できん。
Scatter/Gather命令で計算しやすいようにデータのレイアウトを高速に変更できるってのが特徴ってなら理解できる。
>>93 3Dゲーでリアルタイムにデータ要素を入れ替えるのは全体の計算量からいったらごくわずかだろ。
単にruntimeとかで扱い安い概念としてのStrandだと思う。

>>95
高級言語とアセンブラの関係、あるいなP6以降のx86命令セットアーキと内部アーキの違い。
ソフトGPUは極度に抽象化されてるんだよ。

>>95
加えて、釈然としない人のために、ネイティブのSIMDをダイレクトに使うための手段を用意してるんだから
気に入らないならそっちを使えばいい。俺はそのつもりだし。

>>96
　　----------------
　　そもそもSIMD演算で性能を発揮することが前提のLarrabeeでStrandで複数要素を扱う
　　メリットが理解できん。
　　----------------
GPU的用途でわ、「同じ演算」を行う対象が山ほどあるすから、横に並べてSIMD演算でも、
1-wayのStrandを大量に処理しても同じ効率になるのだと思われるす。

う〜わかってないなあ。
2D画像処理とか科学技術計算とかなら理解できるけど、
3Dゲームのグラフィックスの計算で、4要素とかのベクトルデータをバラに考えるケースなんて
殆ど存在しないって。
まあ、知らないのだからいいや。次に興味のある話題までROMってるわ。

というか、言ってしまえばLarrabee＝GPUエミュレータ

>3Dゲームのグラフィックスの計算で、4要素とかのベクトルデータをバラに考えるケースなんて
>殆ど存在しないって。
そもそもGPUが3Dゲーに異常進化できたのもこの前提があるからなんだけど。
Larrabeeはそこからちょっと距離を置いているように見えるが、
やはりGPUの代替えとして使う限りにおいて、4要素のpixel/vertex, 16要素のtransform行列
あたりの処理の考えはこれまでのGPUからあまり変わってないように見える。

>>97>>98
つまり高級言語ではプログラマはStrandという単位でプログラムを記述する、
それがコンパイラによって最終的にSIMDの1wayに還元されるということ？
その情報のソースはある？

>>100
その4要素がx, y, z, wとして、バラさないといけないケースならしょっちゅうある。

IntelがSSE4でdppsをサポートするまで内積とるのすら
シャッフルが必要だったし。

クォータニオンの回転も並列実行するにはばらさないと無理

>>104
それはCPU側の話だろ。
今は元々GPU側の処理メインの話してるんだが。
Larrabeeがでても今までCPU側がやってたことは当分CPUでやることになるって。

>>105
ならそれがGPU側でできてしまうLarrabeeはゲームにも強いことになるね。

そりゃ一応今までのGPUよりも融通が利くのがLarrabeeなのだから
使いようによっては面白いものが出来るんだろう。でも性能は高くないと思う。
3DゲーのベンチではGPUばかりが注目されているけど、
ベンチではない3DゲーでのCPUの計算量はバカにはならないことは
DirectXでなんかつくったことのあるやつならわかると思う。

>>107
　　-----------------
　　でも性能は高くないと思う。
　　-----------------
これに関してわ、多少なりとも明らかになるのが一年以上先の話す。

Havokみたいな物理演算やるにも、GPUでできないことをCPUにやらすためにいちいちデータ交換するより
GPUだけでやってしまったほうが有利でしょ。サーフェイス作って転送なんて馬鹿らしいことやる必要ない。

>>109
豪華な仕様で高性能という単純な時代わ終わっているす。

nVIDIAもIntelもやろうとしてることは同じ。座標計算などCPUでやってた処理をほぼすべて
GPUでやれるようにする。各社がそれぞれ２大物理演算エンジンを買い取ったのはそのため。

AMDはGPU-CPU間のデータ転送レイテンシを短縮するためにFusion構想を打ち出した。

GPU-CPU間のデータ転送が遅いことがネックってのはどこの会社も認識してるわけだ。

大量のデータ並列化が可能な場合は16個のvertex/pixelで16waySIMDを各要素ごとにそれぞれの要素を入れて、
命令の並びがscalarに見えるように処理するのが一番ALU的に無駄が少ないと思うんだけど。
といってもその辺は自由だからアイデアがあったら各自実装すればいいだけだね。

個人的にはフラグメントシェーダーからフレームバッファとZの参照が可能、A-Buffer実装可能、リアルタイムレイトレに一番近づいてる、
ってだけでも興味がわくけどな。intelならメモリ帯域とキャッシュ周りの性能が足引っ張ることもなさそうな予感がしてる。
唯一ボトルネックになりえるのがテクスチャユニットで、話で聞いた限りでも間違いなく足を引っ張ると思う。

LarrabeeってMCMでうまいこと繋げられるようになってるのかね？なってるならハイエンドも狙えるんじゃないかな。

>>100
> 3Dゲームのグラフィックスの計算で、4要素とかのベクトルデータをバラに考えるケースなんて
あるって。しかもNVIDIAもATiもそれを考えて作ってるでしょ。
NVIDIAはSIMDだろうがなんだろうが全部ばらして独立したスカラプロセッサで処理してるんでしょ？
ATiに関してはR600のISAのドキュメントを読んでごらんよ。

ttp://developer.amd.com/documentation/guides/Pages/default.aspx#open_gpu
R6xx Family Instruction Set Architecture
Figure 4-3. ALU Data Flow

>>100
> 3Dゲームのグラフィックスの計算で、4要素とかのベクトルデータをバラに考えるケースなんて

ぼくちゃんあのね、あれは Data-Parallelism on Larrabee というセクションの記述なの
ちゃんと読もうね

データパラレル的でなくグラフィックスをやりたいのなら、団子と一緒に頑張ってくれ

Larrabeeでハイエンドの性能はねらえないでしょ。
性能って速度のことをいってるわけだけど。
LarrabeeってLarrabeeにしか容易にできなさそうなことをやればGPUよりも速くて、
従来型のゲームグラフィックスだとローエンドのGPUにも劣るとかそんな感じだと思うけど。
単純に今あるようなベンチでミドル〜ハイエンドのスコアを期待しているなら、
多分Larrabeeがでるときにアンチスレッドでバカ騒ぎする厨房と化すのは目に見えているな。
そもそもLarrabeeって単体よりもCPUにGPUのやっていた仕事を取り込む方向なわけで。

実際DirectX使ってれば内積とか座標回転なんてしょっちゅう使うぞ。
Intelはどっちに転んでもいいようにCPU側のSIMD命令の大幅強化をはじめました。

ID:AU8yjwvo以外はあまり3Dゲーム処理には詳しくないみたいだね。
そもそもstrandという概念をなぜfiberやthreadなどの概念と並べて説明する価値があったのかという話で、
一応>>113とか>>114とかの言いたいことは理解できるけど、軸がぶれすぎ。

団子も嫁って。
内積は一命令で済むぞ。

GPU自体がDXと共に途上過程にあるため
既存の概念でパフォーマンス云々言っても仕方ない気もするが
なんせ登場まで最低でも一年以上もあるのだし

GPUの構造も現在よりもDX11向けに変更されて
ある程度GPGPU向けに最適化される可能性もあるわけだし
いずれにしろ、楽しみではあるね

現存するGPUでは、たとえばDX10にいち早く対応したnvidiaよりも
さらにDX10に最適化した仕様で、GSの高パフォーマンスを誇ったATIだが
そのGSのパフォーマンスを、S3（のローエンド）がさらに超えてしまう場面があるし
（物量がものを言うものは除く）

ttp://jp.youtube.com/watch?v=ruLzQmNokXU
ここの動画(DXSDKサンプル)だと、radeon HD4870が88?fps位でHD2600proが23fps
440GTXが50fpsとなっているようだ（なんで440だけ音楽違うんだよ）
うちの3870と4670じゃ45-48fps位だから、どんな構造になってんのかねChromeは

理論パフォーマンスでは劣っても、構造がそういった世代向けに最適化されている場合
他社のハイエンドGPUすら凌いでしまう場合は、ヒョットシタラあるかもね
（ただし、それより古い世代のパフォーマンスは知りませんよ）

>>118
知ってるよ。内積命令なんて初歩の初歩だもんな。

クォータニオンは？
Intelもなかなか対応してくれないんだよね。

ちなみに計算幾何学の基礎がないやつが3Dゲームを作ると、
いちいち個々の要素を1次元配列にコピーして取り出してみたりとか
無駄なことをやってくれる。
同人ゲーまでは許されるけど、さすがに洋ゲーの主流ではこんなコードは書いてないと思う。

クォータニオン扱ってる大学少ないのが嘆かわしい。
D3DXでサポートされてから専門学校ではチョコチョコ始まったのかな？
回転マトリクスなんかよりよっぽどスマートなんだがなぁ

>>117
君はゲーム以外のことを知らないし、視野も狭すぎる
(ゲームのことも怪しいが)

しばらくROMれば？

いや、視野がせまいのはフェンス君の方だと思うよ。
なんでもかんでもアーキテクチャの歴史と結びつけないで欲しい。
strandは20年前からある用語だとか、
Data-Parallelism on Larrabeeってところにかいてある。
それは理解できるんだが、LarrabeeをGPUとして使用したときに
strandという単位になんの意味があるの?っていうところが発端なんだけど。
で、Larrabeeは従来型のGPUより柔軟性があるから云々という話をしてる。

しかし、ほとんど正解なのに、なんで理解できんのかな
よりにもよってMACオタは正しく理解しているし…
文面だけ読めば理解できると思うんだが、余計な思い込みが邪魔してるんかね

>>115
> そもそもLarrabeeって単体よりもCPUにGPUのやっていた仕事を取り込む方向なわけで。

Larrabeeに取り込むのはCPUのSIMD命令に取り込むのと同義だぜ。
Intelの最終構想はあくまでこれだもんね。

http://pc.watch.impress.co.jp/docs/2004/1228/kaigai02l.gif



このへんではLarrabeeはハッキリと「IA++」という呼び方をしている。
http://www.custompc.co.uk/images/slideshow/84261

「IA++」は全x86のヘテロジニアスマルチコア構想を打ち出したときにゲルたんが言ったスモールコアの呼称と同じ。

>>124
> それは理解できるんだが、LarrabeeをGPUとして使用したときに
> strandという単位になんの意味があるの?っていうところが発端なんだけど。

実体としてFiberにまとめられてしまったイメージしか湧かないということだろうけど
プログラミングモデルに意味を見出せないのなら、それまでだね
いくら説明しても無駄だし、君も永遠に理解できない

逆にGPUとして使ったとき以外にStrandに意味はない。
C/C++で使う場合はただの512bitのSIMDユニットの載ってるマルチコアCPUだ。

>>127
全然理解できん。俺がなんか極端な勘違いしているとかなら別だが、
Larrabeeも結局スタートラインは今のGPUが処理しているゲームグラフィックスと
同じ内容を扱うことからはじまるんだが。
Larrabeeの提唱する新しいプログラミングモデルが効果を発揮するのは、
従来型のGPU処理から離れていく未来の話でしょ。
その上でstrandはこう使えるというのなら意味はあるけど。
何が理解できていないのでしょうか?

>>129
　　------------------
　　何が理解できていないのでしょうか?
　　------------------
理解できていないとわ思わないすけど、有体に言えばStrandに関してわ気にする必要が無いす。
グラフィックプログラマわ、個々のピクセルなりバーテックスなり、ポリゴンなりに適用する
プログラムを書けば良いす。

それを誰かが対象物全てに適用するようにファイバなりStrandなりに展開してくれる訳すけど、
その世界わ数学的な処理とわ別に汚い世界す。

なんとなくわかってきた。
俺はどっちかっていうと、Larrabeeの命令セットはSSEが長くなっただけみたいな仕様で
最終的な処理は従来のSIMDをグラフィックスの計算に適用するときの扱いと大して変わらないと思ってるんだけど。
そこまでばらばらにStrandには展開されないと思ってる。
Intelの資料にはFiberがGPUのShaderに相当すると書いてあるから、柔軟にスケジュールされるのはFiberの方だと思うが。

ちなみに、コレわ当人が理解していない場合の典型的反応す。
>>127
　　---------------------
　　いくら説明しても無駄だし、君も永遠に理解できない
　　---------------------
通常の返答わ、「済みません。判ってるつもりだったんだけど、説明できるほど詳しくなかった。」じゃ
ないすかね(笑)

>>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

ミス。PV?とPS?は全部-2してくれ。ずれちゃった。

>>132
また都合のいい所だけ引用してイチャモンつけるんだから

正しくはこう
> プログラミングモデルに意味を見出せないのなら、それまでだね
> いくら説明しても無駄だし、君も永遠に理解できない

PXはCore 2 Duo E8500よりも優秀

Xbox 360のCPUは、Wii と同様に PowerPC をベースにしたプロセッサだが、
3コアで動作クロック3.2GHz を内蔵する。同 CPU は、並列処理においてIntelのコンシューマー向け CPU で最速の
Core 2 Duo E8500（2コア／3.16GHz）を超える性能を持つ

>>135
捨て台詞にまで文句を付けられると出てきちゃうすね(笑)
Larrabeeのプログラミングモデルの話題に参加している段階で、
　　----------------------
　　プログラミングモデルに意味を見出せない
　　----------------------
ってのが当てはまらないのわ自明す。

>>133
それはAMDATIのshader実装はこうなっていますと説明してるだけ。
nVIDIAやATIもGPGPU的な進化をしているので、いままでより柔軟性がある実装にかわってきていることは不思議ではない。
おれは従来の3Dゲー処理でわざわざ1要素の例を一度抽出してしまった方が都合がよい処理は殆どないといってるの。
ATIやnVIDIAもHPCとか従来の処理にとらわれない用途を模索した結果の実装だとおもうけど。

strandってインテルが現在実装している16waySIMDの性能を引き出すDXとOGLの実行レイヤーを解説するのに使ってるだけでしょ？
実際セミナーではstrandやfiberについての解説がなくて、16waySIMDについて既存のハードウェアに照らし合わせて、
4要素以下ののベクトルに対して処理するとき無駄が多すぎる！みたいな勘違い(？)をした人が結構いたみたい。
このハードウェアはintelが提供するDXレイヤーを使わずに独自の実装を許容するわけで、
その場合strandの概念に縛られる必要はまったくない。
16waySIMD、4H/Wスレッド、scatter&gatherと自由なswizzleを使えるメモリアクセスと読み書きが可能なL1/L2キャッシュを使って
好きにプログラムすればいい。当然BinningもFiberも必須ではない。

ただFiberは性能を引き出す上で避けては通れないかなと思うけど。

>>139
おもしれーｗｗｗ
だが実際は制約は同じっていう。

ただ、Fiber相当のことはネイティブやる場合、ただのソフトパイプライニングでしかない。まじで。

>>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で彼なりに訂正したとおれは理解している。)

>>141
? Strand: a program invocation that runs in one SIMD lane
1つのSIMD lane(==32bit scalar値)に対する呼び出し = Strand
Strandはdataそのものではない

Strandをどれだけ有効活用できるかはRuntimeばかりではなく、
Larrabeeの命令セットに深く依存してる。
IntelがStrandという概念を持ちだしている限り、
多分LarrabeeのISAや回路実装はStrandをうまく扱えるようにつくってある。
ID:AU8yjwvoのいうとおり、プログラマ次第で何でもできるといえばそうなのかもしれないが、
実際は性能が出る範疇でしか自由に出来ないから手法はある程度決まってくるかと。
本当につかうかわからないもののための万能なISAや万能な回路実装は自分の首を絞めるだけだから。

>>142
では例えばshaderで3要素ベクトルの内積があったとして
なにがstrandになるの？

>>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がベストということになるね。

いや、ランタイムにはstrandという実体は存在しないんだって
スケジューリングの最小単位がfiberでしょ

>>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つのレジスタ使ってる場合もある。

>>144
その回答は俺よりも他の連中が得意なんじゃないの?
俺は一貫して、Strandという概念はLarrabeeを従来のGPU用途以外にも展開できることを想定して
用意した概念であって、従来の3Dゲームグラフィックス用途に対してはあまり意味のない
概念だと思っているから。その点では君とはかなり共通した認識みたいだが。

> kernel void hoge(float4 A<>, float4 B<>, out float4 C<>)

<>を見るとメタプログラミングの変態の血が騒ぐんだぜ

> スレッド1　■■■■■■■■ファイバー１[0-15]
> スレッド2　　 ■■■■■■■■ファイバー１[16-31]

Fiberはこんなふうにスレッドに跨がらねーの
どうして皆こう思い込みが激しいんだ

>>146
ランタイムでスケジューリングするときにstrandという概念があって
最終的なnativeコードでは実体がないとおもってたが違うのか。

>>150
思い込みが激しい奴だな。スレッドに完全従属である必要はない。

>>147
この例みたいなArray of Structuresじゃなくて、Structure of ArraysなのがLarrabeeのData-parallelism

どうしてもAoSでやりたきゃTask-level Parallelismというモデルも用意されているから、そっちを使いな

ファイバーはStrand数に応じてスレッドで分割実行される。
これを否定するのはAtomのlfenceはNOPじゃない！なみの思い込みでしかない。

なぜ「フェンス君」なんて言われてるかわかるだろ？
ご自分が思い込みで壮大な誤爆をしたの忘れた？

>>144
1つの3要素ベクトルの内積を計算するプログラムが1strand

4スレッドでファイバーを水平分割して実行するモデルの何が合理的かって
同じ命令列を実行するだけでいいので命令キャッシュが節約できる。
レイテンシを埋めるためのレジスタも節約できる。

縦割りだとどうしてもコードサイズ・レジスタ数に無駄が生じるからな。

フェンス君の言っていることがわからん。
SoAだったら外積のときはStrandはどうなるやら?

>>154
1. AtomのlfenceはNOP　　　　　　　　　　　　　←団子の主張
2. AtomのlfenceはNOPかどうか不明　　　　　←おれの主張
3. AtomのlfenceはNOPではない

団子は論理学の素養がないので、2.の選択肢があることを理解できない

そういうわけで何回おれが訂正しても、おれは3.だと主張している

まさか内積と外積のときでいちいちデータを並び替えるのか?
どっとも3Dゲーでは頻発だが。
無知な俺におしえてたもれ。

>>153
俺は実際に「3Dゲー処理」とやらで4要素がバラけるのはよくあることだと言う例を
>>138に対して示してるんであって、Larrabeeがどうこうってのは知らないんだが。

>>158
お前は分析すらしてないだろｗｗ
妄想でものを言うな

>>160
俺(>>138)は>>138に書いているとおり、
1要素に対する操作(=Strand)をわざわざ抽出してメリットがあることは殆どない
といっているだけで、実際GPUで計算されるときにばらけるとかそういう話はしてないんだが。
そりゃGPUの実装の問題でしかない。

>>159
そうだよ。しょっちゅう並び替えるよ。

じゃあ従来の3Dゲー処理では使えないモデルだね。
並び替えで時間をくわれて話にならない。
やっぱHPC向けなんだろ。

Fiberの切り替えって単純に避けられないデータハザードとかテクスチャの読み込み待ちなんかで
どうしてもALUが遊ぶ場合に例のドキュメントの手順を踏んでパイプライン埋めますってだけでは？
Fiber切り替えはHWスレッドの切り替えと違ってノーペナルティでは出来ないとすると、
どうしようもないとき以外はFiberのスイッチはしないと思うんだけど。

>>165
x86コードに落とし込んだときにファイバーの「スイッチ」なんてものは存在しないの

ソフトパイプライニングして交互に実行するだけ。
ただアーキテクチャレジスタが少ないのでインターリーブは最小限にしたほうがいい。

>>165
正解
ファイバーの切り替えは静的に見積りができるレイテンシーの隠蔽に使う
コンテクストスイッチと見積ったレイテンシーの有利なほうを選べるでしょ

ただし、コンテクストスイッチのペナルティはレイテンシーに隠れるけどね

ファイバーのインターリーブも隠れるわボケ

>>162
だからちゃんと例示したものは読んで下さいよ。
HDRエンコードどかデコードとかはバラけるんですけど。
ほかにもクックトランス反射はベクトル演算なんて4回ほどの
内積と1回のスカラ倍で、後は全部スカラ演算だし。
Larrabee云々の話は知らんがな。

>>166
インテルの資料にファイバーはコルーチンだって書いているのに、どうしてそう強情をはれるんだ

>>170
抽象的な概念に踊らされすぎです。
コンパイル時に1つの直列なコードに変換されます。

x86レベルでも本当にコルーチンとして展開されてると思うのか？
call/retのクロック数考えてみろよ。レイテンシの隠蔽以前の問題だから。

> call/retのクロック数考えてみろよ。レイテンシの隠蔽以前の問題だから。

call/retって何？

？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

団子よ、お前が妄想を書き散らすのは勘弁してやるが
せめてインテルの資料は尊重してくれ

知らないならいいよ。

ちなみに今のIntelコンパイラはインライン展開可能かつ並列実行可能な関数は展開して
同じ命令列の中でインターリーブして実行することもできます。
ためしにアセンブリの出力みてみましょう。

静的コンパイルだろうと実行時コンパイルだろうとやることは変わらない。
静的の方がやれることは多いけど

>>155
> >>144
> 1つの3要素ベクトルの内積を計算するプログラムが1strand

では積の部分を3wayで一気に計算せずに1wayだけ使って
スカラー的に1stepづつ計算するわけ？
(で16個の内積を並列に計算することで16wayを埋めると？)

>>173
あのさー、それ真の意味でタスク切替。

ファイバーを交互実行する仕組みでのインターリーブとはまったく別物。

>>169
それを1スカラ要素に着目するとどうエレガントなコードに変身するのか説明してくれよ。
お前だけ全然別の話してるぞ。

>>178
そりゃ違う話してるよ。>>100への反論続けてるのなんて俺だけでしょ。

>4要素とかのベクトルデータをバラに考えるケースなんて殆ど存在しない
この部分ってのは1要素に対する1連の操作を抽出してもメリットは殆ど内って意味。
キミが書いているのは全然違う話だって。レジスタやALUなんて今の話に関係ねーよ。

>>177
？Fiber switch on texture request submission

>>176
概念的にはだいたいその通り

4要素ベクトルを処理するのが、strand
4要素ベクトルのベクトルを処理するのが、fiber

で、たとえば内積に続いて外積を計算するときは
SoAではどうするの? >ID:sZHTe2uz

>>181


> ？Fiber switch on texture request submission

テクスチャリクエスト

どこにリクエストする？
メモリだろ？

その間に別の処理をやってしまおうってだけ。
レジスタ退避復帰が伴うので普通のOSのコンテクストスイッチと同じだよ。

レジスタを二重に持つことでレジスタ退避・復帰を伴わずにやってしまうのがItanium2のCGMT

しかしLarrabeeの場合はレジスタファイルを多重に持つのは既にFGMTでやってしまってるので
あまりリソースを取れない。だから退避が必要なんだ。
1スレッドあたりのレジスタ数がそんなに多くないので退避してしまっても
たいしたペナルティにならない。逆にね。

外積のあと内積だな。
SoA的にはオペランドを縦割りだあらかじめ全部抽出しといて
一気にかけ算だけバーっとかでやるとかになるんだろうけど。

>>180
> この部分ってのは1要素に対する1連の操作を抽出してもメリットは殆ど内って意味。
実装の部分ではあるんじゃない？
GeForceは抽出してるわけじゃないけど実際1要素ごとにばらばらにして演算するわけだし。
と思ってるから今までISAや実装の話と、実際のエフェクトの話をしてた。
スレの流れから逸脱してるのはわかってるし団子叩きの邪魔になってるのもわかるんだけど、
まあ許しておくれ。

今1要素ごとにばらばらにするってことが問題なんじゃなくて、
ある1要素に注目してそれに対する操作という考えで、
コードを書くor自動でスケジュールすることに意味があるのかという話。
同じところに積和を何百万、何億回とひたすら計算を繰り返すジャンルなら理解できるが、
3Dゲーみたいにころころ計算内容がリアルタイムにころころかわるジャンルには向いてないと思う。
レイトレーシングのコードはよくしらないからわからん。

>>188の書き込み内容は微妙だがまあいいや。

Strandはベクトル演算の1ALU OPの複合化したやつとでも思えばいいのかな
ベクトルと同様に、Fiberにまとめるのをコンパイラやランタイム任せにすれば、境界条件のマスクを考えなくてもいい

ただし、アーキテクチャ上からも逐次方向の局所性を利用しないと性能がでないので、純粋なベクトルモデルではなく、
Strandの導入になったと

おれは今日の議論でLarrabee(のD3D実装は)
shader上のベクトル演算も一旦スカラーに展開して、
それを並列に並べてベクトル演算器に流すと理解した。
つまりG80のさらにその先を行くわけか。
ステップ数は増えるが、確かに並列度は高くなって演算器を有効に
使えるのかもしれない。
しかし結果トータルでパフォーマンスはあがるのか？
分岐やテクスチャフェッチはどうなるのか？
そのあたりまだよくわからない部分はある。
レスくれた皆サンキュー、寝る。

なんだか散々だな。
結局団子の1ファイバ 4スレッドの解釈は間違いだったとことでいいんだろ。
腹切りよろしく >> 団子
そして俺は寝る。

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

これならマトリクス演算も高速に出来るってわけだ。

>>192
はい？

散々言ってるけどハードウェアスレッドとソフトウェアスレッドの意味を混同してね？

そこで説明されてる「ファイバースイッチ」そのものは普通のOSでのコンテクストスイッチと同じこと
何百クロックも何千クロックも待たされるからこその。

16ビット時代はフロッピーディスク初期化中に他の作業できなかったろ？
プリエンプションでフロッピー初期化中でも別の作業ができるようになった。
アレと同じ理屈

命令間のレイテンシを埋めるためのインターリーブはまた別個で必要

>>193
任意の要素をゼロクリアできる分だけ
32bit要素の並び替えに関してはAltiVecのvpermより使いやすいってことかいな

>>196
そう、抽出用のパターンテーブルが1つで済む。
AltiVecは3つ目のオペレーションにvpermを使うにせよvselに使うにせよ
もう一個ビットパターンを用意しないといけない。

同じ目的の命令はAMD SSE5にもpermpsというのがあるが
こっちはAltiVecの劣化版に毛が生えたようなの。

で、フェンス君の言ってたスレッドよりファイバを使えのなぞ発言ってさ

テクスチャフィルみたいな待ち時間が多い処理は
ハードウェアスレッド切替を使うんじゃなくてファイバコンテクストそのものを退避して
別のコンテクストに切り替えろ

ってこと？
なら納得。


CPUとして使う場合でテクスチャフィルなんて使うのか甚だ疑問だが

>>196
　　--------------------
　　任意の要素をゼロクリアできる分だけ
　　32bit要素の並び替えに関してはAltiVecのvpermより使いやすいってことかいな
　　--------------------
CELl SPEのShuffle Byte命令も任意要素を0, 0xFF, 0x80に設定できるす。

>>198
　　-----------------
　　テクスチャフィルみたいな待ち時間が多い処理は
　　ハードウェアスレッド切替を使うんじゃなくてファイバコンテクストそのものを退避して
　　別のコンテクストに切り替えろ
　　-----------------
レイテンシが不定な処理わ、データが来たところで自動的に再開できるSMTを利用するのが得策す。

ところで、この謎発言わ撤回したすか？fiberわSMTスレッドの上位の単位で無いし、「4つ」という
制限も無いことわ明らかにされたかと思うす。
　　==================
　　847 名前：,,・´∀`・,,）っ-○●◎ 投稿日：2008/10/05(日) 00:21:59 ID:PiRb9Agc
　　　　[略]
　　　　LarrabeeでいうところのFiberは同じ1コアで動かすべき4つまでのスレッドを纏めたものにすぎない。
　　==================

それ全然vpermil2psより優位な要素じゃないんですけど。

vpermil2ps/vpermil2pdでは、imm8[1:0] で指定する2ビット値によって、第3ソースで指定した
パターンのうち、最上位ビットが立ってるほうをゼロクリアするか、あるいは立ってないほう
をクリアするか選択できる。
シミュレータで動かした限りにおいてもSPEのアレよりだいぶ便利だ

>>199
ほんとだ。確かに要素指定には5bitしか使わないから
残りの3bitを使えばフォーマットを変えずに拡張できるね。

でも4ベクトルから任意の要素を取り出して並べ替えようとすると、
やっぱり2つ制御ベクトルが要るね。2ベクトルだと1つで済むけど。
このあたりをAVXはimmidiateを使ってうまくやってる感じ。32bit以下には使えないけどw

SSE5のも見てみたが、こっちは0以外にもセットできるけど
やっぱり4ベクトルから取り出そうとすると制御ベクトルが2個要るのは同じだな

おっとかぶったw

>>200
何が？

で、ファイバーのスイッチは普通のOSにおけるプロセスを切り替える仕組みと何が違うのかな？
プロセスには（ソフトウェア）スレッドが従属するが。

>>204
　　-----------------
　　普通のOSにおけるプロセスを切り替える仕組み
　　-----------------
「普通のOS」というのがWindowsやLinux, Mac OS Xのような用途のOSを意味するなら、ページテーブル
の切り替え等、はるかに複雑な処理を必要とするす。
ファイバのスイッチと比較できるのわ、関数呼び出し程度でわ？

XSAVE/XRESTORで全部退避復帰する必要があるんですけど
関数呼び出しで退避が必要なレジスタは一部です

>>201-202
SPE ISA、VMX-128の改善点、反省点を含めた新SIMD ISAわVSXとしてPOWER7に実装される
予定す。Altivecの正統進化がどのようなものになるか、楽しみにして欲しいす。

>>206
　　----------------
　　関数呼び出しで退避が必要なレジスタは一部です
　　----------------
Larrabeeのファイバのスイッチも退避レジスタわ使用している分だけと書いてあるす。
　　================
　　- Saves "live" registers [""わ、MACオタ注]
　　================

ところで、後藤氏がLNIと将来のx86拡張についての記事を書いているすよ。
Gelsinger氏とのインタビューを交えて。
http://pc.watch.impress.co.jp/docs/2008/1006/kaigai470.htm

まあ、使ってないレジスタは退避しないという方針に基づいても、

汎用レジスタ16本とSIMDレジスタ16本、マスクレジスタ、EFLAGSにMXCSRなど
諸々は基本的に退避しないといけないな。
FP/MMレジスタの退避はまあ使わないなら必要なさそうだな、

関数コールとは違ってABIを規定できない筈だし（するのか？）

>>209
だから言ったとおりじゃん。
Larrabeeのコアはヘテロジニアスマルチコアにおける「IA++」と同じものだって。

ちなみにゲルたんがいってることは4年前に後藤自身が解説したこととなんら変わってない。
SSEと共存できないだとか、いや、共存できるだとか、後藤が一人で混乱してただけで
Intelは一貫してたわけだ。

>>210
なんとなく見積もりが違う気がするすけど。。。
　　-----------------
　　関数コールとは違ってABIを規定できない筈だし（するのか？）
　　-----------------
Larrabeeわ目的が異なるスレッド(orタスク)が併走する設計になっていないす。
(例えば4つのSMTわMMUを共有するため、スレッド間のメモリ空間の独立性の自由度わ低い)

演算リソースわユーザーコードで占有され、タスクのスケジューリングも自前で行うすから、
ABIも必須でないす。こういう点でもCELL SPEと各コアの使い方わ近いかと思われるす。

>>211
記事でわAVXが妙に無視され気味な訳すけど、その辺気にならないすか？
スケジュール通りなら、2010より数年間AVXとLNIが並立するというISAの分離が発生するすけど。。。

>>212で少し記述間違えたす。
　誤: 4つのSMTわMMUを共有するため
　正: 4つのSMTわTLBを共有するため

> つまり、256-bitと512-bitのずれは、時間軸上のずれに過ぎず、
> PC&サーバー向けCPUもいつかは追いつくことになる。

さて、問題あるかね？

LarrabeeでSSE/AVXをサポートしないとも言ってない。
特にAVXについては、LNIでVEXエンコーディングを用いる以上
デコードできてしかるべきだし、やれるんじゃないの？
まあ「絶対サポートする」と強弁する気はないが。



後藤はLNIがVEXエンコーディングって事実はまだ把握してないようだが
なんとなくは気づいてるような。「命令は固定長にするのが望ましい」とかな。

>>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.
　　--------------------------

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では無効にするとかそういう類のものになりそうだが

後半書き直し

最初のPentium IIIからPentium 4においてSSEが64bit SIMD×2で実装されてたように
Sandy Bridgeでも256bit AVXは内部的に128bit命令を2個実行するだけの実装にとどまってる。

LNIでもAESくらいならサポートしない理由はある。テーブルが複雑だし。
まあ、あれはAVXを実装したCPUですら無条件でサポートされるものではないことは
マニュアルにて示唆されてるが。
汎用CPUではSSE4.1を無効にしたWolfdaleコアがあるように、マーケティング上の理由で
ローエンドCPUでは無効にするとかそういう類のものになりそうだが

>>218
　　-------------------
　　Sandy Bridgeでも256bit AVXは内部的に128bit命令を2個実行するだけの実装にとどまってる。
　　-------------------
また根拠の無い話を(笑)

反証にわソースがあって、"Terra Terra Terra"プレゼンでわ、Gesher (Sandy Bridge)のコアあたり
のDP Flops/cycle/core=7とあるす。8の誤植かどうかわ別にして、「サイクルあたり4-wide x 2 (積和)」
じゃないと到達できない数字す。

古い記事見たら、LarrabeeにVEX使うことは後藤は既に気づいてた。
http://pc.watch.impress.co.jp/docs/2008/0407/kaigai434.htm

> また、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方式であるべきだと説いているようだ。

http://pc.watch.impress.co.jp/docs/2008/0811/kaigai458.htm
> 　Intelは、Larrabee拡張命令のフォーマットの詳細については明らかにしてない。
> しかし、想定できる点がいくつかある。まず、命令フォーマットはデコードしやすいものでなければ
> ならない。x86命令のデコード時の複雑さの多くは、x86命令が可変長であることに起因している。
> この問題を軽減するためには、Larrabee拡張命令を、固定長にすることが望ましいと推定される。


この記事で
> MMX Pentium以降のMMX/SSE系の拡張命令は、サポートしないと推測される。

なんてトンデモなことを言った理由は、むしろVEXプリフィクスの合理性を主張したいからな気がした。
実際には、MMX/SSEが使ってきた2byte Opcode空間はMMX以前から使われてきたしLCP＋2byte Opcodeなんてのはザラ。
SSEの命令フォーマットがデコードできない理由にはならない。「遅い」ならまだわかる。

余談すけど、今回の後藤記事の内容のヒドさに、私わ落胆したす。

かつて後藤氏わ、素朴な質問をぶつけて相手に詳しく語らせることで、自身の素養の無さにも
かかわらず良いインタビューをモノにしていたす。（ちなみに、逆のスタイルが本田雅一氏で、
話を聞くより自分の意見を売り込もうとしてるんじゃ無いかと思われるようなやり方す。)

ところが今回の記事、まるで自分の憶測の裏付けを必死でGelsinger氏に求めているとしか
思えないような代物す。これでわ記事自体、都合のいい言葉だけを引用しているような
バイアスがかかっている疑念すら出てくるす。

>>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ヲタは。

>>222
何度か書いているすけど、
　　-------------------
　　俺のサイトにも書いている通り
　　-------------------
議論の相手や聴衆が、自分と同じ情報を持っているという思い込みわ、勘弁して欲しいす。

それわそれとして、
　　-------------------
　　128bit FMA＋ 128bit Dot-Productで7でも計算が合う。
　　-------------------
内積のような高級命令ってシングルサイクル・スループットなんすか？

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」というコードネームが消えた今となっては真相は誰も知らないわな。
つーか、あの資料の該当ページを抹消したのにも何かしらロードマップ上の理由があったと思ってるが。

>>224
　　-----------------
　　Gesherも死んでSandy Bridge/IvyBridgeは後釜なんじゃないの？
　　-----------------
思い込みに合わせて現実を改変するのも勘弁して欲しいす。一応風数ソースで。
http://pc.watch.impress.co.jp/docs/2008/0129/kaigai412.htm
　　=================
　　Sandy Bridgeは、もともとはヘブライ語のコードネーム「Gesher(ゲッシャ)」で呼ばれていた。
　　GesherからSandy Bridgeへと変わったのは、技術的な内容の変化があったからではなく、
　　名称だけだという。
　　=================
http://www.atmarkit.co.jp/fsys/kaisetsu/087idfspring2007/idfspring2007_03.html
　　=================
　　32nmプロセスの2世代目（新しいマイクロアーキテクチャを採用）の開発コード名が従来の
　　Gesher（ゲッシャー）からSandy Bridge（サンディ・ブリッジ）に変更されたが、こうしたコード名の
　　変更は「靴下を替えるように、頻繁にあること」だという。
　　=================
もう少し詳しい理由わ、こちら。
http://www.theregister.co.uk/2007/04/17/intel_gesher_sandybridge/
　　=================
　　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.
　　=================

で、7は誤植で8だという根拠は？
7は誤植だという一方で8が真実だというのはずいぶん都合がいい考え方だなぁ
4GHzで28GFLOPSとも書いてあったぞ。

http://xtreview.com /images/davis.pdf

これだろ？


先に出るLarrabeeのベクトル長が8か16かも曖昧な資料が根拠になにを妄想してるのかなFUCKくんは

FMAがSandy Bridgeで実装されないことそのものがロードマップの修正だと思わんかね？

Intelの*mmintrin.hでサポートされる組み込み関数の使える命令がCPU世代をまたがったことは一度も無い。

Sandy Bridge世代ではいまだに内部128bitである根拠

◎AVXではメモリアドレッシングで指定されたソースに対しミスアラインロードを許容するが、
　SIMDユニットがネイティブで256ビットをサポートするとすれば、アラインメント補正処理を
　ユーザーに開放したvpalignrの256bit版がないのはおかしい。
　シフト・ローテート処理が128ビットのままでは、スループット的にアンバランスが生じる。

◎256bit化の対象となってる浮動小数演算は、SIMD演算ユニットが内部128bitのまま256ビット版を使う
　・命令レイテンシ隠蔽のため引き伸ばすだけでも実効性能は伸ばせる。
　・SandyBridge世代においてもなお16バイト/clkまでしかないらしい命令フェッチ帯域の節約になる。


まあ俺はどっちでもいいよ。
内部256bitといい続けることで恥をかくのはお前だけだから。

>>229
前者わ興味深い指摘だと思うす。今後わ、最初にこういう論拠を示してから自説を展開するように
お勧めしたいモノす。
後者に関してわ、何度も現実に裏切られているのでわ？

>>227
少しだけ補足す。
　　-----------------
　　先に出るLarrabeeのベクトル長が8か16かも曖昧な資料
　　-----------------
"Terra Terra Terra"のp.16のブロック図に"SIMD-16"とあることから、この時点で16(512-bit)-wideわ
確定していたことが判るす。従ってDP flopsの未確定部分わ、この時点で積和命令を実装するか
否かが確定していなかったことを示すす。

じゃあ、palignr の256bit版が存在しないのを「誤植」だとでも思っておきなよ。
VEX.L=1にすると未定義例外が出るってハッキリ書いてあるんだがな。

たとえばAltiVecｔのvpermが先頭64ビットまでしか作用しなかったらきっと
理不尽だと思うだろうけどそれと似たようなもんだよ。

全部誤植でAVXのベクタ長は1024ビットかもしれないよ
極論言うとMACヲタの妄想はそういうことだ

実物が無い以上
全部妄想です

xmmレジスタが登場してから演算器が128ビットになるまでを考えると128*2の可能性は大きいな。
同業者の状況を見るに、急いで新昨日で巻き返さないといけないなんて状態でもないし。

7DPで28GFLOP資料が間違ってるという一方でそれを根拠に

7DPで28GFLOPS＠4GHzという資料が数字が間違ってるという一方で
それが根拠にネイティブ256bitだというのは苦しいわな。
256bitでない根拠にならなりうるが。

間違ってると言った数字を根拠にする理屈はありえない。

ちなみに積和＋内積で7DPを満たせるってのはム板でも議論されてた。

64bit SIMDではあるがK7ではE3DNow!によって内積をスループット1クロックで行えていた。
別に困難でもないんじゃないの？パイプライン段数増えていいなら。

http://software.intel.com/en-us/forums/intel-avx-and-cpu-instructions/topic/58076
もう既に。中の人に近いところではAVXのパフォーマンスについて議論がなされてるよ。

AVX-256での行列積のスループットはSSE2の1.4〜1.6倍程度だそうだ。
ざっと概算しても新命令のvpermil2psの効果分＋3オペランド数増加分程度の
スループット向上しか得られてない。
これは内部128ビットのままである証拠にならないかな？

MACヲタも無根拠な256ビット幻想なんて捨てて
Intel謹製のパイプラインシミュレータでスループットの検証してみれば？

むしろSandyBridgeって乗算命令って2ポートで発行できるようになってないか？
FMA＋DotProductで7DPを実現するスタイルだと、乗算だけに限っては既存のCore 2ファミリの
2つの浮動小数ユニットのどちらでも2DP/4SPの乗算が可能になる。

まあ、加減算とは排他になるが。

でだ

FMUL/FADDとある２つの演算機の両方に乗算・加減算を実装してどちらでも加算・乗算を発行できる
ような形にすれば、既存のSSEコードでも若干性能向上が期待できる。
それに、新命令のFMAのパフォーマンスという観点でも1つの実行ポートに両方の演算ユニットが
ぶら下がってるほうが性能を出しやすい。

256bitでのパフォーマンスが伸びてないというより、レガシーを含めた128bit SIMDでの
パフォーマンスを若干ながらも伸ばすアプローチを採るのはそれなりに意味はある。


いじょ。

フォローしておくと256bit SIMDでも相当速いよ。シミュレーションの通りなら
今のCore 2と比べてざっと2倍ってのは嘘じゃない。
単に256bitじゃないと恩恵が無い実装にはしなかっただけでしょ。

とりあえず、この手の話で
団子 >>> MACオタ
なのはよくわかった。
今日の団子はいつもよりかなりまともな理屈をならべているな。

つーか、団子は正直、拡張命令ネタだけでいい。他はいらん。

対戦成績表'08
ﾅﾏｴ 10/6
---------------------------------------------------------------------
団子　○
オタ　●

10/6 AVXの実装など

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を整理したい。

larrabeeってDX11世代のGPUやOpenCLで使った場合のGPUに対して
余程のパフォーマンス的アドバンテージが無い限り
結局ニッチな仕様のGPUで終わるんじゃないのかい？

ところがCPUに内蔵されるようになる予定だから話はちょっとこじれる。

それはAMDがやろうとしてる事と
何が違うの

どうせCPUに内蔵されるから、単体カードとしてのLarrabeeはぼろぼろでも、
CPUに内蔵されたら、今と同じでシェアだけは高い可能性があるってことじゃね？

マリオと抱き合わせでクソゲーを買わされたトラウマが…

>>247
ポイントは全部x86。
同じ命令セットで汎用スカラ処理が得意な大きなコアとSIMDだけは得意な特化型コアが並立する。
で、ワークロードに応じて最適なコアを選んで実行するようになる。

AMDのやろうとしてることの最終構想はCPUのSSE命令をGPUでやること。
現実にはGPUの大量の演算ユニットだけあってもSSE命令の供給が間に合わなければ意味がない。
CPU内蔵のFPUすら、持て余してる時間が多い。
フロントエンドやスケジューラにどれだけトランジスタつぎ込んでるか考えれば
AMDがやろうとしてることがいかに無謀で馬鹿げてるかは。

適切なコアの判断は何処でやるの？

並列計算プログラミングを勉強している者ですが、質問があります。
Dual CoreとQuad CoreのCPUを用いてバックトラッキングの速度計算をやっているのですが、
実際のマルチコア対応演算プログラム（例えば、将棋や囲碁など）だと、
Dual CoreとQuad CoreはSingle Coreの物と比べてどのような処理をやっているのでしょうか？

>>251
OSのカーネルじゃね？
XP/VistaのカーネルはRDPMCでプロファイルとってコンテクストの割り当てを最適化する
機構を既に備えている。

現状、SMTで論理プロセッサが複数あるCPUで、同一物理CPUかを判定したり、
メモリ階層を考慮した最適化くらいはOS側でやってくれる。
IntelとMSは共同でメニーコアの研究やってるからなんらかの解決策は出してくるでしょ

ララビーのコア1個1個はOSから
それぞれCPUとして認識されるっての？

GPUではなくずっと先の話だ。

>>252
「バックトラッキング」って言葉の意味がわかってるなら話は単純だが
複数のコアあるなら、その分だけスレッド起こして各枝の探索に割り当てていけばよくね？

IBMがDunnington対抗でPOWER6搭載サーバーのミドル〜ローレンジで搭載コア数を2倍にしたす。
単純にソケット数を2倍にした模様。
http://www-03.ibm.com/press/us/en/pressrelease/25359.wss
　　-------------------
　　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?)」http://pc11.2ch.net/test/read.cgi/jisaku/1178140550/850
「実わ実装密度倍増？」http://pc11.2ch.net/test/read.cgi/jisaku/1214999146/45
ときて、結局POWER6でソケット数倍増という形で実現しているす。POWER6+って順調に遅延しているか、
Dunnington対抗で、製品投入を急いだという感があるす。

ただし、ミドルレンジのPOWER570にもハイエンドと同じPOWER6/5GHzを投入しているすから、搭載
チップ数倍増と合わせて、POWER6自体の歩留まりわ上がっていそうす。POWER6+登場前の在庫
整理の可能性もあるので、POWER6+がいつ登場する(or しない)かわ、注目す。

>>252
枝分岐する探索をthreadに割り当てとかじゃね？
憶測だがｗ

>>250
> で、ワークロードに応じて最適なコアを選んで実行するようになる。
dynamic loadbalancing?
そんなとろいことやってたらﾒﾆｺｱではscalabilityﾎﾞﾛﾎﾞﾛのキｶﾞｽ
これも憶測だがｗ
ねむー仕事でくたくただの介。モヤ済みﾉｼ

>>257の続報すけど、IBMサイトのPower 560 Expressの価格ページで、搭載プロセッサが
"POWER6+"と記されていることが話題になっているす。
http://www-03.ibm.com/systems/power/hardware/560/browse_aix.html
当初予定されていた45nmプロセス製造のPOWER6+によるコア数倍増のロードマップがズレて、
POWER6のままでのコア数倍増製品の投入至ったという推測を裏付けているかと思われるす。

なお、ITJungleのTimothy Prickett Morgan記者がIBMに問い合わせて、実際にわPOWER6の
ままであることを確認したとのことす。
http://www.itjungle.com/tfh/tfh101308-story07.html
　　--------------------
　　I checked with my sources at IBM, and the Power 560 is not based on the Power6+, but rather
　　the existing Power6 chip, which is implemented in 65 nanometer processes.
　　--------------------
IBMサイトのページわ、今後訂正されるかもしれないすけど、当該記事にわスクリーンショットが
掲載されているす。

TechNewsWorldのRoss Mauri (IBM, Power System事業部長)インタビューより、POWER8の仕様
策定が開始されたという話題す。
http://www.technewsworld.com/story/64779.html
　　--------------------
　　"We are working on Power7 and next week I have a meeting to hear about research on
　　Power8," Mauri said. "We're not slowing down."
　　--------------------

NCSAが建設するPOWER7を採用したスーパーコンピュータ"Blue Waters"の水冷技術に
関する記事す。
http://www.techworld.jp/channels/datacenter/102289/
　　---------------------
　　NCSAの代理ディレクター、ロブ・ペニントン（Rob Pennington）氏によれば、水冷方式の大きな
　　アドバンテージは「CPUの高密度実装を可能にすること」であるという。同氏らは、開発中の
　　コンピュータを設置するために、現在NCSAで稼働しているスーパーコンピュータの2倍分の
　　施設を確保している。だが、現行コンピュータのコア数が9,600 基であることを考えれば、同
　　プロジェクトにおいて高密度化がいかに重要な課題であるかがわかる。

　　「水冷方式だからこそ、CPUコアの高密度実装が可能になった。もし、空冷方式でサーバを
　　冷却しようとしていたら、フロア内の空気の流れを確保するために、さまざまな制約が課される
　　ことになっただろう」（Pennington氏）
　　---------------------
前スレに書いたPOWER7に関する情報も参考に。
http://pc11.2ch.net/test/read.cgi/jisaku/1219884494/950
　　=====================
　　開発グループが異なるとわ言え、POWER6で電力効率向上のために一旦あきらめたOoOEを
　　再投入する 技術的裏付けわ謎す。冷却に関してわ水冷技術で先行しているために問題わ
　　無さそうす。
　　=====================

>>254
それは無いと思われ。

http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycore.pdf

論文によればLarrabee上で実行されるプログラムは、
専用コンパイラで生成されなければならないと書かれてるし。
それにシステムコールもLarrabee側では実行されず、
CPU側で動作してるコードに一旦コールバックして実行されるらしい。
(つまり、OSはLarrabee上で動作していない)

既存のアプリを再コンパイルなしで実行出来ないなら別にx86互換でなくてもねぇ。

ｺﾝﾊﾟｲﾗが作り(流用し)やすいのは、一つの大きなﾒﾘｯﾄだろ。
すぐできる。が、しかし…

nVIDIAが「ハイエンドクアッドコアよりデュアルコアにSLIなGPUのほうがエンコ速いよ」
って挑発してる状態だからね。
あくまで継続的に高付加価値のCPUを売っていきたいIntelには、GPUを牽制するのもやっぱり
x86である必然性が出てくる。

・将来のSIMD拡張LNIの先行実装
・トランジスタあたりのスカラ性能もそれなりには出る
・x86最強ｗｗｗｗｗ


つーか実際問題ハイエンドを欲するのはエンコとかゲームとかなわけで、
大量のSIMD演算をこなせるエンジンが必要になる。

CPU側のサブコアではなく敢えてディスクリートGPUとしてのモデルを採ったのは
いろいろな実験を兼ねてるんだと思われ。
というか、CPU側にはまだ汎用コアを詰め込んだ方が良いと判断したんだろう。

むしろx86スカラコアがおまけで主力はSIMDエンジン

んでそいつらのためのGDDR3
ディスクリートしか道が無い

LeadtekのSpursEngine搭載アクセラレータボードは3万だってな
VGA機能のないSIMDアクセラレータですらこの価格だから
VGA機能を兼ねるLarrabeeでもそれなりの値段はしそうだな。

それはどれだけの普及を見込んでるかによるのでは？

SpursEngineはチップの単価が1万円程度だからなぁ。

ハイエンドSIMDアクセラレータになるか、ローエンドGPU扱いされるかは
ソフト次第だと思うよ。

その点においてIntelはしっかりしてると思ってる
少なくともCellみたいに当のSCE自社すらまともなライブラリ作れないような企業より。

Larrabee、試しに買って、お家でもﾌﾟﾁHPCしてみるか、どうするか…
Cellだとｱﾌﾟﾘが完成するまで203高地・死体累類状態を数年続けた後、
ｱﾌﾟﾘが完成して日の目を見る前にﾌｪｰﾄﾞｱｳﾄされちまいそうで
迷わずｽﾙｰしたけれども。

S3もGPGPUに参入したす。
http://www.s3graphics.com/en/technology/gpgpu/
http://drivers.s3graphics.com/en/download/other/S3FotoPro/S3FP_ReleaseNote.htm

IBMの2008Q3会計報告も出ているす。
http://www-03.ibm.com/press/us/en/pressrelease/25530.wss
http://www.itjungle.com/bns/bns101608-story01.html
ハードウェア部門に関してわ、前年同期比10%減の$4.4Bとのことす。
　- z (メインフレーム): 台数ベースで+49%の大幅増加。売上ベースでも+25%
　- p (Unix/Linux): 売上+7% (Power Systems統合後のi-Seriesも含む)
　- i (AS/400): 売上-85%
　- Microelectronics (半導体): -27%

POWER6搭載製品わ、まあまあ好調に見えるす。
ゲーム機用プロセッサの受託設計で大儲けして以来、Microelectronicsの売上わ低下する一方す。
そのうち研究施設だけ残して工場わ売り払われるかもしれないすね。。。

TheINQのCharlie "Groo" Demerjianが最近RWT掲示板に出没しているすけど、彼の書き込みから
興味深い話題をいくつか。
「xbox3 Larrabee採用説」
http://www.realworldtech.com/forums/index.cfm?action=detail&id=93708&threadid=93619&roomid=2
　　-----------------------------
　　Last up, MS is likely to use the API that keeps Larrabee in a box the most.
　　-----------------------------
「Nvidia身売り説」
http://www.realworldtech.com/forums/index.cfm?action=detail&id=93743&threadid=93619&roomid=2
　　-----------------------------
　　My bet is that they won't be an independent company at this time next year.
　　-----------------------------
「Nvidia/VIA交渉」
http://www.realworldtech.com/forums/index.cfm?action=detail&id=93775&threadid=93619&roomid=2
　　-----------------------------
　　It was tried. If you know anything about Jen-Hsun and Wen-Chi, the two together in the
　　same room has all the makings for someone getting stabbed in the eye with the spork
　　that came with lunch.
　　Needless to say, no deal was done, and comedy did ensue.
　　-----------------------------
「既にクロスライセンス締結済みの企業(intelとか。。。)わ無い？」
http://www.realworldtech.com/forums/index.cfm?action=detail&id=93760&threadid=93619&roomid=2
　　-----------------------------
　　Anyone who would be in line to buy them has likely already cross-licensed everything they
　　have, so patents would not likely be an issue.
　　People will be bled off as the writing becomes quite apparent on the wall. Intel is already
　　picking them pretty clean, so what will be left?
　　A good analogy is Transmeta. Lots of bright people, lots of interesting tech, no one bought
　　them. Why? Same real reasons.
　　-----------------------------

>>272
Core2Duo E8400 3.0GHzと430GTでは約2.3倍の差がつきます
もっともCPUはシングルしか使われませんが

ちなみに119枚の2048*1536のjpgを処理した場合
E8400 3.0GHz : 215.744s
同CPU+430GT : 95.398s
------------------------------------
Turion64 1.8GHz : 9.474m(568.44s)
同CPU+440GTX : 179.594s

同様にS3からエンコーダでも提供されれば
VIAプラットフォームにとって強い味方になりそうですね

>>275
＞ E8400 3.0GHz : 215.744s
＞ 同CPU+430GT : 95.398s

＞ Turion64 1.8GHz : 9.474m(568.44s)＞ 同CPU+440GTX : 179.594s

やっぱ同じGPUでもプラットフォームで差がつくんだな。
GPUでできない仕事をCPUにオフロードしてるから当然といえば当然だが。

ということは、よりCPU側に投げる仕事を減らしたのがGPGPU市場を制しうる。

Larrabeeの勝因はここにあるかもな。

もっとも固定機能部分が遊んでたら意味Nothingだが

> Larrabeeの勝因はここにあるかもな。
もう勝ったことになってるよｗ

>>264
既存のコンパイラをある程度流用出来るのは分かるけど、
Larrabee側でシステムコール呼んだらCPU側で実行されるってどうやるんだろ?

システムコールの引数がポインタだと、
�@Larrabee側のコードもCPU側のコードも同じメモリ空間を共有するか
�Aシステムコールごとに決まったサイズ(たいていは構造体)のデータをコピーするかしないと...

�@だと変数にアクセスする度にPCIバス通して通信するわけだし
�AだとWin32での実装が大変そうだ。

公称1TFLOPSとかあるのに、GPGPUとして使ってみるとCPUの良くて数倍程度の性能しか
出せてないのは、実効性能が低いからでは？
キャッシュが小さかったり、演算の小回りが利かなかったり。

>>278
> Larrabee側でシステムコール呼んだらCPU側で実行されるってどうやるんだろ?

っていうかシステムコールをホスト側で処理する必要あるんだっけ？
Larrabee側にもOSを持っててPC上のOSとはメモリ空間は独立なのに

ttp://fah-web.stanford.edu/cgi-bin/main.py?qtype=osstats
さて、何倍でしょう。

>>278
やり方は色々考えられるだろうけれども、
実際にIntelがどうするについては参考文献を読んでから書来たいところ。
読んでいる時間あればだけれども…orz。
パット思いつきで書けばthrouputneckが懸念されるのはread/write システムコールだけ。
でもさ、並列化のセオリーで言えばIOって思いっきりcriticalなんだよねｗ
>>279
数コア程度のCPUの性能分析と同列に考えない方が良いよ。

モデルの大きさが違うんじゃなかったっけ？
キャッシュ（Cellの場合LS)の容量に合わせた小さいモデルを選択してるだけで
それをもって性能比較とするのはどうかなと

だって、PCと同じ大きさのモデルをシミュレーションするのは
性能以前に「無理」なんだろ？

モデルの大きさはCPU>CELL>GPUということだけど、定量的な情報が無い。
クライアントがバージョンアップするたび扱えるモデルも大きくなっているとも言ってる。

今のcore2duo2GHzと母板のその他機能がワンチップで省電力になるのはいつごろだい？

5年後位のCPUのハイエンドって今のよりどれ位性能アップしてるの？

>>280
論文の6.1節
"Two current limitations are
that application system call porting is not supported and the
current driver architecture requires application recompilation."

それから
"Additionally, execution of some
C/C++ standard library functions called from Larrabee application
binaries must be shared with the host operating system.
Specifically file I/O functions such as read/write/open/close, etc.,
are proxied from the Larrabee application binary back to a service
that executes such functions remotely on the host OS."

とのことなので気になってます。

>>282
read/writeもそうだし、スレッド間の協調のためのAPIもホスト側で実行するなら...
この論文には詳しい実装手法は載ってませんでした。
他に論文orドキュメント知ってたら教えてくらはい。

来年のICC11にひょっとしたらLarrabee開発ツールも載っかるかもしれないのでそれまで待ちましょう

>>275に新たにE8400+440GTXを加えて

E8400 3.0GHz : 215.744s
同CPU+430GT : 95.398s
同CPU+440GTX : 88.941s

Load->処理->saveのうちLoad,Saveはどの結果でも同じと仮定し
処理のみの時間を出してみると

x+y=88.941sec
x+1.139y=95.398sec
x+c=215.744sec

x:laod+save時間 y:440gtxの処理時間 z:cpuの処理時間 1.139=1025/900(440SP/430SP)

x=42.488sec
y=46.453sec
z=173.256sec
となり

GPUとCPUでは約3.7倍となる

CPUはシングルスレッドで12gflops、440は65.6gflops
GPUの実行性能としては、マズマズかと

実行中はこんな感じ
ttp://www.nicovideo.jp/watch/sm4987162

>>287
残念ながら詳しい文献は持っていないよ。関係者のﾌﾞﾛｸﾞ
Intel Graphics Jobs - Graphics - The Computer Science Agora
ttps://i2cs.cs.uiuc.edu/display/graphics/2008/04/25/Intel+Graphics+Jobs
の近くにある8月19日のslide
architecture reading group slides -- 19 aug 2008.key
ttps://i2cs.cs.uiuc.edu/download/attachments/10454670/larrabee-aug19-slides.pdf?version=1
の11枚目辺りを見てもIOに関しては
. GPU variant: stdlib I/O proxied by host processor
としか触れられていない。これは多分PCIExpress add-in card形態のものの場合だと思うけど、
PCIｶｰﾄﾞ内のLarabbeeからNorthやSouthにぶら下がったI/Oを(Host CPUと調停しながら)
アクセスする手段は(第三世代になっても)無い？(←知らぬ)か何かにより、Open MP compilerで
compile&linkしたexecutableのhost CPU用binary側にI/Oを代理実行して賄ってもらうん
じゃないかとそれをproxyと書いているんｼﾞｬﾏｲｶと、コレはﾓﾚの予想だけれどもさ。

ちなみにthread同期に関しては同じく11枚目に
on-chip thread synchronization and communication
と書かれていて、これはLarrabee内のcore間の同期でPCIは経由しないものの筈。
逆にLarrabeeとhost CPU間のPCI経由同期もあるはずで、OpenMP compierは
２種類のbinaryを含むececutable内でこの２階層の同期を取り扱えるような
codeを生成するのではないかと、ｺﾚも予想だけれれどもさｗ
ご苦労さんなこったぜ

とうとうGPUでprintfデバッグができる時代が来るのかw

仮にS3がChrome400にExponentialの技術を使ってるとしたら
10年に及ぶ、随分と長い伏線だな

>>290
おぉ、サンクスコ。

>PCIｶｰﾄﾞ内のLarabbeeからNorthやSouthにぶら下がったI/Oを(Host CPUと調停しながら) ...
というか、いわゆるカーネルモードのプログラムは全てCPU側で処理するのでは?
つまり、in/out命令のレベルで調停するのではなく、
read()/write()システムコールの処理を一括してホスト側で処理するのではないかと。
(もちろんLarrabeeを動作させるうえで必要な最小限のカーネルというかファームウェアが特権命令をLarrabee上で提供することはあると思うけど)


また、論文のコピペした部分 ”『現在の』ドライバ設計ではアプリケーションの再コンパイルを要する”とあるので
将来的には再コンパイルは不要となるのではないかと漏れは予想してます。
だとすると、やはりLarrabee上で発行されたint命令を
必要に応じてホスト側のint命令として処理するコードがドライバに組み込まれるのではないかと。


>OpenMP compierは ２種類のbinaryを含むececutable内で
>この２階層の同期を取り扱えるような codeを生成する
OpenMPで自動並列化するときにCPUの演算資源とLarrabeeの演算資源を同時に活用できるってこと?
クレイジーだね!

中文版EngadgetがIDF Taipeiで仕入れたLarrabee情報を掲載しているす。
http://cn.engadget.com/2008/10/20/idf-2008-intel-gpu-larrabee-detail/
　・コア数: 最大32
　・動作クロック: 最大2GHz
　・製造プロセス: 45nm〜32nm
　・今年11月にプロトタイプ登場？

コア数と動作クロックに関してわ、
コア数と動作クロックより最大ピーク性能わ、
　倍精度: 2 [GHz] x 8 [並列] x 2 [積和] x 32 [コア] = 1 [TFlops]
　単精度: 2 [GHz] x 16 [並列] x 2 [積和] x 32 [コア] = 2 [TFlops]
基本的な性能上のターゲットわ、"TFlops on Chip"ということの様す。

>>293
> >OpenMP compierは ２種類のbinaryを含むececutable内で
> >この２階層の同期を取り扱えるような codeを生成する
> OpenMPで自動並列化するときにCPUの演算資源とLarrabeeの演算資源を同時に活用できるってこと?
> クレイジーだね!
OpenMPは演算性能やlatencyに大きな非対称性のあるthreadが混在すると
基本的にloadをbalanceさせ易くないし、PCI経由の同期はそれなりに遅く密接な
同期の間に挟まない方が性能的に有利なので、並列regionに突入するチームを
host CPUとLarabee内のthreadで混成するところまでは、さすがにやらないのでは
ないかと想像して□。
しかし、特定のH/W threadやcoreを固定的に割り付けるaffinity APIをpthreadに拡張し、
OpenMP APIはその上に乗っかるわけだし、host<->Larrabee間のmessage/data passing
protocolは非同期APIもサポートするからCUDAのようにGPUがご多忙中の裏でhost CPU
も一仕事させられる上で必用な仕組みは備わっている。
それがOpenMPのチームを編成するthreadの割付指定拡張の様な??ものなのか、
あるいはCtのみのサポートなのかは今のところ想像の域を出ない。
Ctは非常にダイナミックなのできっと何か仕掛けてくると思う。LLVMの様な仮想命令と
optimizationまで取り入れられる。○○とは役者が違う、もう参ったよって感じ。
しかし、ﾓﾚは何を2chでﾏｼﾞﾚｽしているのやら…

>しかし、ﾓﾚは何を2chでﾏｼﾞﾚｽしているのやら…
いやいや勉強になるわ。

>CUDAのようにGPUがご多忙中の裏でhost CPU も一仕事させられる上で必用な仕組みは備わっている。
うーん、これはこれでCELLみたいにスーパーハカー的なプログラミング作法を要求しそうでやだなぁ。
あっても良いけど、いつの間にか○○しながら××することが性能出す上で当然みたいなことにならないといいね。


>Ctは非常にダイナミックなのできっと何か仕掛けてくると思う。
>LLVMの様な仮想命令とoptimizationまで取り入れられる。
Ctでコーディングしたら、コードの自己書き換えを伴った実行時最適化が掛かるってことでおk?

>>294
サンクスコ。
各x86コアが2GHz動作するってことかな?

>>289
CPU<-->GPU間が遅くて連携は難しいとか言われてたが
Chrome400程度のローエンドでこれほどなら
AMDのFusionとかの構想も結構期待できるのか？

それともChrome400が特殊なのかね？
Exponential？

>>296
> >LLVMの様な仮想命令とoptimizationまで取り入れられる。
> Ctでコーディングしたら、コードの自己書き換えを伴った実行時最適化が掛かるってことでおk?

印刷物は会社に置いてきちまったけれども、それでOKだと思う。
抽象IA命令だったっけな、これをruntimeに最適化しながら
具体的なIA-32、IA-64、Larrabeeなどの最適化Nativeが生成されて行くと
いうような事が確か文献に。
最近ﾓﾚの周りではこういう研究もﾌﾟﾁ流行の気配なんだ。ﾆﾔﾘ

自己書き換えっていうか動的生成のほうが正しい
文字通りの自己書き換えは（既存コードシーケンスの上書き）は、
ページ属性操作が煩雑かつトロくさくて最近はあまり流行らない
XDビットの兼ね合いもあるし。

バイトコードを動的に並べてExecutable属性つけてそこに飛ばすほうが速い

「粘着力はヤモリの足の10倍」、はんだ代替に使える導電性接着剤を米大学が開発
http://eetimes.jp/article/22472/

なかなか興味深いですね。
アーキテクチャ関係ないけど。

【1Peta-FLOPS】GPGPUについて語ろう【実用間近】
http://pc11.2ch.net/test/read.cgi/avi/1224646162/

消費電力は電圧の2乗・周波数に比例するって言うけど
性能も周波数に比例するから、アイドル時に電圧下がるなら
速く処理が終わる高クロックのがワットパフォーマンスは良くなんじゃない？

だとしたらPentium4は何が悪かったの？
周波数を上げても消費電力も性能も同じだけ上がるだけだけど
その周波数を上げるのに電圧を上げなくちゃいけなかったってだけ？

>>302
見通しではリーク電流を順調に減らせるはずだったけどそうはいかなかった。
それでもTDPと共にクロックを上げ続けたおかげで冷却が物理的に間に合わなくなった。

>>295
> Ctは非常にダイナミックなのできっと何か仕掛けてくると思う。LLVMの様な仮想命令と
> optimizationまで取り入れられる。○○とは役者が違う、もう参ったよって感じ。

おれの知ってるCtはOpenMPなC++コードを吐くコンパイラだったのだが、
いつのまにそんな高機能になったの？
ソースプリーズ

>>304
ＧhuloumのTechnology Jurnal 2007やWhitepaper。
forward scalingの章辺り以降VIP、VCGの記述の辺り。
今では英語のwikiからもintelのＣｔのｻｲﾄからﾘﾝｸがたどれる。という以前に、
ttp://www.google.co.jp/search?hl=ja&q=Intel+Ct+SSE+SIMD&btnG=%E6%A4%9C%E7%B4%A2&lr=
など…

ググるんだったらこっちの方がええんかな…
ttp://www.google.co.jp/search?hl=ja&q=Intel+Ct+LLVM&btnG=%E6%A4%9C%E7%B4%A2&lr=
すぐに実用的製品に至るかはﾜｶﾗﾝが、appleの件もあるので

>>298
>具体的なIA-32、IA-64、Larrabeeなどの最適化Nativeが生成されて行くというような事が確か文献に。
ふむふむ。
インタプリタでは間接分岐を工夫しないと性能に影響が出るって論文で読んだけど、
インオーダーのLarrabeeなら、それほど影響は出ないかもね。
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.14.5161


>最近ﾓﾚの周りではこういう研究もﾌﾟﾁ流行の気配なんだ。ﾆﾔﾘ
kwsk!!

>>299
>自己書き換えっていうか動的生成のほうが正しい
なるほど。
しかし、これだけだとLLVMって言うよりJVMのJITっぽいよね。

やることはJVMのJITそのものだよ。
単純な演算の繰り返しなんで、コンパイル時間より実行時間のほうが多いからJITでも十分。
分岐パターンが一意に決まらない複雑な演算もやらされるJavaよりもある意味では有利。

たとえば、このアプローチが有効なのは
http://homepage1.nifty.com/herumi/soft/xbyak.html
にもあるような量子化の定数を実行時に決めるやつ

GPUでやるような並列コンピューティングの場合、条件分岐の評価を最初の1回目だけあとは
同じパターンを延々繰り返しなんてのが多いからこういう最適化はかなり役に立つ。

JavaScriptエンジンも最近の実装ではJITを使った高速なものがある。
YARV(Rubyの別実装)でもXbyakを使ってx86ネイティブコードを動的生成することが試みられている。

Xbyak面白れぇ!使ってみよw

>単純な演算の繰り返しなんで、コンパイル時間より実行時間のほうが多いからJITでも十分。
逆に汎用言語の処理系ではLLVMみたく最適化の結果をファイルに書き戻す処理は流行りそうに思うけど。どうかな?

>JavaScriptエンジンも最近の実装ではJITを使った高速なものがある。
ｷﾓ過ぎるな、おいｗ
ブラウザの上でJITとか走った日にゃ、超高速ブラクラとか遭遇しそうでry)

>YARV(Rubyの別実装)でもXbyakを使ってx86ネイティブコードを動的生成することが試みられている。
ほぅ。さすがssdさんはそんなことまでやってたのか。
VM型インタプリタだから中間言語の仮想命令を一つずつネイティブ命令に置き換える実装?
それとも各仮想命令間をまたぐスーパー命令を動的に定義してくれんのかな?

YARVって確かネイティブスレッド対応だし、YARVのソースをLarrabeeコンパイラに掛けたらそのまま並列化出来そうだよね。

>>302
ロード時の電力が半端じゃないだろ。
少なくとも初期のPentium 4はアイドル時はPenII以降のデスクトップでは最も消費電力が低い部類です。

>>308
> JavaScriptエンジンも最近の実装ではJITを使った高速なものがある。

唐沢俊一のトリビアなみだなwww

Lars Bakで調べると吉

>>308
> やることはJVMのJITそのものだよ。

ちゃんと調べてから書けば、幼稚なことは書かずにすむ

ttp://portal.acm.org/citation.cfm?id=857077

>>311-312
Googleのv8エンジンも知らないなんて幸せですね

ヒント
SoftWire

単に自分自身がネイティブコードを生成するかVMがやるかの違いでしかない

BrainFuckのJITのサンプルがあるからちょうどいいだろ

BFソースプログラムからすればXbyakで書かれたサンプルアプリはJIT型のVMとみなせる

「JVMの」ってのがバカにされてるところじゃない？
よくわからんけど。
JVMってスタックマシンだよな。

JIT手を見る。

MACオタですら馬鹿にされたらムキになって調べてくるのに
団子って自分の知識が世界の全てだから、ずいぶん幸せそうだなww

あと最適化が手動のJITと同列にするのってどうなの？

Lars Bakという人名すら知らない団子は本当に幸せそうだ

へえ
ttp://d.hatena.ne.jp/sumim/20080904/p1
>Self VM から Animorphic VM、Java HotSpot VM、OOVM、そしてこのほどの V8 には、“VM の魔法使い”と呼ばれるラース・バック（Lars Bak）が共通してかかわっているという話のようです。

また頭のいかれたフェンス君かな？

>>315
見方の違いでしかない。
たとえばWindows上のJVMはjava.exeはバイトコードを読んでx86ネイティブコードシーケンスを動的生成するWin32アプリとも見なせる。
あとは動的生成対象のコードシーケンスが外部ファイルかアプリに組み込まれてるか
あるいは外部ファイルがテキストかたとえばJavaバイトコードか、
の違い。

ちなみに最近はRubyも単体EXE作れるんだな

>>321
> ちなみに最近はRubyも単体EXE作れるんだな

小学生の豆ちしきを披露する前に、ちゃんと調べよう

JVMやV8のネイティブコード生成ルーチンとSoftWireやXbyakのそれは技術的には同じだよ

Perlなども単体.exe作れるが…あれはLLVM等とは別扱いすべきだな。
途中で生成されるＣのソースコードはひたすらVMの機能関数呼び出しの羅列で
Perl本体の.oとリンクするわけだし…
Rubyはｼﾗﾈ

もとのCtの話にもどると肝はJITそのものでなくその時点での最適化でしょ？
SoftWireもXbyakもそこは手動なんだから同列に語れないでしょ
むしろJVMのHotSpotなら話は近いと思うけど

v8のソースちゃんと読んだ？

ぶっちゃけ実行時最適化もVM開発者が労力かぶってるだけの話でしかないんだが。

SoftWireは元々シェーダスクリプトをx86で実行するためのVMの土台のライブラリだから
立場的にはなにも変わらない。

http://v8.googlecode.com/svn/trunk/src/assembler-ia32.cc

Xbyakのやってることそのものだな

JVMのソースなら数年前に読んだよ。
V8は別にあんまり興味ない。
最適化に興味があるのでそのあたりおもしろいところがあれば紹介して欲しい。

>>328
> 最適化に興味があるのでそのあたりおもしろいところがあれば紹介して欲しい。

dynamic optimizationでciteseerを検索する
いろいろ出てくるので興味のあるものをたどってゆく
citeseerに本体がなくても、著者のページにあることがあるので、タイトルでぐぐると吉

どのﾚﾍﾞﾙでの最適化をご所望かﾜｶﾗﾝけど
最適化関連で多少注目していてｺｺに書いて差し障りのないものとしては
COIN、某大学の広域、LLVMの最適化・生成、あと海外の大学の数件くらいなどしかｼﾗﾝ。
役に立てずｽﾏｿな。Compiler Infrastructureでｸﾞｸﾞｯﾃ見ては？
さて、一杯飲んで寝るとするか…

COINSのMLは学生時代から登録やってるが、たまに質問が投げられても中身がないな

>>330
svKUApQqが静的最適化に興味があるんだったら、最近の分厚い成書をまず読むべき
Muchnickのがおすすめ

そんなことﾓﾚに言われてもｼﾗﾝｶﾞﾅｗ
文句ならﾒｰﾙ書いたﾔｼに言えば＞

>>333は>>331宛ね、念のため。

おもっきり実装レベルの話をすれば、生成したネイティブコードシーケンスの両端に
RDTSCみたいなクロックカウンタしこんでかかったクロック数を計測するだけだよ
あとは経験則で最適なコードシーケンスを選んでいくだけ。

Larrabeeの場合フィードバック最適化はあまり必要ないんじゃないかと
だってコンパイル時にCPUわかっちゃうだろ？

>>335
いや、だからさ、単体ﾚﾍﾞﾙでもの考えすぎだって…
くどくく言いたくないけれど

逆に泥臭いことが嫌いならさ、言ってるじゃん

i社「最適化ノウハウは我々にあるから君らバカ共はCtの取得だけに勤しんでくれ」


いずれにしても肝心なことは教えないから自ら茨の道を歩む人は
計測しつつトライアンドエラーしかない

皆様どうもありがとう。
興味あるのはLLVMのようなリンク時、実行時の最適化です。

>>335
プロファイルをフィードバックする最適化はgccでもできるけど
それなりの効果はあるよ。

if then elseのどっちの説をストレートに通してpipeline stoleを減らすかを
profileベースで決めるだけでもそれなりに効果はああったな。
いや、15年前の技術でｽﾏﾝけれども。ｵｯﾁｬﾝで悪かったな…

静的な最適化といえば必須テクはテンプレートメタプログラミングとかの類だな
再帰とかめちゃくちゃ速くなるぜ



あ、実行時にfprintfでCのソースを動的生成してコンパイラを走らすアホなフレームワークとか知ってるが
あれはソース読んで腹筋を激しく鍛える以外の意味は無いと思う

なんかあほらしくなってきた…
寝よっと

団子ちゃんの根底にあるものをわかってれば
そんなに疲れないんだけどねー

....何か荒れてるな。ひょっとしてオレのせい?...orz
COINSのくだりなんか政治的な匂いがするな。

>>340
>実行時にfprintfでCのソースを動的生成してコンパイラを走らすアホなフレームワークとか知ってるが
>あれはソース読んで腹筋を激しく鍛える以外の意味は無いと思う

最適化とは関係ないけど、javassitでアスペクト云々とかの事例もあるし、そこまで悪いとは思わないけどなぁ。

>>339
>if then elseのどっちの説をストレートに通してpipeline stoleを減らすかを
>profileベースで決めるだけでもそれなりに効果はああったな。

間接分岐予測の精度向上って昔からあるんだな。
VLIWが主流になるからこうゆう研究は下火になるって考えられた事は無かったのか?

>>343
> ....何か荒れてるな。ひょっとしてオレのせい?...orz
> COINSのくだりなんか政治的な匂いがするな。

いつものように、団子が自分の知っている単語(だけ)を振り回す、小学生のようなマネをしているだけです。

> 間接分岐予測の精度向上って昔からあるんだな。
> VLIWが主流になるからこうゆう研究は下火になるって考えられた事は無かったのか?

プロファイリングで分岐の最適化する話は、まさにVLIWと共に進歩したよ。

だまれフェンス

今日もJITのコンパイラソースも読めない恥ずかしいフェンス君がいたいね

>>343
いちいち文字列化してファイルに書き出し、更にそれと1字1字読んで解析することほど
コンピュータにとって無駄な作業はないよ。
実際問題効果は得にくい。

それならまだコンパイラのバックエンド組み込んじゃったほうがエレガント。
GCCなんてオープンソースなんだし。まあGPLだが。

それとね、インタプリタは字句解析→関数コールの繰り返しだから
たとえばCより速いとかさえ考えなきゃ、単純にマシンネイティブコードの
シーケンスに置き換わるだけでも十分な効果は得られるわけだよ。

普通のプログラム使ってる分には自己書き換えや動的生成といった技術では大した効果は得にくい。

まあ、Perl何かでよく多用する正規表現の評価なんかはどのみち正規表現ライブラリでやることになる。
文字列処理ばかりは、どうしてもそんなに速くならない。
まあ、Nehalemで正規表現の文字クラスを一括判定出来そうな命令も加わってることだし
SIMDに置き換え甲斐はあるんだけどね

あ、知ってると思うけどXbyakの更新ログ見てみな。度々コミットしてる「団子厨」って俺だよ。
宣伝乙だろ？

熱くなって書く前に、レスをまとめろ。

焼き団子旨そう。

XbyakってJITって言ってもJITコンパイラでなくJITアセンブラだよね
興味持つ人は少ないと思われる

もちろんアセンブラ部分の上の部分さえ作りこめばコンパイラになる。
YARVのサブプロジェクトとして使われてるyajitがXbyakベースのコンパイラ第一号だ

Xbyakの動向はRuby教祖まつもと氏も関心をお持ちのようだよ。

gccのasm()の方が好みだな。rtl式使えるしcompilerは当然既にあるし
つかスレチ

それただのインラインアセンブラ
JITは実行時生成だ

遊びとしては面白いだろうけど使う気が起きないわ。

>302
Pen4は内部で早いうちにx86命令をRISC命令に分解して
トレースキャッスに予測がヒットするのを前提として
楽観的に予測実行をせざるを得ないアーキテクチャだと
聞いたことがあります。リプレイシステムなんてのも実装されていました。
もちろんトレースキャシュにヒットする場合は速いのですが、そうも行かない
場合も多く、ヒットしない場合はリプレイシステムで再実行がかかります。
また、RISC命令に早期に分解しているため、実行命令数も増えます。
実行命令数が増えたのと、再実行が多いため、リソースを食いまくり、
限界に達したのかもしれません。
Core2系では、x86命令を早期に分解せず、むしろ合体をして実行命令数を減らします。
最後の最後ではRISC命令に分解するみたいですが。
全部受け売りです。もし間違った理解をしていたらごめんなさい。

>>356
うーん
微妙な理解だなぁ

命令長が不規則で複雑怪奇を極めたx86命令の命令の切りだし＆デコードはそれだけでも大がかりな作業なんだよね。
特に3-4命令同時にやろうと思えば。
Core2だって決して万能ではない。

NetBurstにとってはフロントエンドの負荷軽減のための省電力技術としての側面もあった。

Nehalemではものすごく限定的だがμOPsをキャッシュする機構を復活させている。
もちろん、ごく短いループでしか効果はないが。

つーか、それ以前に>>302の認識が間違えているから、
レスつけても仕方がない。

>>348
すごいな団子さん
尊敬する（嫌味じゃないよ）

そのうち程度がばれて
へるみからそっぽ向かれるに10,000ベリカ

ベリカってどこの単位だよ


とりあえずAVXのYMMレジスタ対応まで好きなように拡張していいって許可ならもらった

トランスメタのコードモーフィングでジャバを半ネイティブ実行する仕組みがあれば、
ネットブック用CPUとして未だ生き残ってたかもなあ。

まあ、ネットで目立つ人材を叩いてまわるだけで10年近いのに、
自分では何も発信できないどっかのコテよりは数倍マシですね。

FUCKヲタの悪口はそこまでだ

http://www.epitech.eu/v4/perso/~bevand_m/

epitechってどのくらいのレベルの大学なのよ？
これをさらに高速化出来る手法編み出したんだが。
つーか、ソース読んで1時間でわかった。

正確にはグランゼコールか。フランスの高等教育制度はよくわからん。

>>362
無理無理、ネイティブ自体が大した効率良くない。

これってどれ？

>>363
団子も大嘘ついては訂正しないことではMACオタに引けを取らんけどな

>>367
webページってテンポラリデータでHDDにキャッシュするから、そのキャッシュに
JSをx86ネイティブにコンパイルしたコードもキャッシュする、ってのはどう？

もうやってるかもしれんが。

こんなのあったけど、ポストカードが貰えるらしい。
http://zigsow.jp/?m=mus&a=page_entrance&museum_id=1

>>370
JavaScriptとJavaの違いを学んだ方がいい 実行の方式が全く違う
Scriptなのでネイティブ変換はできません HTMLの解析結果との連携なんかもあるし

ｵｰﾄﾏﾄﾝてSIMD処理に適しているのか？
状態の扱いは思いっきり依存ありげでvectorには不向きな気がするが
ﾌﾄ疑問に思っただけだが

ttp://www.google.co.jp/search?hl=ja&q=finite+automaton+regular+expression+SIMD&btnG=%E6%A4%9C%E7%B4%A2&lr=
ﾁﾗ見してみたが、芳しい検索結果はみつかりまへんな…

>>372
だから、v8はネイティブ変換やってるってば

>>373
普通は適してないよ。

というか馬鹿まじめにオートマトンなんてやってないよ。
正規表現エンジンでよく使われる後方参照なんて、
DFAじゃ実現そのものが不可能だし。（NFAといっても良いかも疑問）

PCREも鬼車はBoyer-Moore法で固定文字列として扱える部分を大雑把に判定することで
高速化してる。これはNFAでやるとものすごく遅いから。

手法にとらわれない本質って大事だよ。
正規表現を使って文字列検索をすることの本質は、ステートマシンを使うという
手段ではなく、あくまで文字列検索という目的。

で、文字列サーチ部分はSSEの支援を受けようと思えばできる。

状態変数そのものも高速化できる。

たとえば、SSE4.2の文字列比較命令を使うと、
XMMレジスタにロードされた最大16個の文字が
[1234567890ABCDEF]のいずれかにマッチするかを
1命令で判定するなんてこともできる

これ、動的生成でこそ効果発揮すると思うけどどうよ？
まあxmmレジスタに読む値は即値化できないがな

- PCMPESTRI (SSE4.2) Packed Compare Explicit Length Strings, Return Index
- PCMPESTRM (SSE4.2) Packed Compare Explicit Length Strings, Return Mask
- PCMPISTRI (SSE4.2) Packed Compare Implicit Length Strings, Return Index
- PCMPISTRM (SSE4.2) Packed Compare Implicit Length String, Return Mask

力技だが、BM法でやってた文字列サーチを代用することもできるし
文字クラスのマッチングのように使うこともできる。

文字列処理と正規表現をごっちゃにしている

馬鹿だね。「正規表現」は必ず全部有言オートマトンとして文字列比較しないといけないとでもお思いですか？
C++ TR1にもほぼそのまま採用されたBoost Regexですら固定文字列として扱えるパターンを抽出してｒ
boyer-moore法を使ってる

しかし、ぶっちゃけ今普及してるPerlコンパチのあれは「正規」でもなんでもないんだがな。

GNU GREPも複雑な正規表現で無い限りBM法やtrieを使ってる

ソースコードも読まずに古い知識を広げるのはやめていただきたい。

いい？
abc(def|g[hij]?)*k+

なんてパターンを与えられたら
まず必ず評価する "abc" にマッチする部分をBM法ないしその他の高速な固定文字列検索法で検索し、マッチしたところに対してNFAで評価するのがモダンな実装。

文字列処理はどうでもいいの
finite automatonはどうかという書き出しだが

おまえさんは文字列処理で扱える範囲の単純なパターンマッチングだけ
考えているんだろうけど、ｵﾚが着目しているのは例えは
ttp://search.cpan.org/src/MKUTTER/SOAP-Lite-0.710.08/lib/XML/Parser/Lite.pm
なの。

バカだな
俺はFAそのものを高速化できるなんて一言も言ってないぜ
NFAの最大のネックはバックトラックだし。

FAを使わない方が絶対的に速いんだから、いかに問題を切り出すかが課題。
モダンな正規表現エンジン高速化のテーマなの。

固定文字列なりtrieなりシンプルなパターンに落としこみ、JITで命令を使ったシーケンスに変換すればいい。
あ、おまえはSSE*はSIMDだと認めてないんだったかなｗ

もちろん梟本は持ってるよ俺は
おまいは持ってすらなさそうだが

>>384
> あ、おまえはSSE*はSIMDだと認めてないんだったかなｗ

誰と勘違いしてんだ

NFAの話に対し、NFAに頼らずにすむ高速化しやすい問題を扱えばいいと…

あ、
ベクトル演算＝ベクトルマシン
だったかな

固定文字列部分が4文字以上あるならmpsadbw+pminposuwを使う方法もある。
実際BMより速い。

ていうかレトロ君の脳内の正規表現パーザは後方参照（\1-\9）通りますか？

>>362
月アスのインタビュー等でDitzelが「やってる」って答えてたよ
後藤さんの海外ニュースにも掲載されてる
http://pc.watch.impress.co.jp/docs/article/20010619/kaigai02.htm
> Crusoeは、命令セットをハードウェアではなくソフトウェアでインプリメントしている。
> (中略) そのため、x86ではなく、異なる命令セットをインプリメントしたCMSを作ることもできる。
> 実際にTransmetaはJavaでそうした実験をやっている。昨年9月にディツェル氏は「CMSにJavaを
> インプリメントして、直接Javaのバイトコードを扱えるようにする実験はやった。Crusoeは、
> 世界最速のJavaプロセッサになりうる。しかし、Javaプロセッサの市場は大きくないので、
> 現在は提供していない」と語っている。

まぁ、「実験してる」発言であってデモしたわけじゃないので、性能は「？」だけど

いったい誰がNFAを高速化するなんて言ったんだ
思考回路が短絡してるな

文字列処理の話を勝手に始めたのは誰？

>>389
だったら最初から黙っていればいいのに…

正規表現は必ずFAで処理するものだと思いこんでるのはお前だけだよ

だから高速化しやすいケースの話ではなくFAの話だと
文字列はどうでもいいと。何度も書かせるな。

>>391
自己分析としてならその発言は正しいな
無知の君は最初からは黙ってれば良かったんだ

だめだコリャ…

俺はFAの高速化の話題なんて振ってないし
一人相撲はいい加減にしないと

ｵﾚはFAの話しをしてたんだよ。
それを聞きたくもないのに文字列処理の話しに勝手にそらしてﾚｽつけたのはお前だぜ。
訳わかんねぇぞ

まさかレトロ王国(国民1名)には
正規表現によるマッチングにFAを使わないといけないなんて法律でもあるのか？

じゃFAなしで頑張ればいい。どうぞご自由に。

FAを処理なんて誰が言い出したんだ？
正規表現による文字列検索にはSSE4が応用できるとは言ったが。
正規表現をまずFAに展開するなんて誰も言ってない。

だからお前に聞いていないと

ｵﾚも言っていないがそれが何か…

純粋にFAだけで処理する実装の方が珍しい

団子はなんで誰に対しても攻撃的なんだろうな

それこそ誰が言ったのかと…
まいいや、時間の無駄だった

>>373のレスは誰に向けてなのかな？
独り言なら失礼した。
LLでよくある正規表現による文字列検索のことは言ってなかったんだな

>>373と>>374には繋がりは無かった（ということにしたい）んだな

あのな、忙しいんでほどほどにしたいんだけれども
正規表現をによるパターンマッチングの内、文字列処理もある。
文字列処理にのみ着目すると色々高速化の方法がある。
方法があるとわかっている問題は解けているも同然だから
研究課題としてどうでもいいの。
状態の更新の様な依存がある問題をどう並列化するかのﾓﾃﾞﾙとして
ややこしいパイプライン化等が有効かとか、まぁ場合によるので一概に言えないが、
SIMDに関しては一括処理する単位が小さいので、
まぁいくらなんでも無理ジャマイカと、休日部屋掃除をしながら
つらつらと考えていた訳よ。
あばよ、勉強にならなかったぜよノシ

お帰り俺

で、>>374は結局何を検索しようとしてたの？

　finite automaton regular expression SIMD

こんなん見つかるわけ無いよ

っていうか
英語表記は　Finite Automata 　　だし
　　　　　　　　　　　　　　　　　　~~
日本語だけじゃなくて英語もだめなんだね。


根本的に全てFAに変換する必要自体ない。
後方参照をサポートするとすでにFAとは呼べなくなるし。

それ複数形だが…
だからもういいって。

>>410
団子は抽象的なものの考え方ができないし、
自分の知識にないものは世の中に存在しないのと同じなんだよ

正規表現＝FAで処理するものだなんて考えてるレトロ君ほど
凝り固まった考え方の人間もいないけどな

そうそう、団子は論理もおかしいんだった

>>408
リストベクトルを使って幅優先探索することくらいじゃまいか

リストベクトルって固定観念の象徴たるフェンス君が好きな用語だな

DFA


JIT

ちょっと誤爆した

SIMDはともかくとして
DFAをJITでネイティブコード化するのは悪くないアプローチだよ

正規表現エンジンでDFAを使った実装が不人気なのは、後方参照とかのサポートの問題
だけじゃなくて、特にUNICODEだと遷移テーブルが膨大になってかえってキャッシュミスでおそくなる
ケースが多いから。

JITだとテーブルを使わなくていい部分は使わない、使っても小さくてすむ場合は小さくする
っていう最適化ができるからその点の弱点は克服できる。

もちろん後方参照はDFAでは表現不可能なので（というかNFAですらない）
別の方法を考える必要があるけどね

>>360
団子ちゃんがへるみたんからソッポ向かれるのはいいけど
Xbyakに俺ライセンス的なものを主張しはじめないかとか
すごくしんぱい
今までの言動、行動を見てるとねー

http://www.dodgson.org/omo/t/?date=20071215

ま、この辺でも読んでみてくれ
まあ確かに状態遷移にSIMDは不向きだと思うよ。
ただ、テーブル参照を高速化するアプローチには部分的には使える。

コード読んでもらえばわかるんだが鬼車やPCREの「VM」ってのも所詮はインタプリタなので
ネイティブコード化して高速化する余地はいくらでもある。

で、○成氏はどうもつまらんところで苦戦してたらしーが
NFAすら使わない方法のほうがうまくいったらしい

> それに加えて，1TBの共有メモリを有する32CPUのスカラSMPのAシステムと，
> 3ノード96CPUのベクトルコンピュータのVシステムが付いています。

稲垣足穂かよw

>>417
ほんとの所
2.06にコミット依頼したとき部分的に提案突き返されたので
ああ、この人はこういう人なんだなと思いました。

コンパイル時引数チェックが甘いのと32ビットと64ビットをマクロで切り替えてるのが
不満だから、テンプレートベースで基本クラスを再設計してコーディングインターフェイス
互換なやつを作ってるのが本音。

というかSourceForgeに修正BSDライセンスで利用登録しちゃってるわけだが。
コードまだ1行もあげてないけどね。

>>419
っていうかレトロはエンタープライズ級のハードで解決しようって考え方がジジくさいなぁ
そこまでの問題でもないのに

ひげぽんスレでもxbyakの話題出てたけどへるみ氏はおもっきし過去の人扱いされてた。
まあ、俺も午後時代で終わった人と思ってるが

xbyakつくれてる時点でひげぽんより圧倒的に上だろ。
OSなんて多少の知識があれば体力勝負。

詳しそうな人が多いのでここで聞いてみる
プロセッサのメモリ関連でCRFって何？

>>418
> http://www.dodgson.org/omo/t/?date=20071215

このblogはそこそこ面白ぇな、特にgrepが圧倒的に早くて愕然とする下り。
grepが早いのは前から有名で昔から雑誌の雑文やネットに書かれたし、
perlもpythonもreは実行時にcompileしている。
ｵﾚはそのreを高速化するつもりなど毛頭ないし、そんなテーマで飯は食えない。
ましてやエンタープライズ級のハード、って何だかわからんがｗ持ち出す気などさらさら無い。
なんでそう妄想で話をスリップさせて因縁つけてバトルしたがるかね。
状態遷移問題の並列性について考えていた際、
FAに関しては並列化はともかくとして、SIMDは性能向上に貢献ないだろという話だったのにさ。

>>423
Xbyakの何が凄いんだ？
デザインが簡潔
それだけじゃね？

>>423
アホの俺にいじれてる時点で技術的にはたいしたもんじゃないよ
まんまSoftWireのパクリだし

ほかにもこんなんがあるよ。こっちはC
http://luajit.org/

>>425
ABC(DEF|GHIJ)
こういうパターンならABCDEFとABCGHIまでは同時に探索できるよな？SIMDで。
バックトラック回数の削減にもなるぞ。
状態マシンの概念破壊してるじゃんって言われたらそれまでだけどさ


あー、SSE4.2のマニュアル読んでみるといいよ。
Intelが言うにはアレはXMLパーザを組む為に作ったそうだが
XMLに限らずいろんな字句解析に使えるよ。

>>428
parse関連でserialの性能にコマったら4.2はいずれ読んでみるよ。�dｸｽｺ

>>424
commit reconcile & fences
詳しく走らん
読め
http://csg.csail.mit.edu/pubs/memos/Memo-413/memo-413.pdf

ARM Forum 2008レポート【マイコン編】
16bit/8bitマイコンの置き換えを狙うCortex-M3マイコン
http://pc.watch.impress.co.jp/docs/2008/1029/arm02.htm

講演では低コスト化の手法を、主に以下の4種類に分類した。

1)半導体の製造コストを下げる(回路面積を小さく抑える)、
2)メモリ・コストを下げる(必要なメモリ容量を少なくする)、
3)電力コストを下げる(消費電力を低く抑える)、
4)開発コストを下げる(安価なツールで短期間にプログラミングできる)、

である。

1)の「半導体の製造コストを下げる(回路面積を小さく抑える)」では、
組み込みマイコンに特化したアーキテクチャ「Cortex-M3」を開発する
とともに、ARMの特徴だった豊富なバンク・レジスタを大幅に削減して
回路面積を縮小した。

2)の「メモリ・コストを下げる(必要なメモリ容量を少なくする)」では、
命令セット・アーキテクチャを16bit/32bit混在の命令セット「Thumb-2」
だけにしてプログラムの容量を抑えるとともに、アンアラインド・データ
・アクセスとビット操作機能を導入してデータを効率的にメモリに収納
できるようにした。

3)の「電力コストを下げる(消費電力を低く抑える)」では、演算効率を
高めて処理に必要なクロック数を少なくするとともに、省電力モードを
設けた。演算効率の向上では、命令バスとデータ・バスを独立に装備
するハーバード・アーキテクチャを採用するとともに、1クロック・サイ
クルの乗算命令を装備し、ベクトル割り込みに対応した。省電力モード
では、スリープ・モードとディープスリープ・モードの2種類のモードを
設けた。

4)の開発コストを下げる(安価なツールで短期間にプログラミングできる)
では、32bitアドレスによる4GBの広大なメモリ空間、命令セットの一本化
によるプログラミングの簡素化、C言語での割り込み記述、デバッグ機能の
拡充などを紹介していた。32bitアドレスとは既存の16bitマイコンによる
アドレス空間の制約を意識したもの。命令セットの一本化とは既存のARM
コア(Thumb命令セットとARM命令セットの両方を装備)との違いを説明した
ものである。

まあソフト次第だが、AMDやnVidiaのGPU用ソフトとの競争は、果たして何処が有利なのやら。

リードテック、東芝「SpursEngine」搭載カードの発売日が決定
http://pc.watch.impress.co.jp/docs/2008/1029/leadtek.htm

団子のメッキがボロボロ剥げてるな

メッキｗｗｗｗ


NVIDIAの平柳って人知ってる？
先日メールでいろいろ話があってだね。

でね、俺も賺さずいろいろ情報聞いちゃったわけよ。
メディアに未公開の情報も掴んじゃってます。

とりあえずLarrabee出るまではCUDA厨やらせていただこうかなと。

俺のあっちのサイトでの活動を評価してくださったのよ。ぶっちゃけ。

おまいらときたら、机上の空論を並べるばかり。
天と地の差とはこのことだよ。

GTX2xx無償提供してくれるってさ

はいはい、すごいでちゅねー

馬鹿だなぁS3しかないだろGPGPUは


682 ：Socket774 [↓] ：2008/10/31(金) 00:16:25 ID:YC2/oQgy
ttp://xs432.xs.to/xs432/08444/shadrtest971.jpg

例のAMD製Shaderの命令発行数を測るプログラムで
9800GTX+,4870,4670,2600Pro,440GTXを比較

VSで2600が4670を上回るのが面白い
現在のATIのドライバーではVSは1アレイに制限されているので
共に8 shaderとなる2600,4670では似かよった結果になるのだが
クロック差を考慮すると、shaderあたりの命令発行は
2600の方が効率がよいということになるな

9800と440が似た傾向にあるのはshaderが同じくスカラであるためだろう

こうした差をものともせず、例の動画のような
（4670に迫る）shaderパフォーマンスを発揮する440は異常といえるだろう


683 ：Socket774 [↓] ：2008/10/31(金) 00:31:10 ID:pSuOrXQl
>>682
ものすごい低性能ってグラフにしか見えないんだが、俺ってグラフの見方分ってないのかな・・・


684 ：Socket774 [↓] ：2008/10/31(金) 00:37:32 ID:YC2/oQgy
上のはあくまで命令を発行できる数の比較でしかない

実際のshaderを走らせた場合はこのようになる

S3 Chrome 440 GTX VS ATI Radeon HD 4670 Shader Performance
http://jp.youtube.com/watch?v=y4eAODlnyxU&fmt=18

CUDAらねー

S3ってチートで一躍有名になったTridentを吸収したメーカーだよね
http://pc.watch.impress.co.jp/docs/2003/0530/ubiq7.htm

さぞすばらしいトリックがあるんだろうな

固定機能で手抜きってなんらともかく
shaderでそんな事が出来るのかよ
ドライバーのdownloadサイズ12MBそこそこので
100MB近いnvの方が余程あやしいわい

S3はExponential関連のライセンスもってたなそういや

CUDAランタイムとかも入ってるんじゃなかったっけ

CUDAあわせてもそんなに大きくなるかね？
ＡＴＩが全部込みで役40MB程度ですし

中身見たらPhysXで50MB近く使ってるわ

VS2008でCUDAが使えるようになるらしい？

それ機密情報なのに何で知ってんだよ

俺はリリース時期まで聞いた

だからあのスレに団子が来たのか･･･。

2008サポートは2.0Beta出した頃から言ってたじゃん
いつになるかを明言してなかっただけ

いつになるか聞いちゃいました

俺が持ち上げたしたってことは、まあつまりそういうことなんで
そこは察してね

年末
クリスマスあたりですかね

フロントエンドにVSが使えてもどうってことないんだが・・
CUDA以外でもそういうのは他にもいろいろあるし
問題はデバッガとプロファイラだな

なんか団子が暴れてNVIDIAのイメージ悪くなりそうだなｗ

CUDA2.1知ってるよね？ていうか公開情報だよね。

まぁおもしろい機能いろいろだね。


ま、おまいらが関心があるとしてそのVS2008をサポートするバージョンが
2.1になるか2.0のマイナーアップデートになるかってことだけど
まぁ楽しみにしててくれ。

とりあえず俺的にはOffice2007 Ribbonスタイル（＝Win7標準スタイル）のUIを持つ
CUDAアプリケーションが簡単に作れるのはそれなりに意味はあるかなと思ってるが

ある小学生の身内にゲーム作ってる奴がいるような、そんな錯覚。

商用アプリについてもAMDのGPGPU戦略がわからない。
TMPGEncやアドビには働きかけてるんだろうか。

うまい喩えだな
ただ別に身内でもないし敢えて言うなら実力でコネを作ったっていうか。

その小学生がたとえばロックマンの新作の敵キャラ募集で当選したと仮定してみなよ

私は素直に期待してるよ
アプリが増えるのはGPGPUの底上げにもなるし
是非にがんばって欲しい

まぁ、無理をしない程度に

ブロンズメッキが剥がれた下からは何が見えた？

nvのグダグダ加減
みたいな？

152 ：Socket774 [↓] ：2008/10/31(金) 22:57:00 ID:QmA5a6BH
また出棺追加？
Nvidia forced to dissable chipset PCI prefetch
http://www.fudzilla.com/index.php?option=com_content&task=view&id=10222&Itemid=1

特許侵害で機能を使えなくしないといけないらしい。＞チップセット

ま、俺に絡んじゃったのが最大の死亡フラグだな
CUDAやるのもIntelの中の人に開発ツール提供してもらうための踏み台にはなるかもな。

Streaming言語の方言ｗによる囲い込み大作戦でどのﾍﾞﾝﾀﾞｰも必死乙状態だが
無料で使えるくらいにしないと普及しないってば…
特にCt。
いや、GCC4.3,4.4にLarabeeのOpenMP対応 .mdをcontrinしてLinuxや(BSDでも←個人的嗜好)
Larabeeを活用できるようにするくらいの懐の深さがあればもはや最強、
もう君臨状態だろうな…

http://www.intel.co.jp/jp/business/glossary/6365.htm

IntelはCtを普及させる気がないのか・・・

ないある

larrabeeもDX11まかせ

Native C/C++/Asm任せに決まってるだろ

GPUアーキテクチャについて語るスレは無いのか…

厨vsスレがあるだろ

中国のIT誌、www.ciw.com.cnのFrank Soltisインタビューす。
http://epaper.cio360.net/zgjsjb/page/1/2008-10-27/C03/84841225186992305.pdf
興味のあるヒトわ、google translateの中国語->英語変換でもつかえば良いす。
目ぼしい内容わ、次の通り。
　- POWER7わ既報通り8-core
　- POWER6と比較した場合の動作クロックを尋ねた記者の質問に対して、「コアあたりの性能
　　は従来以上」と回答している。

フィックスターズ、「Yellow Dog Linux」の米Terra Softを買収--Cellビジネスの拡大目指す
http://japan.zdnet.com/news/ir/story/0,2000056187,20383457,00.htm?ref=rss

MIPSマネージメント・セミナー2008レポート
〜1GHz超の高速MIPSコアとマルチスレッドのクアッドMIPSコア
http://pc.watch.impress.co.jp/docs/2008/1114/mips.htm

これってnVidiaのCUDAよりも使い易いっぽいかな。

AMD、12月のCatalystで「ATI Stream」を実装
〜RadeonでGPUコンピューティングが可能に
http://pc.watch.impress.co.jp/docs/2008/1114/amd.htm

これってMicrosoftのDirectXよりも使い易いっぽいかなって言いながらPreyを紹介するようなもんだが

普通にCで書いたコードを最適化してくれればそれで良いんだけどな

>>470
Cyberlinkは今年の夏の終わりくらいに何か出すって言ってたよね

さて、Larrabee持ち上げるか

俺飽きるの早かったCUDA

nVidiaの話はどうなったんだよ

あーだめ
Intelなら各命令のレイテンシ−スループットとか事細かに公開するじゃん。
企業秘密のため答えられませんとかどんだけ。

まあ大体傾向調べて判っちゃったけどね。

Larrabeeのほうがまだ高性能。の可能性高い。

今週わSOIプロセスにからむ重要な報道が多かったので、まとめておくす。
まず、IBM一党の45-nm SOIプロセス受注開始の報道。
http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=212001346
　　---------------------
　　IBM claims 45-nm SOI can offer up to a 30 percent performance improvement or 40 percent
　　power reduction, when compared to bulk silicon.
　　---------------------
バルクとの比較と言っても、Intelの最先端HKMGプロセスと比較している訳じゃ無いというのわ、注意
すべきす。IBMとシンガポールのCharteredで、このサービスを提供するし、AMDの"The Foundary
Company"も、セカンドソースとして加わることになる筈す。
記事の方わ、この発表と合わせてSOIプロセスがニッチに留まっている現状について次のように述べて
いるす。
　- コストが相変わらず高い
　- SOIに対応したIPライブラリが少なすぎる
　- 過去にIBM自体がASIC製品での提供を重視していた
　- しかしNvidiaがSOIコンソシアムに加入するなど、性能目当ての顧客の参入も出てきた模様
SOIがニッチに留まっている現状を反映して、SOIウェハの製造企業の経営も苦しくなっているとのことす。
　- Ibisわ経営危機で見売り先を探している状態
　- Soitecの今年第3四半期の売上わ、前年より28.1%低下。世界経済の下降により今後の見通し
　　も苦しい。

上の記事でも売上低迷が取り上げられたフランスSoitec社すけど、先日シンガポールの新工場
落成の報道があったす。
http://www.eetimes.com/showArticle.jhtml?articleID=212001213
フル稼働で1M wafers/yrの規模とのことす。
SOIプロセスのファンダリ企業としてわ、IBM, Charteredに加えて"The Foundary Company"が加わって
市場が拡がることを当て込んでいると思われるす。

SOI市場拡販のためにわ、盟主IBMも手を売っており、>>477の記事で取り上げられた"IPが無い"という
問題解決のためにARMと話をつけた模様す。
http://www.arm.com/news/23737.html
http://techon.nikkeibp.co.jp/article/NEWS/20081110/161034/?ST=silicon
　　-----------------
　　英ARM Ltd.は，米IBM Corp.の45nm SOIのシリコン・ファウンドリ・サービス向けに，回路ライブラリ
　　を提供することになったと発表した
　　-----------------

AMDの製造子会社"The Foundary Company"の方針わ、先日のAnalyst Meetingでも説明が
行われたすけど、Fab36, Fab38, 新設のFab4xの三工場体制で32-nm SOIプロセスを提供し、
22-nm世代も予定していることを表明したす。
http://www.amd.com/us-en/assets/content_type/DownloadableAssets/DougGroseAMD2008AnalystDay11-13-08.pdf

ココまでの流れわ良い話が多かったすけど、SOI市場のニッチ具合と世界経済の危機的状況わ
甘くないす。IBMのSOI連合わ、IBM, Chartered, The Foundary Companyの3社体制での製造を行う
というの予定すけど、早速一角が崩れて、Charteredの身売りの噂が出てきたす。
http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=212002266
オリジナルのソースわ、台湾Digitimesのこちらす。
http://www.digitimes.com/news/a20081113PD206.html
CharteredのCEOが身売り交渉のために、台湾を訪問するとか。TSMCかUMCが買収することになる
という話す。

ARMベースのノートPCをubuntuでサポートするというニュースす。
http://news.zdnet.com/2424-9595_22-249202.html
　　----------------
　　ARM-based processors have traditionally been used in small devices such as mobile
　　phones, but it emerged in October that ARM's technology would soon be used in netbooks,
　　the new breed of small, low-cost notebook PCs.
　　----------------
MS vs Linuxとか、Intel Atom vs ARMとか色々な視点で興味深いニュースすけど、上で書いた
IBMのSOIプロセス連合の報道とある意味でリンクしていると言えるす。

来週の国際会議SC2008で今年下期のTop500が発表されるす。で、下馬評を扱ったこのニュース。
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9120142
　- ORNL Jaguar (Cray XT5アップグレード), LANL Roadrunnerアップグレード, Blue Gene/Pが有力
　- Jaguar: 45-nm Opteron 搭載ラックを200台増強 (192 chips/rack)。ピーク性能 1.64 PFlops。
　　　　　　　消費電力 7MW
　- Roadrunner: 軍用のためアップグレードの状況わ謎。消費電力わ3,9MW -> 2.5MWに改善とか。
　- Blue Gene/P: 世界各地の計算機センターが導入中

Top500の結果す。
http://www.top500.org/list/2008/11/100
　1. LANL Roadrunner (PowerXCell 8i/3.2GHz) 1,105 TFlops (ピーク比 75.9%), 2,483 kW
　2. ORNL Jaguar (QC Opteron/2.3GHz) 1,059 TFlops (ピーク比 76.7%), 6,951 kW
　3. NASA Pleiades (QC Xeon/3.0GHz & 2.66GHz) 487 TFlops (ピーク比 80.0%) 2,090 kW
　4. LLNL Blue Gene/L (PPC440/700MHz) 478 TFlops (ピーク比 80.2%) 2,330 kW
　5. ANL Blue Gene/P (PPC450/850MHz) 450 TFLops (ピーク比 80.8%) 1,260 kW

TSMCが40-nmプロセスでの量産を開始するとのことす。
http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=212100139
　　--------------------
　　 At 40-nm, TSMC offers several derivatives, including general purpose (40G) and
　　low-power (40LP) versions.
　　The 40G process targets performance-driven applications, including processors, graphics
　　chips, networking devices, field programmable gate arrays (FPGA), storage ICs and others.
　　The 40LP process targets low-power applications, including cellular baseband, application
　　processors, portable consumer and wireless connectivity devices.
　　--------------------
SunもTSMCの40-nmを利用する予定なんて話も書いてあるすけど、経営危機のSunが果たして
SPARCの開発を継続できるかどうか。。。

正式発表に合わせてCore i7のSPEC2006が公開されたす。
代表的なハイエンドプロセッサの成績と比較しておくす。OS等わバラバラなので参考程度に
しておいて欲しいす。
■SPECint2006
　Nehalem/3.2GHz: 30.2 (base) / 33.6 (peak)
　http://www.spec.org/cpu2006/results/res2008q4/cpu2006-20081024-05711.html
　Penryn/3.2GHz: 27.0 / 29.7
　http://www.spec.org/cpu2006/results/res2008q4/cpu2006-20081024-05695.html
　POWER6/4.7GHz: 17.8 / 21.7
　http://www.spec.org/cpu2006/results/res2007q4/cpu2006-20071030-02416.html
　Montecito/1.66GHz: 15.7 / 17.0
　http://www.spec.org/cpu2006/results/res2007q4/cpu2006-20071015-02284.html
　Barcelona/2.5GHz: 14.4 / 16.2
　http://www.spec.org/cpu2006/results/res2008q3/cpu2006-20080721-04794.html
　POWER5+/2.2GHz: 10.5 / 13.2
　http://www.spec.org/cpu2006/results/res2007q1/cpu2006-20070215-00481.html
　SPARC64 VII/2.5GHz: 11.5 / 12.6
　http://www.spec.org/cpu2006/results/res2008q4/cpu2006-20081023-05678.html
　Pentium4/3.8GHz: 11.6 / 12.3
　http://www.spec.org/cpu2006/results/res2006q3/cpu2006-20060513-00018.html

■SPECfp2006
　Nehalem/3.2GHz: 31.7 (base) / 33.6 (peak)
　http://www.spec.org/cpu2006/results/res2008q4/cpu2006-20081024-05709.html
　SPARC64 VII/2.5GHz: 25.0 / 28.8
　http://www.spec.org/cpu2006/results/res2008q3/cpu2006-20080711-04734.html
　Penryn/3.2GHz: 24.5 / 25.3
　http://www.spec.org/cpu2006/results/res2008q4/cpu2006-20081024-05693.html
　POWER6/5.0GHz: 20.1 / 24.9
　http://www.spec.org/cpu2006/results/res2008q2/cpu2006-20080407-04057.html
　Montecito/1.66GHz: 19.9 / 20.4
　http://www.spec.org/cpu2006/results/res2007q4/cpu2006-20071015-02285.html
　Barcelona/2.5GHz: 18.5 / 19.7
　http://www.spec.org/cpu2006/results/res2008q3/cpu2006-20080721-04798.html
　POWER5+/2.2GHz: 12.9 / 14.9
　http://www.spec.org/cpu2006/results/res2007q1/cpu2006-20070215-00483.html
　Pentium4/3.8GHz: 11.9 / 12.1
　http://www.spec.org/cpu2006/results/res2006q3/cpu2006-20060513-00017.html
　

■SPECint_rate2006 (8-threads)
　Dual Penryn/3.2GHz: 145 (base) / 156 (peak)
　http://www.spec.org/cpu2006/results/res2008q4/cpu2006-20081013-05591.html
　Dual Shanghai/2.7GHz: 113 / 136
　http://www.spec.org/cpu2006/results/res2008q4/cpu2006-20081024-05683.html
　Single Nehalem/3.2GHz: 117 / 124
　http://www.spec.org/cpu2006/results/res2008q4/cpu2006-20081024-05712.html
　Dual POWER6/4.7GHz: 108 / 122
　http://www.spec.org/cpu2006/results/res2007q4/cpu2006-20071030-02417.html
　Quad Windsor/3.2GHz: 102 / 119
　http://www.spec.org/cpu2006/results/res2008q2/cpu2006-20080331-04035.html
　Dual Barcelona/2.5GHz: 92.7 / 108
　http://www.spec.org/cpu2006/results/res2008q3/cpu2006-20080801-04850.html
　Quad Montecito/1.6Ghz: 94.7 / 102
　http://www.spec.org/cpu2006/results/res2006q4/cpu2006-20060918-00102.html
　Dual POWER5+/2.1GHz: 47.9 / 53.3
　http://www.spec.org/cpu2006/results/res2007q1/cpu2006-20070205-00339.html
　Single SPARC64 VII/2.52GHz: 36.9 / 40.8
　http://www.spec.org/cpu2006/results/res2008q4/cpu2006-20081023-05680.html
　

■SPECfp_rate2006 (8-threads)
　Dual Shanghai/2.7GHz: 105 (base) / 118 (peak)
　http://www.spec.org/cpu2006/results/res2008q4/cpu2006-20081024-05684.html
　Dual POWER6/4.7GHz: 102 / 115
　http://www.spec.orgcpu2006/results/res2007q4/cpu2006-20071030-02421.html
　Quad Windsor/3.2Ghz: 95.3 / 103
　http://www.spec.org/cpu2006/results/res2008q2/cpu2006-20080527-04440.html
　Dual Penryn/3.4GHz: 87.2 / 95.6
　http://www.spec.org/cpu2006/results/res2008q4/cpu2006-20080915-05364.html
　Dual Barcelona/2.5GHz: 86.3 / 94.7
　http://www.spec.org/cpu2006/results/res2008q3/cpu2006-20080623-04663.html
　Quad Montecito/1.6GHz: 87.4 / 90.8
　http://www.spec.org/cpu2006/results/res2008q3/cpu2006-20080623-04663.html
　Single Nehalem/3.2GHz: 82.9 / 86.1
　http://www.spec.org/cpu2006/results/res2008q4/cpu2006-20081024-05710.html
　Dual POWER5+/2.1GHz: 57.2 / 62.5
　http://www.spec.org/cpu2006/results/res2007q1/cpu2006-20070205-00340.html
　Single SPARC64 VII/2.52GHz: 33.6 / 35.2
　http://www.spec.org/cpu2006/results/res2008q4/cpu2006-20081023-05679.html

>>484-485のシングルタスクのSPECint/SPECfpにshanghaiの登録が無いのわ残念
すけど、Nehalemのスゴさわ揺るがないす。

なお、int, fp共にrateの成績に関してわSMTをサポートしているプロセッサわ若干不利である
ことを割り引いて見て欲しいす。Nehalem, POWER6, POWER5+, SPARC64 VIIが該当するす。

ふ〜ん。たかがﾍﾞﾝﾁ、されどﾍﾞﾝﾁ、なんだか時代の切り替わりを感じるな…
こーれでcore当たりのLinpackも速かったら、top５００はCPUの総数と網だけが勝負のでｋ(ry

>>489
　　-----------------
　　たかがﾍﾞﾝﾁ、されどﾍﾞﾝﾁ、
　　-----------------
『たかが』すか？一般にプロセッサアーキテクチャの研究でわ、典型的命令ミックスとして
SPEC CPUを使う筈すけど。。。

>>490
それは「されど」のほうだな

>>490
「たかが」のほうでは、
研究者はみんな「こんなのあてにならんよな」と思いながら、他に代わるものもないのでしぶしぶ使っている

>>492
　　------------------
　　研究者はみんな「こんなのあてにならんよな」と思いながら、
　　------------------
早速、知ったかさんが現れた様す(笑)
http://www.spec.org/cpu2006/Docs/readme1st.html
　　==================
　　The benchmark programs are developed from actual end-user applications, as opposed to being
　　synthetic benchmarks.
　　==================
反面、CELL/B.E.やGPGPUのようなプログラミング手法そのものの変革が必要なシステムわ
テストできないということになるす。

>>493
はあ、それは理想ではあるけどな…
部外者は気楽なこって

変革だとさｗ
CELL/B.E.やGPGPUでintのgccとか計ってみなってｗ
万が一うごいたら…の話だが。

>>495
多分すげー遅いだろうな、0.1とかw

>>>493って自己紹介上手いな

>>482で紹介した今年下半期のTop500すけど、今回からシステムの消費電力も一部公表されて
いるす。そこで、アーキテクチャごとの電力効率をまとめてみたす。
なお、クラスタシステムわインタコネクトの違いで電力効率が大きく変わるので、ケチってギガイ
ーサを使っているシステムわ除いたす。明らかにおかしいと思われるデータも除いたす。

■スーパーコンピュータの電力効率
　　プロセッサ / 電力効率 [MFlops/W]
　　IBM PowerXCell 8i / 498.4 (最高536.2, 最低444.9)
　　IBM Blue Gene/P (PPC450) / 367.8 (最高371.7, 最低357.1)
　　IBM Blue Gene/L (PPC440) / 206.6 (最高208.3, 最低203.8)
　　Intel QC Harpertown / 203.5 (最高265.8, 最低 124.9)
　　Intel QC Clovertown / 170.8 (最高207.0, 最低 130.5)
　　AMD QC K8L / 154.9 (最高 231.6, 最低 113.8)
　　IBM POWER6 / 87.4 (最高95.6, 最低 69.9)
　　Intel DC Woodcrest / 84.5 (最高 102.9, 最低 57.4)
　　AMD DC K8 / 43.9 (最高 81.5, 最低 27.1)
　　Intel DC Itanium2 / 57.1
　　IBM POWER5+ / 40.0
　　IBM POWER5 / 39.0
　　NEC 地球シミュレータ (SX-6) / 11.2

マルチコア化とプロセスの縮小が、電力効率向上の大きな要因になっていることが判るす。
Intelの45nmプロセス世代の汎用プロセッサがBlue Gene/L (130-nmプロセスのPPC440コア
SoC)に電力効率で追いついているのわ、たいしたモノだと思うす。
POWER6わ巨大コアのデュアルコアチップとしてわ意外に頑張っているのと、POWER5の電力
効率の悪さがちと目立つす。

>>484-487のBloomfieldのSPEC CPU2006すけど、AcesHardware掲示板の投稿によると
シングルプロセスの結果も"rate"も両方ともにターボモードの恩恵を受けているとの話す。
http://aceshardware.freeforums.org/amd-shanghai-launch-t684-15.html#8697
　　--------------------------
　　The all architecture help on SPEC, it is not that simple to find a reason for the boost.
　　Memory help, The cores are improved. With regular cooling, in 99% of the case, turbo
　　will kick in, you rarely get to the max power ...
　　when you run spec , you ll get your 2 bin turbo boost, then you run SPEC_FP_RATE, you'll
　　get 1 bin turbo boost. I just checked with my Buddy Rahul, the Spec Gurus.
　　--------------------------

どこに行っても馬鹿にされてるんだね

IBMがバイナリトランスレーションの専門企業Transitiveを買収したす。
http://www.theregister.co.uk/2008/11/19/ibm_buys_transitive/
記事にもあるようにTransitiveのQuickTransit技術わ、AppleのRosetta、IBMのPowerVM Lx86,
HPのSolaris実行環境等に採用されているす。
古くわ、こういうニュースもあったすね。。。
http://www.watch.impress.co.jp/pc/docs/article/20011019/mpf04.htm

前述のようにIBMわPOWERサーバーにおけるx86版Linuxアプリの実行環境としてPowerVM Lx86
を提供しているすけど、経営危機のSunの顧客を狙ってSolarisでも同様の戦略を取ると思われる
す。加えてTransitive社自体を手に入れることにより、他のプラットフォームへのSunの顧客の
流出を邪魔することを狙っているのかもしれないす。

普通の日本語書けばいいのに。

Top500ランキングに関してわ、JAXAのSPARC64 VIIシステムで222位にランクされた富士通が、
微妙なリリースを出しているす。
http://pr.fujitsu.com/jp/news/2008/11/19.html
　　------------------------
　　当社のハイエンドテクニカルコンピューティングサーバ「FX1」を中核としたこのシステムは、
　　世界トップレベルとなる89％以上の実行効率(注1)を実現し、このたびのTOP500リストに
　　掲載されている日本のシステムでは最も高い実行効率となります。
　　------------------------
理論ピーク性能とLinpackの結果の比である実行効率に関してわ、従来からItaniumベースのSGI
のシステムが優れており、今回のランキングでもJAXAのクラスタより大規模なシステムで90%以上
を達成しているモノもあるす。
　44位　http://www.top500.org/system/performance/8385

ふーん

CrayがXeon搭載のデスクサイド・スーパーコンピュータ CX1を発表したす。
http://www.cray.com/Products/CX1.aspx
中身わ、ただのブレードサーバー筐体なんすけど、Xeonと共にNvidiaのTesla C1060を搭載
したGPGPUノードなんてのも詰め込めるところが新しい目す。
http://investors.cray.com/phoenix.zhtml?c=98390&p=irol-newsArticle&ID=1228234&highlight=
LinuxベースのクラスタOSとしてわ、割と有名なRocksとセットでも売る模様す。
http://investors.cray.com/phoenix.zhtml?c=98390&p=irol-newsArticle&ID=1227697&highlight=

今のところ搭載CPUわHarpertown Xeonすけど、Nehalem-EPが発表されれば搭載すると
思われるす。

top500等、だれもがアクセスできるところにある公知情報を延々コピペは控えめがよろしいかと

>>506
私の投稿で引用で囲った文章だけがコピペす。
どれをコピペと思い込んでるすかね(笑)

言うと思ったｗ
ﾘﾝｸ張るにしても宣伝臭い情報などは見抜いてもう少し有用なﾈﾀか吟味して精選したら？

クスクスクス

コピペのみに徹していれば
馬鹿にされることも無いだろうに

反応してるやつはみんなオタの仲間

MACヲタに嫉妬するのはみっともないですよｗ
自分の無能さに気づきなさいｗ

はーい

ちょっと面白い記事だが、ブロック毎に休止させる手段との整合性が気になった。

単一電力で動作するレベル・シフター、システム構成の簡素化に役立つ（2008/11/21公開）
http://eetimes.jp/article/22552/

SGIがx86版Blue Geneとも言うべき製品"Molecule machine"をSC08でデモしたらしいす。
http://www.theregister.co.uk/2008/11/20/sgi_molecule_concept/
　- Dual-core Atom N330/1.6GHz
　- プロセッサ、2GBメモリ(4 x 512KB DDR2 DIMM)、インタコネクトチップをボード上に配置
　- "Kelvin"と呼ぶセラミックカートリッジに上記のボードを2枚収納
　- Kelvinを電源、ネットワーク、冷却機構を内蔵したバックプレートに接続
　- 90個のKelvinを3Uラックに収納。 2 x 2 x 90 = 360 cores in 3U-rack
こういう言い回しをしているところを見ると、ノード間ネットワークの設計わ、まだ固まっていない模様す。
　----------------------
　The important thing to realize, explained Brown, is that if the interconnect was architected
　correctly, the entire memory inside the chassis could be searched in one second.
　----------------------

上の話、写真つきの日本語の記事が出ていたす。
http://techon.nikkeibp.co.jp/article/NEWS/20081120/161565/?ST=lsi
写真を見ると、上でリンクしたThe Registerの記事わ若干誤解が含まれている様す。
　　-------------------
　　ブロックは，寸法が5cm角ほどの基板2枚を空冷用の孔をはさんで張り合わせ，樹脂で
　　固めたものから成る。各基板にはマイクロプロセサとデータの経路制御用LSI，および
　　メモリ用チップを基板の裏表で計8個搭載している。マイクロプロセサには，デュアルコア
　　のAtomを用いる。このAtom は，1.3GHz動作で「x86-64」の命令セットが動作する。メモリ
　　の容量は1基板で2Gバイトである。
　　-------------------

Top500に続いて、電力効率のコンテストGreen500とHPC Challengeの結果も発表されたす。
Green500: http://www.green500.org/lists/listdisplay.php?month=11&year=2008&list=green500_200811.csv&start=1&line=101
HPC Challenge: http://www.gcn.com/online/vol1_no1/47627-1.html
なぜかHPC Challengeわ、公式サイトhttp://www.hpcchallenge.org/が未だにアップデートされて
いないす。上記の記事によると、結果わ以下の通り。
　■ G-RandamAccess
　　1. Blue Gene/P (ANL): 103 GUPS
　　2. Blue Gene/L (LLNL): 35 GUPS
　　3. RedStorm, Cray XT3 (SNL): 34 GUPS
　■ G-FFT
　　1. Blue Gene/P (ANL): 5,080 GFlops
　　2. RedStorm, Cray XT3 (SNL): 2,870 GFlops
　　3. Jaguar, Cray XT5 (ORNL): 2,773 GFlops
　■ G-HPL
　　1. Jaguar, Cray XT5 (ORNL): 902 TFlops
　　2. Blue Gene/L (LLNL): 259 TFlops
　　3. Blue Gene/P (ANL): 191 TFlops
■ EP-STREAM-Triad
　1. Jaguar, Cray XT5(ORNL): 330 TB/s
　2. Blue Gene/L (LLNL): 160 TB/s
　3. Blue Gene/P (ANL): 140 TB/s

>>514
容量素子のサイズがでかくなってあまりメリットないような・・・

MIMならともかくMOSキャパなら大した事無いだろ

Green500が発表されたので、>>498をアップデートす。
今回わ、Green500ルールで測定が行われているデータの上位3つの平均を求めてみたす。
なお、前回IBM p575 (POWER5+)のシステムで効率が異常に良いデータを除いたすけど、
Green500の審査に通っているので、今回は計算に入れたす。
■プロセッサごとのスーパーコンピュータの電力効率比較 [MFlops/W]
　1. IBM PowerXCell 8i (65nm): 532.3
　2. IBM Blue Gene/P, QC PPC450 (90nm): 371.7
　3. Intel Harpertown, QC Core2 (45nm): 241.7
　4. IBM Blue Gene/L, DC PPC440 (130nm): 208.3
　5. Intel Clovertown, QC Core2 (65nm): 188.7
　6. AMD Barcelona, QC K8L (65nm): 146.9
　7. Intel Woodcrest, DC Core2 (65nm): 109.1
　8. IBM DC POWER6 (65nm): 95.6
　9. IBM DC PPC970MP (90nm): 91.7
　10. IBM DC POWER5+ (90nm): 71.0
　11. Intel DC Itanium2 (65nm): 69.3
　12. AMD DC Opteron, DC K8 (90nm): 46.9
　13. IBM DC POWER5 (130nm): 36.3

集計法が異なるので、若干>>498と順位も変動しているす。

>>479で書いたChartered Semi.の身売り話すけど、Digitimesより続報す。
台湾訪問中のChartered CEO, Song-Hwee Chiaわ、合併交渉を否定したとのことす。
http://www.digitimes.com/news/a20081121PD207.html
　　-----------------------
　　In response to rumors about Chartered seeking mergers with Taiwan's foundries,
　　Chia said it is too "risky" to talk about such issues at present. He declined to make
　　further comments concerning possible mergers.
　　-----------------------

MACオタって何してる人？
相当知識はありそうなんだから別にこんなとこに居なくともよさそうだが。

見ての通りだろ

四六時中ネット徘徊してる人？

ちょっと煽るとすぐ火がつくMACオタ（）笑

こんなとこ、に集まる人々

i7は単体core当たりの対C2D比実効性能をなぜ上げられることができたんだろうか
例のMNIのｺﾋﾟﾍﾈﾀを除くとw、C2Dはかなり完成度が高くて
これ以上単体実効性能を上げるのは相当難しそうな気がしていたんだが
あいつらすげえ執念だな。

あるいは、今後更に単体実効性能を上げる余地があるとすればそれはどのようにしてなのだろう。

もはや単体性能にこだわる時代でも無いのかもしれないし、
単純なﾍﾞﾝﾁでの性能比較の無意味さは食傷ぎみだが。

こういう話の方がtop500よりも面白いと思うのは個人的な趣味なのかな

つか、まぁGFLOPSだの性能云々そのものが指標として陳腐化してきて
世の中流や産業ともはや連動していないんだよな…orz

>>527
　　------------------
　　i7は単体core当たりの対C2D比実効性能をなぜ上げられることができたんだろうか
　　------------------
これだけNahelemアーキテクチャ解説の情報が溢れているというのに。。。言うに事欠いてそれすか(笑)

top500なんて昔から、国の、プロセッサ屋の、システムベンダの、宣伝用だからね

>>527
基本的に「メモリ直結」と「キャッシュ増量」のお陰だろ。

あとは「ＨＴ」や「コア数ウプ」も有るが、いずれにしても大きな改良点に
珍しい手法は見当たらない。

>>531
あと「メモリチャネル数が３つ」になったのも大きい。

キャッシュの総容量は実は12MBから8MBに減ってるけどな

Intelの技術者が言うにはL2を小容量低レイテンシにしたことが効いてるらしいけど
512KBだと性能が落ちたとか。

馬鹿来た

レイテンシ幾つから幾つに変わったの？教えて君ﾓｰﾄ、横着ﾞｗ
中身の変化は寄与無いの？
で、そういった改良を総括するとあの実効性能の差は合理的に説明つくのだろうか、、、

> Intelの技術者が言うにはL2を小容量低レイテンシにしたことが効いてる
intelって前からそれ好きだよな…
AMDやCentaurがL1を128KBにする中で、レイテンシを優先してPentiumPro以来ずっと容量は32KB程度のままだったり
あと、L2も、Pentium4とAthlonXPで同じ256KBだった時代でも幅が256bit対64bitだったり…

MACオタのアク禁まだ〜？

CoppermineのL2はレイテンシ0とか無茶な数字が書いてあった気がする

もともとFSB経由だったのが内部バス化されたからそういう意味でのレイテンシ0だろ
L2そのもののレイテンシが無いわけではない

TheINQのCharlie "Groo" Demerjianによると、Microsoftが自社ブランドの携帯電話
を開発するとの事す。プロセッサわ何とNvidia Tegra (ARMコアSoC)とのことす。
http://www.theinquirer.net/gb/inquirer/news/2008/11/21/microsoft-phone-nvidia
Tegra製品についてわ、こちら。
http://www.nvidia.co.jp/page/handheld.html
iPhone, Gphoneに続き、MSまでARM系採用を決めたことで、Intelの組込分野への
野望わ、展望が苦しくなってきたす。

ARMのSIMD拡張としては本家の64bit/128bit拡張よりメジャーな
WirelessMMXを普及させた張本人じゃないかIntelは

>>541
事業としてのXScaleわMarvellに売却されてしまったす。
http://www.intel.co.jp/jp/intel/pr/press2006/060628.htm

そうだよ。黒字出してたのにAtomを普及させるためにわざと、ね。

ARMは各ベンダーのDSPコントローラのコントロールコアとしては広く普及したけど
独自のSIMD拡張命令を普及させることに関してはうまくいかなかった。
それこそDSPベンダーの思惑があって。
WirelessMMXがMSやGNUのコンパイラで本家のSIMD拡張であるNEONをさしおいて
サポートされてる。これが現実。

で、WMMXをそこまで成功させたIntelが今度はx86命令セットそのものをサポートする
モバイルチップを投入する。
各ベンダーはともかく、開発者は画一的なアーキテクチャを望むわけよ。
アクセラレータ部分の命令セットも共通化したいわけだ。

MSが自社ブランド携帯電話でARM採用したからってどうなるもんでもないよ。
どうせハード作るのは東芝かサムスンあたりだろ。
Intelは保険としてモバイル向けLinuxの開発やってるが
あれこそMSとの交渉材料だと思ってるが。


大体に、Intelはもともと携帯電話そのものをいきなり狙う方針ではなかった。
ぶっちゃけシャープとWillcomのあれは先走りすぎた。
もともとAtomは現行世代で携帯電話で勝負する気はない。
消費電力がまだ大きすぎる。
x86コード資産を生かして製品は携帯電話とモバイルPCの中間のレンジから浸透を図る予定だったはず。

ARMに共通のソフト資産なんてあってないようなもんだからx86市場が脅かされることも無いわけだ。
（コントロールコア部分が共通化できるくらいでアクセラレータ向けのコードには互換性がない）

＞野望わ、展望が苦しくなってきたす。

こんな間抜けな個人見解は書かなきゃ良かったな。
君はコピペだけやってればいいよ
自分の頭で考えることだけはやめたほうがいい。

目糞と鼻糞の競演

>>543
火病っているところ申し訳無いすけど、MSがNvidiaと組むということわ、
　　-------------------
　　WirelessMMXがMSやGNUのコンパイラで本家のSIMD拡張であるNEONをさしおいて
　　サポートされて
　　-------------------
この部分にNvidiaのGPU/GPGPUを採用するということす。
「ARM」という部分だけに目が行って、本題を見過ごしているとわ思わないすか？

>>501
ITJungleのMorgan記者のIBMによるTransitive買収の分析記事す。
特に新味わ無いすけど、歴史的な経緯やIBMの戦略予想が良くまとめられているので貼っておくす。
http://www.itjungle.com/tfh/tfh112408-story01.html

>>545
無理だね。Tegraに採用されるコアはシェーダモデルとしては相当古い。
CUDAがサポートされてるプラットフォームくらい調べたほうがいいよ。

GeForce8からだ。それ以前は切り捨て。
もちろんTegraでもCUDAはサポートされない。アーキが別物だもの。

頭悪いんだから喋るな。わかったな？

>>547
　　-------------------
　　CUDAがサポートされてるプラットフォームくらい調べたほうがいいよ。
　　-------------------
携帯電話で科学技術計算でもすると思い込んでいるすか(笑)

携帯機器におけるマルチメディア命令の用途わ、過去のPCと同様にCPUがGPU役をやっている状況す。
専用GPUにオフロードするだけで御の字かと。

Intelの主張するWireless MMXの用途わ、こちらす。
http://www.intel.com/intelpress/sum_wmmx.htm
　　----------------
　　- Video compression
　　- 2D and 3D graphics
　　- Image processing
　　----------------
Nvidia Tegraの主要な機能わ、こちら。
http://www.nvidia.co.jp/page/handheld.html
　　----------------
　　- 最高1080p HDの映像再生
　　- 分かりやすくスムーズな3Dユーザインターフェースのための超省電力GeForce GPU
　　- 100時間を超える音声、および10時間を超えるビデオ再生のための統合メディアプロセッサ
　　- 進化したDSCおよびHDビデオカメラ処理による画像処理
　　----------------

少なくとも"GP"GPUじゃァないなあ・・・それは。

画像処理にしたってOpenGL ESで実装するのは確実だしね。
NVIDIAのGPGPUを採用とは言えないわな。

>>550
　　--------------
　　少なくとも"GP"GPUじゃァないなあ・・・それは。
　　--------------
確かに>>545でGPGPUと書いたのわ、言い過ぎだったす。

DX11のCompute ShaderもOpenCLもSM4.0以降が前提になってます。
はっきり言ってTegraの優位性は怪しい。

仮想敵はIntelじゃなくてAMDだろうに。
ATiのほうが組み込み向けのGPUではノウハウあるからね

NVIDIAも必死だからな。
日本法人の営業さんからして必死だもん。（あんまり言うと怒られるけど）

Tegraのデモがアレだからな。Atomの"N"270＋945GS搭載のネットブックと比較して
こっちのほうが電力効率いいですよとか

組み込み向けに作ってるのはZシリーズのほうだっつーに。
あと、SoC製品は年が明けてからだしな。45nmプロセスで周辺モジュールを統合する
という点で、ある意味NehalemのX58チップセット(65nm)より先進的なプラットフォームといえる。
＃先進的なだけで絶対性能が高いわけではないというフォローもしておく。


iPhoneをパクってWindows MobileをOSとして載せてアプリケーションのプラットフォームとして
使おうって言うならやめといたほうがいいと思うよ。
1プロセス32MBの制限に家電屋は今日も泣かされるのであった（CE6ベースだと無いんだけど）

>>553
　　---------------
　　仮想敵はIntelじゃなくてAMDだろうに。
　　ATiのほうが組み込み向けのGPUではノウハウあるからね
　　---------------
もはや存在しないような。。。
http://www.amd.com/jp-ja/Corporate/VirtualPressRoom/0,,51_104_543_1991~127080,00.html
　　================
　　先に発表された非中核事業の見直しの一環として、AMDはハンドヘルドおよびデジタルTV製品
　　事業の売却を決定しており、これらは会計報告では非継続事業※1として分類されています。
　　================

ARMは基本命令セットと基本マイクロアーキテクチャ部分はARM社に使用料を払うことで
各ベンダーで共有することができるが、拡張部分については各社の思惑で動いてて
統一の機運が見られない。
OSでいうならPOSIX以前のUNIX派生OS乱立見たいな感じだと思えばいい。

そんな中でXScaleがARMの中で優位を誇ってた時代もあったよ。
シャープのLinux Zaurusとか東芝あたりのPDAはみんなXScale使ってた。
あとはサムスン製のARM系CPUがちらほら。
ちなみにIntelはXScale製造権を手放したわけでもないしIntel謹製のネットワーク機器向けに
いまだに使われていたりもします。WMMXの商標権もいまだに保持してます。

当のNVIDIAはAtom用のIGPを作らせてくださいとか言ってる立場だったり。
http://www.digitimes.com/mobos/a20080708PD208.html
ま、現状PowerVR使ってるくらいだし、ないこともないだろうな。
X58見る限りNVIDIAとの関係が悪いわけでもないようだし。

ついこないだTegraにCUDA持って来るってのは言ってたよ（第一世代にはない）

Nvidia to offer parallel tech for mobile devices
ttp://www.networkworld.com/news/2008/111908-nvidia-to-offer-parallel-tech.html?hpg1=bn

OpenCLも組み込み視野に入れてるし、事実上競合いないからどっちが採用されても大して変わらないとは思うけど

>>556
>>540のTheINQの記事によるとMicrosoft Phoneわ来年2月に発表になるという話すから、
第一世代のチップが使用されていると思われるす。
　　-------------------
　　The phone is slated to be announced at 3GSM this coming February, so if you plan on
　　attending, please look surprised when MS unveils it.
　　-------------------
GAMA Mobile World Congress (旧名3GSM)わこちら。
http://www.mobileworldcongress.com/

>>557
あら、Tegra自体は2009Q2だって言ってるんだけどな・・・

Nvidia to Ship Tegra Chip by Mid-2009, CEO Says
ttp://www.pcworld.com/businesscenter/article/153461/nvidia_to_ship_tegra_chip_by_mid2009_ceo_says.html

>>556
それならAtomにAVXが載るのが先だと思うよ。
むしろ「LarrabeeはメインストリームCPUに統合される」って話を今するくらい無意味な話題。
どっちかというと動画再生を兼ねるプロセッサとしてはLarrabeeをカットダウンしたほうが良さそうなんだが。

どうせGeForce8400GSくらい相当のコアがMIDのTDPに収まるくらいに微細化が進んだ頃の話だろ。
Compute Capability 1.0以下を設ける気はなさそうだし。8000/900/200シリーズとそれ以前じゃ全然別物。

馬鹿満載

妄想はもう食傷気味 ＞＜
ソース付きのネタを持ってきてよ

ちょっと面白いな。汎用プロセッサとFPGAの中間みたいなものか。

【ET 2008】NECエレ、構成を変更可能なストリーム処理用ASSPを開発、FPGAよりも高性能で低消費電力
http://eetimes.jp/article/22579/

＞Pentiumデュアルコアと比較すると、単位時間当たりの処理速度が15倍に向上し、

この手の売り文句は↓を思い起こさせる
http://monoist.atmarkit.co.jp/fembedded/07ipflex/ipflex01.html
http://biblio.yamanaka.ics.keio.ac.jp/file/tecrep.pdf

N社の日本法人の某氏をして
「（ローエンド製品でのCUDAの意義は）そんなに速くならなくともCPUに処理時間の余裕ができるだけは意味があるんじゃないでしょうか」
とか自信なさげにいう代物だぜ。
ソースは俺。間違いない。

事実として8-32SP程度のローエンドGPUでCUDAやっても速くもなんともない。
処理によってはフル稼働してもCPUより遅かったりする
そんなもんをカットダウンしてモバイル向けに落とし込んでも脅威じゃねーよ。
それなら現時点であのTDPにして128bit-SSE命令を最大2つ同時実行可能（同クロックのPentiumMやK8を凌ぐ）なAtomのほうがまだ現実的で芽はあるよ。

GPGPUなんてのは本当は使いづらいけど性能がでるならということで仕方なく使うもんであって
誰も「GPUでコンピューティングしたい」訳じゃないんだぜ。変態研究者を除いて。

まぁMACオタあたりの御花畑な思考では理想のアーキテクチャに見えるかもしれないが。
本質的にはCellよりメモリの制限がきつく、用途を選ぶ。
罰ゲームでなくて何だよ。

すくなくともそのままではモバイル・組み込みには不向きだな。
SPを減らすのもありだろうけどますますマンチキンの願望とかけ離れた代物になるわな。

使える用途で使えばいいんだよ

何にでも使おうって方が間違い

お願いですからハイエンドCPUローエンドGPUの素エンコ勝負だけにしてください（心の叫び）

モバイル機器でマルチコアは流行らん。歴史が証明してる。
今までどれだけの組み込み向けプロセッサのマルチコア版がペーパーリリースで終わったよ

MACヲタは組み込みの連中の素性を知らんのだろうが
「現場の長年のノウハウ」とか言ってC++によるOoOプログラミングすら嫌ってる奴も多くない。
いまだにサブ関数を順番に呼んでいくタスクシステムの延長でプログラム書いてる。
そんな連中がマルチコアなんてまともに使いこなせるわけが無い。
CUDA？なにそれおいしいの？

最先端プロセスにものを言わせた高クロックのシングルコアのほうが圧倒的に扱いやすいだろ。

専用機能特化機構を積んだ方がよいのでは？
用途も特定しやすいだろうし

うん。
だから組み込みではASIC・システムLSIが使われてきたし、これからも使われ続ける。
それなりの汎用処理性能が求められる携帯電話向けでは、アプリケーションプロセッサが使われる。

最近名前よく聞くフィックスターズとかサイボウズラボみたいな
灯台鏡台博士を大量に雇ってる企業だけじゃないんだよソフト屋は。

日本のソフト業界を支えてるのは三流私立・高専・専門学校卒だったりする。
（従業員の平均年齢30歳未満の世界・・・あなおそろしや）

馬鹿はそれにも引っかからないから可哀想だな

>>571　そう自身を哀れむなYO

ただ、大学卒業できただけで神の子だっていう人もいるし
レベル低いよなこのスレ

ここ直しとく

×「現場の長年のノウハウ」とか言ってC++によるOoOプログラミングすら嫌ってる奴も多くない。
○「現場の長年のノウハウ」とか言ってC++によるOoOプログラミングすら嫌ってる奴も【少なく】ない。

Object-OrientedだからOoOじゃなくてOOか
しまったｗｗｗｗ

いつのながら団子さんの独壇場
おみごとです

現実は…時にﾌｨｸｼｮﾝよりも奇なり
とだけ書いておくか…

一口に組み込み向けと言ってもPCと変わらん物から8bitマイコン・4bitマイコンまであるわけで、
上位の方にはマルチコアが使われているでしょ。

車業界のMISRA-Cとか超保守的
ポインタの演算不可だってよ
まあコスト的にもシビアだからx86もありえないけど

まあ大量に数出るものについてはAtomの単価はネックになるわな。
大体にオーバースペックだろ。

Atomが狙うのは携帯電話なんかよりももっと性能が必要なレンジ。
ARMでも1GHz超えるようなものは1000円超える。
このレンジでようやく、Atomのx86資産を生かした開発効率と天秤にかけることができるわけだ。
Atomがインターネットデバイスの需要はPCから携帯機器に置き換わるって言われてる。
Intelは別に組込業界を支配しようってんじゃなくて、PCの需要がMIDシフトしていくので
飯食っていくために必然的にやらざるを得ないって話。

携帯電話などを通じて下のほうからリッチな機能を持つ支援ハードを搭載して
インターネットデバイスとしての機能強化を狙っていくのがARMやSHなどの
ハイエンド組込CPUだとすれば、インターネットデバイスとしての機能を満たすには
ほぼ十分な性能を持ったPCをベースに上のほうからコンパクト化・省電力化を
狙っていくのがローエンドx86であるAtomその他諸々。
WindowsやLinuxが動くPCをそのままコンパクトにしていく。
今年爆発的に売れたネットブックの需要も通過点。

で、いまiPhoneなんかがやろうとしてるけど、「アプリケーションの動くプラットフォーム」として
成功するには、フリーソフトも含めたソフトの充実は絶対条件だ。
そのことを踏まえ、AppleはiPodやiPhone向けのSDKを、Leopardユーザーなら無料で使えるようにした。
しかしこれもMac買わないといけないので敷居が低いとは言えない。

Atom＋Windowsベースだと、いざとなれば今使ってるPCと同じソフトがそのまま動かせるかもしれない。
これは個人を含めた開発者にもユーザーにもメリットがある。
Win32-x86向け開発ならVCはタダでも使えるし。
MSはWinCE向け開発可能なIDEをVS2008からはPro以上に引き上げちゃった。

しかもMSはCEは廃止にしてNTベースに置き換える計画打ち出してる。

>>577
いま需要が伸びてるデジタルフォトフレームなんかだと
ハイエンドクラスに使われてる石はデュアルコアARMとかもあるよ。
たいがい片方をDSPの制御に使ってたりするんだが。
あと日立の携帯はSHの2コアとか使ってるね。

しかし4コア以上はたいがいペーパーリリースで終わってる。

世界で最も多く出荷されたRISCプロセッサMIPSのサバイバル戦略
http://techtarget.itmedia.co.jp/tt/news/0811/26/news02.html

ん？
マルチコアから4コア以上に摩り替わってる気がするぞ？

ん？デュアルコアも「マルチ」コアに含めちゃって良いのか？
ちなみに2コアのうちDSP制御専用に使われて
ARMとしてプログラム触るのが1コアだけ、
ってパターンでもマルチコアって言っちゃって良い？
1コアがI/O周り専用でもう1コアがメイン処理用みたいなのもあるね。
DSがこのパターン。ARM7+ARM9で。

CPU＋コプロセッサっていうありがちな構成の延長として2コアまではいけるんだけど
それ以上はなかなか普及が進まないんだが。
メイン処理の分割はいろいろめんどうなのよ。

少なくともルネサスとQNXは2コアでもマルチコアに含んでいる、

4コアならARM11 MPCoreのNaviEngineが発表されてるやん
と思って調べたら、それを採用したアルパインの製品が出るのは2010年予定なのか

以下は組み込み開発の現実
http://web.archive.org/web/20071005074329/http://www.eetimes.jp/contents/200710/26305_1_20071004182716.cfm
http://slashdot.jp/developers/article.pl?sid=07/10/08/0814251

正直Atomは今の位置がベストだと思うけど
MooresTown出る前にSkyFireリリースされて終了じゃん？

つ AMP

はぁー

Skyfireってさ、
サーバサイドで前処理して携帯の画面表示用に表示データを落とし込むソフト連携型の「Webサービス」だよ。
Atomを蹴散らせせるほどの顧客を抱え込むことが出来るサービスとはとても思えない。
たとえばだけど、HTMLはテキストの解析からやらないといけないけど、DOMの構造をサーバ側で解析して
構造化されたバイナリデータにして送ればクライアント側のCPU負荷はそんなに少ないわけだ。
で、これが月額いくらとかだろこれ。

この手のよくある　株式会社＜商標名＞の新興企業の作るものって掲げるものは立派なんだけど
いざ実物が出てみるとメッキが剥がれて終了か、いつの間にか会社がなくなってたり
するパターンが多いんだけどあてになるの？

MSもコレと似たDeepfishなるWebブラウザ開発してるけど、MSのWebサービス部門は数年連続赤字だ。

まあモバイル機器はブラウザさえまともに動けば問題ないもんなー
JavascriptのJITの最適化がし易いアーキが勝利じゃね？

Firefox 3.1 TraceMonkey凄いな。ChromeのV8より速いぜ。
nanojitっていうらしいが

http://hg.mozilla.org/tracemonkey/file/d7d64f68423b/js/src/nanojit/Nativei386.cpp
やってることはV8と同じ。
V8はAMD64には対応してないがこっちは対応してる。

例によってベクトル化は難しいようだね
インタプリタ実行がネイティブコード実行になるだけでもJITのオーバーヘッド加味しても効果はある。

>>567-590
えっとモノ知らずのヒトに釣られているみたいすけど、基本的に機械制御等の多くの組込
分野わ『ホンモノ』の並列プロセスの世界す。
単一のプロセッサをOSがあたかも複数のプロセッサがあるように見せかけているPCと
異なって、本当に沢山のコントローラが並列動作しているすけど。。。

ｳﾞｧｶだねぇそれ言ったらPCのほうがより多くのプロセッサが走ってるよ

だから汎用プロセッサのコア数について話してんだって

UMCが45nm HKMGプロセスの検証を終了したとのことす。
http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=212200407
　　-----------------
　　United Microelectronics Corp. has validated its high-k metal gate process with a test
　　SRAM design run at the 45nm node. The move is a step toward the company's goal of
　　offering a high-k process at the 32nm node in 2010.
　　-----------------
量産わ32nm世代からとのことす。

一口に組み込みといっても、クルマのように百単位のものからリモコンのような1個のみまであってだな・・・

複数の専用プロセッサを使うことになると言ってもモジュール毎に開発グループが違うからな。
汎用コア複数だと1グループで複数のCPUをどう使うか考えないといけない。

>>588
Deepfishは死にました。

>>596
> 複数の専用プロセッサを使うことになると言ってもモジュール毎に開発グループが違うからな。
> 汎用コア複数だと1グループで複数のCPUをどう使うか考えないといけない。

(μITRONでいう)タスク分割は組み込みの基本ですがな。
スケジューラも一般に単純だからタイムスライスでラウンドロビンなPCより
注意深く設計しないといけないよ。

東京工業大学が世界初の大規模GPGPUコンピューティング基盤を大規模スーパコンピュータ基盤TSUBAME上に実現
http://www.gsic.titech.ac.jp/contents/news.html.ja?page=News/2008/1119/01

らしいです
既出ですっけ？

>>599
10TFも実効性能上がらなかったんだな。実効効率50%切っている。
4種類のプロセッサを協調させるのは容易ではないんだな。
京速計算機はスカラベクトル混合になるらしいけど大丈夫なんだろうか？
Linpackでも効率出にくいのに実際のアプリケーションで連携させるとなると
更に難しい気がしてしまう。

そんなことよりこいつを見てくれ。こいつをどう思う？
ttp://www.intellasys.net/index.php?option=com_content&task=view&id=60&Itemid=75

メモリスタ、来まスタ。

HP社、3次元構造のメモリスタ・チップを発表（2008/11/28）
http://eetimes.jp/article/22593/

>>601
非同期型というのは珍しいと思う
forthチップは昔から根強い人気
ゼロサイクル通信萌え

>>600
京速のベクトル部は飾りです
偉い人にはそれがわからんのです

ベクトルと言えば、牧野教授がSX9について語っているす。
http://www.artcompsci.org/~makino/articles/future_sc/note067.html#rdocsect72
　　------------------
　　これを x86 PC と比べると、例えば Opteron で DDR2-800 2チャネルだと理論値は1ソケット
　　12.8GB/s ですが実力はまあ 7GB/s くらい、これが Core 2 になると同じ理論値で実力は
　　5GB/s 程度まで低下します。
　　これは面白い状況で、 x86 並列機をソケット 100万で買うとメモリバンド幅 1GB/s 当りのコスト
　　は 14-20万円ですが、 SX9 が1ノード2億円だとすると (地球シミュレータセンターの買い値は
　　もうちょっと安いです)1GB/s 当りの価格は7万円となって、大きな差があるわけです。
　　------------------
安易にベクトル機を叩くヒトもモノ知らずに過ぎないらしい。。。ということで。
その他面白いコメントわ、こんな感じす。
　　-------------------
　　　1年前の議論で若干問題だったのは、 x86 のメモリバンド幅を理論ピーク値で評価している
　　ことです。Opteron (少なくとも 1ソケットや2ソケットなら)はまあ実力がピーク 6-7割がでるの
　　でそれほど大きな乖離はないのですが、 Core 2 は4割くらいしかでないので結 2.5倍の差に
　　なり、2倍程度の差を議論している時には結論が変わってきます。
　　　これは、HPC でベクタ向けに書かれたアプリケーションだと、Opteron のほうが Core 2 より
　　も速いこともある、ということでもあります。
　　-------------------
同時期に設計されたプロセッサにわ、優劣わ無く向き不向きがあるだけという普通の話かと。

MACヲタﾀﾀﾀﾀﾀｱｱｱｧｧｧｧ...

参考までに今回、牧野教授がやっていたSTREAM Benchmarkの最新x86プロセッサによる結果す。
http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8796_8800~128935,00.html

>>607
そこにNehalemも載せると楽しいだろうな

>>608
リンク先読めばわかるが、

もちろん、来月になって Nehalem がでてくるとメモリバンド幅の実力が Core 2 に比べて
3倍程度になるようなので、SX9 と同等になり、メモリバンド幅当りのコストとしては地球
シミュレータ当時と同様に x86 ベースの高い計算機とベクトル機で同等、 x86 で安く上げる
ことができれば1桁良い、ということになります。

とも言ってるぞ。

>>608
　　-----------------
　　そこにNehalemも載せると楽しいだろうな
　　-----------------
Intelによる準公式の数値わ、下記の通りす。
http://journal.mycom.co.jp/articles/2008/09/02/hotchips4/index.html
　　==================
　　Stream Benchmarkで測定したメモリバンド幅は、現状のCore 2プロセサであるHarpertown
　　では、クロック3.0GHz、FSB 1600MHzのチップに800MHzのDDR2メモリをつけた場合は
　　約9.8GB/sであるが、2.66GHzクロックのNehalemに 1066MHzのDDR3メモリを接続した場合
　　は33.4GB/sと3.4倍の向上を示している。
　　==================

>33.4GB/sと
3ch DDR3 1066MHzの理論地より増えているんだが

>>611
2-socketシステムでの値だと思われるす。

大規模共有メモリがSXの大きな利点かと思っていたけど、
同程度のコストパフォーマンスなら楽できるSXの方が選ばれるだろうから
メモリバンド幅が壁になる分野ではマルチノードシステムも有用なんだな。

似たような理由で、東大の情報基盤センターでも
ピーク性能が圧倒的に高いT2Kよりメモリバンド幅重視&大規模SMPのSR11000の方が
遥かに重用されてるらしい

LINPACKは通信量のオーダが計算量に比べて低いので、飾りにしかならないんだと

>>614
それ、大学の計算機センターという利用形態のために複数ノードをまたぐような並列化アプリが
少ないというだけでわ？
箱の中だけで完結する並列化しか行っていない場合わ、当たり前だと思うす。

おそらくT2K仕様も、スーパーコンピュータとしてのコストパファーマンスの悪い4-socketノードを
選択したのも、同様の事情を考慮したものと思われるす。

なんとなく牧野教授の『スーパーコンピューティングの将来』シリーズの過去記事を読み直して
いたすけど、半年前のRoadrunnerの1PFlops越えについて、こんなこと書いているす。
http://www.artcompsci.org/~makino/articles/future_sc/note062.html
　　-----------------------
　　とはいえ、やはり、ボード 4 枚も使って CELL 4 チップ、400Gflops というのは、Opteron
　　とか Xeon だけのとどれくらい違うの？というのは非常に微妙なところでしょう。 同じボード
　　4枚構成で、Quad Core Xeon E5450 が載った IBM HS21 を使えばほぼ同じ性能が消費
　　電力も大きな差なしで実現できそうだからです。
　　-----------------------
今回のTop500で示された現実わ、下記の通りす。
　- x86 (K10/2.3GHz):　　　1.059 PFlops, 6.95MW, 444.9 MFlops/W
　- Cell (PowerXCell 8i):　 1.105 PFlops, 2.48MW, 152.4 MFlops/W
http://www.top500.org/list/2008/11/100
http://www.green500.org/lists/listdisplay.php?month=11&year=2008&list=green500_200811.csv&start=1&line=101

MACヲタタタタタタタタｱｱｱｱｱｱｱｱｱｱｱｱｱｧｧｧｧ……

算数が出来ないMACオタ

>>616わ電力効率が上下ひっくり返っていたす。
　誤)
　　- x86 (K10/2.3GHz):　　　1.059 PFlops, 6.95MW, 444.9 MFlops/W
　　- Cell (PowerXCell 8i):　 1.105 PFlops, 2.48MW, 152.4 MFlops/W
　正)
　　- x86 (K10/2.3GHz):　　　1.059 PFlops, 6.95MW, 152.4 MFlops/W
　　- Cell (PowerXCell 8i):　 1.105 PFlops, 2.48MW, 444.9 MFlops/W

だが情報収集だけなら人一倍だぞ

東工大、世界初のGPU採用スパコンに進化した「TSUBAME 1.2」を解説
〜NVIDIA CEOフアン氏は特別講演を実施
http://pc.watch.impress.co.jp/docs/2008/1203/nvidia.htm

量子色力学計算用の専用システムQCDOCがBlue Geneの先祖だったことを知っている方も
多いと思うすけど、PowerXCellをコアにした専用システム"QPACE"を紹介するす。
今回もIBMがスポンサーになっているすから、次世代Blue Geneわ似たようなモノになる可能性
もあるす。
http://www.itwm.fhg.de/hpc/workshop/mic/Qpace_(Dirk_Pleiter_-_Desy).pdf

４８時間以内に退職を選ばないと解雇する
正社員削減「このままだと自殺者」
http://www.asahi.com/national/update/1203/TKY200812030253.html

>>622
これQCDOCに比べてあまりQCD計算専用と言えるような作りではないよね？
LS増やすかeDRAM付けるとか、そういうのはお金掛かるからダメなのかな。

QCD専用機ｲﾗﾈ
理由：役に立たないから

QCDなんぞGPGPUでいいわ！
んじゃ次世代BlueGeneって何よ…
それこそTSUBAMEライクになるんか？

日本IBM「加藤候補を3000人創出します」
http://dubai.2ch.net/test/read.cgi/news/1228331260/

>同労組には、これまでに７０〜８０件の相談が寄せられているという。
_~~~~~~~
ほっとけつーのｗ こういう和田岩。本質に関係ないから。

理研、Nehalemで108TFLOPSの大規模クラスター　富士通が受注
http://www.itmedia.co.jp/news/articles/0812/09/news012.html

VIAを振った甲斐あってか、Nvidiaがatomのチップセットビジネスにありついた模様す。
http://www.digitimes.com/news/a20081209PD206.html
　　----------------------
　　Nvidia chipset support to come for Intel Atom nettops
　　Monica Chen, Taipei; Joseph Tsai, DIGITIMES [Tuesday 9 December 2008]

　　　Intel and Nvidia will join forces to enable Nvidia chipset support to the Atom platform
　　in order to enhance graphics performance, according to sources at PC vendors.
　　　Nvidia's MCP79 chipset will be the first to support Atom CPUs, however the support
　　will only apply to nettops during the initial period.
　　　Asustek Computer, Gigabyte Technology and Micro-Star International (MSI) have said
　　they welcome the partnership between Nvidia and Intel and believe the cooperation
　　would give them more pricing flexibility.
　　----------------------

それはviaにとって朗報ですね
MACみたいにならなくてすむ

IntelはNVIDIAの首に鈴をつけるような真似しないでとっとと買収しちゃえばいいのに

中国のファウンダリ企業SMICも45-nmプロセスでの生産を開始したとのことす。
http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=212300071
　　---------------------
　　Semiconductor Manufacturing International Corp. (Shanghai, China) has said that it
　　has produced its first 45-nm yield lot, signifying a working 45-nm manufacturing process.
　　This has been achieved less than one year after SMIC signed an agreement with IBM
　　to license its low-power and high-performance bulk CMOS technologies in December 2007.
　　---------------------
記事に書いてある通り、SMICわIBM連合のバルクプロセスを導入しているす。

OpenCL 1.0の仕様が公開されたす。
http://www.khronos.org/opencl/

Roadrunnerの電力効率について言えばCellに混じって少し載ってるOpteronが足を引っ張ってるんだよな。
全てQS22で構成してればさらに電力効率上がってたのに。
次世代CellではPPEもパワーアップするらしいからデバイス制御用にOpteronを入れる必要もなくなるだろうな。

全部QS22だったら実行効率1ペタはなかったろうな

どのようにしたら、そんな一個か二個の数値で
コンピュータの善し悪しを決めつけられるまで
脳を退化させることができるかね…

Windows向けのOpenCL対応処理系ってどこが用意するの？

OpenGLはMSVCも含め多くのWindows向け商用コンパイラが対応したけど
DirectXのCompute Shaderと直接競合するようなものをMSが支持するわけもなく。

まあデファクトスタンダードの断裂は確定したようなもんだ。

すこしそれるが、OpenGLとDirectXは同列かな？
まいいけど

OpenCL(CUDA) vs Ct vs DirectXという認識でおk？
CtはTBBの正統進化系で中身はOpenMPという認識でおk？

アキバ　秋山　飽きてきた。　アーティクル。

なんで言語とライブラリーが…
まいいや、語るも疲れる…

CgとHLSLが似てる程度にはCompute ShaderのそれもCUDAには似せてくるんじゃないかな。

で、ECMA標準規格に登録したりして混乱させるかもしれんね。
.NET Framework互換環境のMonoでWindows.FormがWineに依存だったりする程度に
MS環境依存なものになると。いつもどおり。



>>642
Javaは言語でありライブラリであり仮想マシン（ランタイムプログラム）であるけど
MSのC#はあくまで言語で、ライブラリはWindows.Formやその他諸々で実行環境は.NET Framework

まあそんなモンいちいち気にするのは不毛だ。

　

＞MonoでWindows.FormがWineに依存だったりする程度に
↓ページを嘗め回すように一読・・・しなくていいや、もう過去の話だし、こっちの方が面白い ttp://tirania.org/blog/archive/2008/Nov-03.html
ttp://www.mono-project.com/WinForms

こういうスレばかり見てるから
コテ＝馬鹿ってのが摺り込まれてしまうんだなあ

OpenCLってメニーコアでソフトウェアレンダリングエンジンを書くのが主な目的なのかな。
Specification見たらそんな気がした。
結局一番得しそうなのはIntelかな。大学にエンジン書かせてそのままLarrabeeに持ってくっていう

【社会】経団連の御手洗会長、大分キヤノンの非正規雇用削減問題について「かなり誤解があったようだ」
http://mamono.2ch.net/test/read.cgi/newsplus/1228732999/608

608 名前：名無しさん＠九周年[sage] 投稿日：2008/12/11(木) 01:38:17 ID:8UUJtlZR0
競争力という危険な幻想

　つまり国と国も企業同士のように「食うか食われるか」の熾烈な競争を展開しており、
これに破れれば国が滅びるというのである。ここから「貿易戦争」「経済戦争」などとい
う言葉も生まれてきた。この戦争に勝つためには、「競争力」をつけなければならない
という主張である。
　クルーグマンはこうした「競争力至上主義」の経済学を、正統な経済学では明確に
否定された「俗説」であるという。そして、こうした俗説があたかも正統な経済理論のよ
うに流布し、幅を利かせている現状を、世界にとってとても危険な状態だと警告している。


> 正統な経済学では明確に否定された「俗説」である ｗ


先進国のほとんどで、交際競争力への懸念が高まっているが、それを裏付ける事実
があるわけではなく、逆に、的外れであることを示す大量の事実があるなかでも、
そう信じられているのである。しかし、そう信じたがっている人たちが多いのも、明らかだ。
競争力の教義を説く人たちが、主張を裏付けようと、ずさんで間違いだらけの数値をあ
げる傾向があることを見れば、この見方を信じたいという欲求がいかに強いかがわかる。

http://www.enpitu.ne.jp/usr/bin/month?id=7246&pg=200405

裸の王ｻﾏと同じく、みんな喉元まで出かかって、あえて黙っているお為ごかしをﾊﾞﾗしやがってｗ
まんざら遠大なる誤爆でもなさげだな…

水面下では某国と某国が今経済戦争してるってこと？
今回の金融危機も国家レベルの謀略？
それとCPUアーキテクチャがどう関係するの？

尻の蒼い、嘴の黄色い、駆け出しの青二才には
分からないとしても、無理はないか

どうでもいいが、一々クソスレageんなよ、うぜーよ
禿げどもが

>>649
お為ごかしじゃないんだという事を言いたいんだろ>>648は

他人の日記にケチをつけるのも失礼かとわ思うすけど、牧野教授の公開日記
http://www.artcompsci.org/~makino/journal/journal-2008-12.html#8
　　----------------------
　　まず、 Nehalem, Phenom II でのコスト概算は
　　Nehalem:
　　CPU i7 920 30k
　　マザーボード FOXCONN Renaissance 28k
　　メモリ DDR3 2GB x 6 45k

　　Phenom II
　　CPU Phenom II 940BE 30K
　　マザーボード K9A2 Planinum 14K
　　メモリ DDR2 4GB x 4 40k (2GBx4 ならもっと安い、、、)

　　電源 安く上げるなら 600W クラスのを2台、 14K
　　　 普通なら　　　1200W x 1 　　　　　　　　25K

　　というわけで、もっとも高いと 128k (Ci7, 1200W)
　　　　　　　　　　　　　　　　安いと 98k (PhII, 600Wx2)
　　----------------------
電源が異常に巨大な気がするすけど、GPGPUとかGRAPE-DRの母艦なんすかね。。。
ECCも気にしていない模様すけど、最近のHPCクラスタ用のノード仕様ってこんな感じ
なんすか？

失礼。。。

マキーノ日記にCore i7 920のSTREAM Bench来たよ

Ci7 920 での STREAM (OMP+SSE版)
./stream-omp-sse
-------------------------------------------------------------
This system uses 8 bytes per DOUBLE PRECISION word.
-------------------------------------------------------------
Array size = 51200000, Offset = 0
Total memory required = 1171.9 MB.
Each test is run 10 times, but only
the *best* time for each is used.
-------------------------------------------------------------
Your clock granularity/precision appears to be 1 microseconds.
Each test below will take on the order of 76557 microseconds.
(= 76557 clock ticks)
Increase the size of the arrays if this shows that
you are not getting at least 20 clock ticks per test.
-------------------------------------------------------------
WARNING -- The above is only a rough guideline.
For best results, please be sure you know the
precision of your system timer.
-------------------------------------------------------------
Function Rate (MB/s) RMS time Min time Max time
Copy: 18926.6056 0.0436 0.0433 0.0443
Scale: 15997.1965 0.0513 0.0512 0.0515
Add: 17925.6354 0.0687 0.0685 0.0688
Triad: 18027.3972 0.0684 0.0682 0.0687

Function　　　Rate (MB/s)　　　RMS time　　　Min time　　　Max time
Copy:　　　　　18926.6056　　　　　0.0436　　　　　0.0433　　　　0.0443
Scale: 　 　 　 15997.1965　　　　　0.0513　　　　　0.0512　　　　0.0515
Add:　 　　 　　17925.6354　　　　　0.0687　　　　　0.0685　　　　0.0688
Triad:　　　　　18027.3972　　　　　0.0684　　　　　0.0682　　　　0.0687

下5行のズレ修正。
プレビュー見なかった結果がこれだよ！

やるならきっちりやれ

Function　　　Rate (MB/s)　　　RMS time　　　Min time　　　Max time
Copy:　　　　　18926.6056　　　　　0.0436　　　　　0.0433　　　　0.0443
Scale: 　 　 　 15997.1965　　　　　0.0513　　　　　0.0512　　　　0.0515
Add:　...　　　　17925.6354　　　　　0.0687　　　　　0.0685　　　　0.0688
Triad:....　　　　18027.3972　　　　　0.0684　　　　　0.0682　　　　0.0687

ふ〜ん、他のｃぷのstream性能は具体的な数値を覚えていないが
stream見たいに単純な構造をしたﾌﾟﾛｸﾞﾗﾑのﾍﾞﾝﾁにおいてすらも
PC用のCPUが結構いい性能を出すようになったってことじゃないのｺﾚ？
おっそろしいのはi7は、HPC分野に良くある直線番長型CPU(wと違って
ｺｰﾅﾘﾝｸﾞも速けりゃ、入り組んだ道も速い、しかも金になる市場でｼﾞｬﾝｼﾞｬﾝ売れる
その昔、川下産業とかいってﾊﾞｶにされていたが、よもやここまでくるば勝負あったな。ﾆﾔﾘ。
ｵﾚは今のIntelを(AMDもだがｗ)応援してるぜ。その方がﾕｰｻﾞにとってもIT分野にとっても
そこではたらくエンジニアにとっても吉だ。今はな。

デスクトップ用途としては、あとは順調に改良が進んで消費電力が減ってくれれば
文句なしなんだけどね

…ノートPC用が問題なわけよ…Havendaleがオオコケしなければ…
来年出なけりゃもう45nmはないってことじゃん

他と比べてくれなきゃどれだけすごいのか分からんが

上記ベンチなら、core2duoの3倍弱くらいか？
演算器とのバランスという意味ではそこまでの改善ではないが、大したもんだぜ

それにしてもP6アーキも長持ちするな
ハイエンドx86もPOWER6やRockのようにインオーダーベースになる日は来るのかね

RockはOoO Retirementじゃなかったっけ

インオーダーベースを改造してOoOを実現している、と言えばいいか

Rockは肩透かしだった・・・

>>659
ッフ、、x86の小汚い命令セットごときが何をたわけたことをほざいておる！！

>>663
Power6はクロック電力を抑えクロック上げるためにインオーダーにした。

>>667
バーカ

>>667 >>668
とか言ってるが、実際にはx86CPUの自作PCしかつかったことがないし
RISCマシンを使う意義も見当たらん。
一応、最近安くBlade150(ultraSparc�A550Mhz)を買ったが、「この程度か
」といった感想だな。

長いのでXeon 5130 OpenMPでスレッド4つの結果だけ抜粋

STREAM results for Core 2 CPUs
ttp://www.cs.virginia.edu/stream/stream_mail/2007/0018.html
***** Dual Xeon 5130 on Supermicro X7DBE (IntelR 5000P (Blackford) Chipset)

### OMP_NUM_THREADS=4
----------------------------------------------
Double precision appears to have 16 digits of accuracy
Assuming 8 bytes per DOUBLE PRECISION word
----------------------------------------------
----------------------------------------------
STREAM Version $Revision: 5.6 $
----------------------------------------------
Array size = 20000000
Offset = 0
The total memory requirement is 457 MB
You are running each test 10 times
--
The *best* time for each test is used
*EXCLUDING* the first and last iterations
----------------------------------------------
Number of Threads = 4
----------------------------------------------
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
----------------------------------------------------
Your clock granularity/precision appears to be 1 microseconds
----------------------------------------------------
Function　 Rate (MB/s)　　 Avg time　　 Min time　　 Max time
Copy:　　　 6194.1117　　　　 0.0517　　　　0.0517　　　　0.0519
Scale:　　　4893.0285　　　　 0.0687　　　　 0.0654　　　　0.0943
Add:　　　　5271.2542　　　　 0.0923　　　　 0.0911　　　　0.1017
Triad:　　　 5279.5896　　　　 0.0944　　　　 0.0909　　　　0.1216

長いので適当に抜粋

Stream result for AMD Opteron 2360SE "Barcelona"
ttp://www.cs.virginia.edu/stream/stream_mail/2008/0008.html
-------------------------------------------------------------
This system uses 8 bytes per DOUBLE PRECISION word.
-------------------------------------------------------------
Array size = 4000000, Offset = 0
Total memory required = 91.6 MB.
Each test is run 10 times, but only
the *best* time for each is used.
-------------------------------------------------------------
Number of Threads requested = 8
-------------------------------------------------------------
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
-------------------------------------------------------------
Your clock granularity/precision appears to be 1 microseconds.
Each test below will take on the order of 28773 microseconds.
(= 28773 clock ticks)
Increase the size of the arrays if this shows that
you are not getting at least 20 clock ticks per test.
-------------------------------------------------------------
WARNING -- The above is only a rough guideline.
For best results, please be sure you know the
precision of your system timer.
-------------------------------------------------------------
Function 　　Rate (MB/s)　　 Avg time 　　Min time 　　Max time
Copy:　　　　 17942.3472　　　 0.0036　　　　 0.0036　　　　0.0036
Scale:　　　　 17856.4130　　　 0.0036　　　　 0.0036　　　　0.0036
Add:　　　　 　17259.7704　　　 0.0056　　　　 0.0056　　　　0.0056
Triad:　　　　 17341.5386　　　 0.0055　　　　 0.0055　　　　0.0056

この手の物ってArray size違うもの同士比較していいの？

STREAMをキャッシュ効くような設定で計測する人はいない、、、と思う。

>>670 >>671 実測しくれてて�dｸｽｺ。
memory throught neckに持ち込むとOpteronも結構頑張る傾向は出てますね。
まぁmemory throught勝負は、最後の砦なのかもしれないがｗ
がーしかーし、

Array size = 20000000
The total memory requirement is 457 MB
Number of Threads = 4

Array size = 4000000, Offset = 0
Total memory required = 91.6 MB.
Number of Threads requested = 8

これはちょっとどうかと思ったけど、大勢にはたぶん影響なさげだね。
ｵﾚも暇があったら職場の…いや時間まるっきり無いの介…orz

ちなみにCPUがmemory throughtばかりを前面に出し始めたら黄信号かな
(商売がじり貧で先がなくHPC分野に逃げ場を探している)とｵﾚは見ている。
今までの経験からそう感じているだけだが。

ほな乙かれさん、お先です。ﾉｼ

HPC用途だとどうせクラスタなんだから、CPU単体のスループットよりは価格性能比、電力性能比のが重要と思う。

ネットワークが安くて高速に出来るのなら確かにそうなんだがな

質問。某KumaさんはPentium E5x00よりキャッシュの総容量が多くて、メモリアクセスが全然速いはずなのに、
せいぜいドッコイの性能しか出せないのは何故？

ループ特化してないから

256bit版AltiVecとか出して欲しいんだけどね。
このまま色褪せていくのは惜しい。

てな話を、PPCマカーの人と話してました。






2chにPowerPC最適化プログラミングについて語るスレが無いことに気がついた。

>>679
ようMACオタ
コテ間違えてるぞ

俺はMACヲタとは違う観点でPowerPCの設計を評価してるからな。

興味本位で聞くけれどPPCのどこを評価しているの？
PPCはasmの視点から見ると、きれいと言うより以外と複雑な面があるよ
あるよ、というかあったよという印象の記憶があるだけだけれどもさｗ
ちなみにｵﾚはPPCも嫌いではなかったりする。
えぇ、CPUと女には節操がないものでｗ

AlphaとPOWERとx86は好きでPAとARMは微妙でMIPSとSPARCと68kの嫌いな俺様が

・レジスタ本数が多すぎず少なすぎない
・3オペランド

x86に比べてエレガントな割には実効性能が悪いのは玉に瑕

ふ〜ん、その程度なの…いや悪い意味じゃなくて。
ｵﾚが気に入っていた点は例えば
・FPレジスタ構成がflat、そこへqloadで2x倍精度一気に読めて
　load throughputと倍精度ＦMA演算throughputがバランス良く稼働できたこと
・FMA命令がタイミング良く決まるとclock×2×2の演算性能が発揮できたところ
　（といってもlinpacなど極端に有効な用途はそれ程広くなかったが）
・GR個数がそこそこあってlist引きのAU計算にゆとりがあったところ
　（といってもstreamの細い短いpipeline長のloop限定）
・特に初期のPower、3あたりまでは周波数が低い分各種latencyが小さく、
　ミスっても起きあがり小坊師のようにずっこけてもすぐ立ち上がり走り出して
　極端なstallが起きにくくLispなどlsitの嵐やあるいはcache hitの見込めないアプリで
　失速が少な目だったこと
etc.etc…
逆にイヤだなと思った点は
・(ry
etc.etc…
まぁいいや、いいこだからもう寝なさい。

Shanghaiの4S構成で公式に登録が来たのでまとめてみた。

Dunnington 2.66GHz 4Sockets/24Cores/24Threads
Number of benchmark users & comp.: 5,300 SD (Sales & Distribution)
SAPS: 26,550
http://download.sap.com/download.epd?context=40E2D9D5E00EEF7C9B0CC4EEC41DA7C8FD6BCD35CDB5238BFD97E1A7A4A02389

Nehalem-EP 2.93GHz 2S/8C/16T
Number of benchmark users & comp.: 4,995 SD (Sales & Distribution)
SAPS: 25,000
http://download.sap.com/download.epd?context=40E2D9D5E00EEF7C98569165701A8C64017D9991F441020572812DEF4019E6C6

Nehalem-EP 2.93GHz 2S/8C/8T (スレッド数はAnandtech予測)
Number of benchmark users & comp.: 4,715 SD (Sales & Distribution)
SAPS: 23,650
http://download.sap.com/download.epd?context=40FA5C91FAAE3E61F95E567201A0045C4AC5DB17A6F22BD05281664F5BE58A6C517AFA8A2AB0C666

Dunnington 2.66GHz 4S/24C/24T (RHEL5.2 + XEN3.1の仮想マシン上で計測)
Number of benchmark users & comp.: 4,400 SD (Sales & Distribution)
SAPS: 22,030
http://download.sap.com/download.epd?context=C204AB680DC3C9C9621499C46000FB4D27B9BB1C32A022E35CD002D8D1364FFF2C067F2EE98B60A97B32ABA7B53B398F

Shanghai 2.7GHz 4S/16C/16T
Number of benchmark users & comp.: 4,386 SD (Sales & Distribution)
SAPS: 22,000
http://download.sap.com/download.epd?context=C204AB680DC3C9C99E517E3F38CDECBD48373813E84BE4BBDD5752F147180BEEBEB9071EC1B5ACB3

Shanghai 2.7GHz 2S/8C/8T
Number of benchmark users & comp.: 2,752 SD (Sales & Distribution)
SAPS: 13,780
http://download.sap.com/download.epd?context=40E2D9D5E00EEF7CC1A4F3F5AAA2A28343EF5EEFABD344FBD4BC7E5F39ABE5A9


Shanghai 2.7GHz x 2を1とした時の相対性能
Dunnington　　　Nehalem 2S/16T　　　Nehalem 2S/8T　　　Dunnington with Virtualization　　　Shanghai 4S　　　Shanghai 2S
　　1.92　　　　　　　　　1.81　　　　　　　　　 　1.71　　　 　　　　　　　　 　　1.59　　　 　　　　　　　　　　1.59　　　　　　　　　1.00

まとめを作成するきっかけになった記事
Intel Xeon 5570: Smashing SAP records
http://www.anandtech.com/weblog/showpost.aspx?i=532

ISAと実装がごっちゃになっとるぞw
不可分といえば不可分だが、実装の足を引っ張りそうなISAってあるだろ、そういう話はない？
MIPSだと比較と分岐が1命令になっているところとか。

ISAにあった実装しかできないってのもある。
2引数しか取れないのに積和算ユニット載せても無駄だろ？

Intelは「実装」のためにISAを拡張していってるし
ある程度は不可分じゃね？


特にAVXの3〜4オペランド化なんか重大な変革だと思うけどね。

LNIとの整合性はどう取るつもりなんだろうか。
MMXみたいな扱いになるか

IPCの意味が悩ましくなるがまんざら無駄ではないのでは？
まぁいいけど

x86は速い
これは動かしがたい事実だ
何か本質的なところで優れたISAだとしか考えられない
これはむしろx86 ISAは実装の足をクリティカルにひっぱる要素が比較的少ないからではないか

俺は紳士じゃないんでね
諦め悪いんですよ

というかだから没落するんだ
なぜ・・・ なぜ最後まで戦わない・・・
この 闇

>>692
これはむしろ、の前に
確かに古臭いし欠点だらけのように見えるのだが
が抜けた

レジスタウィンドウや遅延分岐スロットみたいに当時は気の利いたアイデアが後々祟るというのがx86には意外と少ないんじゃね？ということだ

>>692
x86は単にコード資産が多いから、資金が集まり
何が何でも延命させようと巨額のお金がつぎ込まれた

ってことに過ぎない
単に規模の論理で他社には出来ない額の超大規模投資で最新理論で設計
最新プロセスで省電力低発熱を実現できたので
x86の根本的な欠陥をごまかし続けられた

ってことに過ぎない

たられば厳禁だが、おなじ開発費と製造プロセスでPowerPCを作れば
1.5倍くらいの性能のあるものを作れるだろう

>>695
たったの1.5倍程度?

>>695
そう、けっきょく根拠もなくタラレバでしか言えないのよね

そもそも、古い設計に金かけて高性能になるためには元の設計が優れたものである必要があるんだ

AMDがそんなにリソースリッチとも考えられないしね

x86がハードウェアソフトウェア両方の拡張に耐えうる十分に優れたISAである、ということは確かだろうけど、
だから他のISAと比べて優れている、というのはあまり適切ではないとは思うが・・

いや、べつに他のISAより優れているというつもりはなくて、
・ISAには皆が指摘するような明らかな欠点を数多く抱えている
にもかかわらず
・高性能な実装が存在する
のはなぜか？ということ

・指摘者が揃ってボンクラで、実はx86 ISAの明かな欠点はごく表面的なもので本質的ではないのか
または
・本当にシビアな欠点をかかえているが、それを帳消しにするほどには本質的なところで優れているのか
のどちらかなのかを知りたいということ

>>695
どうせならARMでヨロ。

そういやStrongARMって、その方向を目指してたんだっけ？

>>701
ARMは開発当時のプアなリソースに最適化されていて、将来を見越したアーキテクチャという気がしないよね
何十年先を見通すことは不可能だけど、悪い意味でのhackが多すぎる>arm,hppa,mips.sparc

x86はあまりにもクソすぎてそういうhackすら不可能だったのが災い転じてというのはありうるな
ia64はパッとしないままだがw

プロセスルール開発。
プロセス毎に物理デザインを行うツールの開発・カスタマイズ。

この2つに徹底的に経営資源を投下。
微細化とトランジスタ密度の勝負に持ち込んで、
パフォーマンス÷ダイ面積で優位に立ち、他社を赤字に転落させる。

優れたあーきてくちゃあ開発とやらに資源を投下して、
巷で評価されつつ市場から退場していった幾多の企業の反面教師。

>>704
単価は？
AMDは？IBMは？

ARMは悪くないよ。元々組み込み特化の汎用コントローラじゃないか
PCとかHPCとかに使うわけでもないし。

AtomとハイエンドARMは競合する可能性があるわけだが、Atomからすればx86資産ありきの勝負だからね。
電力効率面でARMに対する優位性はあんましない。現状ね。

Cortex-A9(ARMv7)のNEON拡張命令って使ってる人いる？

128bit版ってさ、ただの64bit版2回実行だったりしない？

ARMはもともとパソコン用だったんだけど

前身？の6502とかAcorn RISC MachineまでのARMはね。

AcornからスピンオフしてAdvanced RISC MachineになってからはApple Newtonへの採用からはじまり
モバイル向けとしての色合いを強めていった、と。
今ではMIPS、SHをしのぎ、年間30億個、Intelプロセッサの10倍売れてる。個数だけは。

ARMは最初はあくまでパソコン用に設計されたんだよ。wikipediaでもなんでも見てくれ。
現在ではパソコンにもHPCにも使われないけど
> 元々組み込み特化の汎用コントローラ
これだけ訂正してくれ

ARMもPOWERもx86もそれぞれ利点・欠点があるのはわかる。
ただｱﾎﾟｰみたいにころころCPUを変えるのはおかしい――
と思ったら禿げが死にかけだったか

今度のMacはARMかPOWERになる予定でもあるのか？

今度のMacはH8になります

>>712 713
ないない、しばらくはintelだろ。

iPod の CPU は ARM系？

コード密度の観点からは H16 なんか面白かったのにな。
利点はキャッシュにヒットしやすいことくらいか？

>>715
ARMだね。
俺はただ単にNewtonの血筋が未だに残ってるもんだと思ってるが。

現実問題としてARM以外の選択肢はないも同然だったわけだが
血筋などとキモい事をよく思いつくものだとちょっと感心している
NewtonでARMの経験を積んでいたからとでも言えばいいのに

ジョﾌﾞｽがまた具合悪いの?
あのｵｯﾁｬﾝ、ｸｾが強いけれど、いなくなったら寂しい…

安心して
レトリック君はいなくなっても寂しくないよ

昨日の安藤氏のサイトのIEDMネタより。
http://www.geocities.jp/andosprocinfo/wadai08/20081220.htm
　　------------------
　　　45nm世代ではIntelだけがHigh-K Metal Gateだったのですが，32nm世代では各社ともにHigh-K
　　Metal GateでEOTでは1nmを切るゲート絶縁膜を実現しています。また，露光は液浸のArFです。
　　　TSMCは，予稿では32nmと書かれていたのですが，本番の発表では28nmに書き換えた発表を
　　行い，EOTは0.9nmでゲート長は 24nmでOn電流はN-trが1360uA/um（@80nA/um），P-Trが
　　960uA/um(@40nA/um)と発表されました。しかし，ゲートピッチは100nmとのことで，他社の32nm
　　とあまり違わない気がします。
　　　Intelは第二世代のHigh K/Metal Gateと称して32nmプロセスを発表しました。EOTは0.9nmで，
　　On電流はN-trが1550uA/um(@100nA/um)，P-trが 1310uA/um(@100nA/um)と発表されました。
　　　SRAMセルは0.171um2と32nmプロセスとしては大きめのセルで，Intelは動作安定度を重視して
　　セルサイズを極限まで小さくするという方針でないのは45nmの時と同じです。
　　　このIntelの32nmプロセスのTrのOn電流はTSMCより大きいのですが，Off電流もTSMCより大
　　きく取っているので，見掛けほどの差はなく，技術的にはTSMCが急追している感じです。
　　------------------
大手ファウンダリ企業のプロセスがIntelに追いつき、新興企業がアーキテクチャ勝負の商売を
できるようになる日も遠くないのかもしれないす。

どのみちASICじゃフルスクラッチのプロセッサに勝つのは無理だけど。

TSMC、45nmプロセスの量産を9月より開始
http://pc.watch.impress.co.jp/docs/2007/0413/tsmc.htm
プロセスの提供を開始する時期だけならTSMCはIntelに追いついていたと思うの
TSMCの場合プロセスの提供開始からそれを利用した製品の販売まで結構なタイムラグがあるようなの
設計やバグ取りや製造で時間がかかるっぽいということですか？わかりません〜


>>721
intel 32nm ≒ TSMC 28nmということだと時期的には寧ろ後退しているように見えるの

＞プロセスの提供を開始する時期だけならTSMCはIntelに追いついていたと思うの

いいや、Intelは32nmの量産技術既に確立してるからその意味じゃおくれてる

そーなのかー

確立してねーし

馬鹿の発言は失笑で流せ

>>726-727
http://techon.nikkeibp.co.jp/article/NEWS/20081210/162671/
馬鹿丸出し

馬鹿は馬鹿だしな

・IBMの科学者が世界最速のGraphene(単原子厚)トランジスタを開発(英文)
http://www.ibm.com/press/us/en/pressrelease/26302.wss

量産技術が確立されてるならなんで今すぐ量産しないんだ？

>>731
> 量産技術が確立されてるならなんで今すぐ量産しないんだ？
45nmの償却が済むまで45nmを生産続ける必要があるからだよ

技術の確立と体制の確立は別物

へー
それじゃ歩留まりも十分でファブが出来てないだけなんだ。

プロセッサのバグフィクスもまだJARO

Windowsが起動するWestmereができたら数週間以内に発表するはずだからな

バグ取らずに平気で出せるのがIntel

>>736
とっくの昔にテープアウトしてファーストシリコンも出来ているはずなんだけどな。
そういう報道すらないのはIntelが特にアピールする必要性を感じてないということかと。
Penrynの豪華な報道はHigh-k/Metal-Gate実用化でIntelが浮かれまくっていて笑えた。
逆にMeromの時は必死だったな。（ｗ
まあIDF SpringまでWestmereのネタは出てこないと思うよん。
ISSCCにも論文がないみたいだし。

>>732
ジオンみたいに材料がないんだよ

メッキ団子が剥げ剥げだな

　

量産技術

ま、いいや
http://www.google.co.jp/search?q=%E9%87%8F%E7%94%A3%E6%8A%80%E8%A1%93%E7%A2%BA%E7%AB%8B+Intel&btnG=%E6%A4%9C%E7%B4%A2&hl=ja&lr=&sa=2

90nmだとプロセス開発が終わったと言った後もごたごたしてたけどな。

StrongARMのMMX実装ってどうなってるの？
PentiumのMMXとどう違うんですか？

ググったら45nmの量産技術確立が出ました
↓
ま、いいや
↓
いいや、Intelは32nmの量産技術既に確立してるからその意味じゃおくれてる

うん？降順にソートしているのか？

>>746
馬鹿だな。読解力ないやつはとことん脳みそ足りないな。
君が見つけた45nmの例見てみればわかるように、最初の製品出荷まで1年切ると
量産技術は確立してるものなのよ。
歩留まりがいいとか悪いとかは別問題としてね。
たとえ歩留まり１割程度でも１枚のウェハから製品をいくつも作る以上は量産なんだよ。

Westmereに対応する32nmの生産技術確立もこの前発表があった。
まだWestmereそのものの1stシリコンが出たという話は聞かないがそのうち出るだろう。

ファウンダリ企業はとりあえずSRAMなりロジックなりが最新プロセスで出来るようになってから
ファブレス企業に話を持ちかける。
そういう点でIntelとTSMCを対等に見ると、やっぱり数ヶ月程度は遅れてるでしょ。

>>744
ああ、CopyExactlyがexactlyではなかったというアレか

90nm Pentium Mはリーク電流を抑えこむのに苦労して一部再設計したなんて話があったな。
しかし量産に関しては好調そのものだったとか。

90nmのi945GC/945GSEをAtomに抱き合わせて安売りできるのも、安価に量産できるからこそだろ。

チップセット向けじゃリーク低減のためにCPUとはプロセス変えてるって話だけどね＞90nm

あとTSMCも32nmのSRAMは去年作ってるよ。
量産開始時期も2009年と言ってるし。製品が出てくるのはそれより遅いけど。
それにTSMCの32nmは他社と比べるとハーフノードって感じなんだよな。
シュリンクは出来るだろうけど。
フルノードでHKMGな28nmが本命か。

しかし数ヶ月差にせよIntelに迫ってるのは十分凄いと思うけどな。
まあプロセス世代なんて最近は言ったもん勝ちだが。

SRAMって一番作りやすい箇所じゃね？
IBM連合の65nm SOIは散々だったようだけど

> SRAMって一番作りやすい箇所じゃね？

そうでもない