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

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

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

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

前スレ
CPUアーキテクチャについて語れ 11
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/

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

テンプレが時代錯誤っぽかったんで勝手ながらアレンジしちゃいました。

元のやつ↓

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

x86/RISC/CISC/スーパースカラ/VLIW/MIMD/SIMD
等について語ってもよし、

フリップフロップ回路が小さいPentium Mマンセー、
CISCなのに内部はRISCなPentium 4マンセー、
x86なのに32/64bitコンパチなOpteronマンセー、
昔々8086の時代は(以下略・・・等もよし。

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

つか「Cell B.E.」って書こうとしたら間違えたし

12スレ目にもなると流石に飽ーきてくっちゃ、ダーリン

これもテンプレにしたほうがいいな
--
fenceってのは、ストア1が完了したことを別のストア(ストア2)で他のプロ
セッサお知らせしたりするようなときに二つのストアの間に置くものだよ。

このとき、、

つまり、ストア1とストア2のアドレスは別。他のプロセッサがロードによっ
てストア2への書き込みを知った後、ストア1の結果を読み取ろうとしたと
き、それがメモリシステムのごたごたによってまだ読めなかったりすると
困る。

そんなことが無いように保証するのがfenceの役割。

中途半端に完了させるのがフェンスの役割だろ。
いまさらまともなこというな

これもテンプレ追加で

595 名前：Socket774[sage] 投稿日：2008/08/25(月) 01:15:00 ID:O2J1PAxv
>>590
> メモリコンシステンシ遵守で走ってるときは1命令が完了するまで次の命令はフェッチできない。

どうしてそう性能を落したがるのかなあ

どうしてそう性能を落したがるのかなあ
どうしてそう性能を落したがるのかなあ
どうしてそう性能を落したがるのかなあ
どうしてそう性能を落したがるのかなあ




データに信頼がなくなるからです

これもテンプレ
--
> フェンス命令をしないといけないのはアクセスするアドレスが重なるときだよ。やっぱり君は解ってないな。

これは「間違い」

488 名前：Socket774[sage] 投稿日：2008/08/24(日) 16:48:54 ID:dxY2QGlA
>>486
> HPC用に用意されるソケット版はXeonとプラットフォーム互換で、QPIで相互インターコネクトされる。

だからそれはLarrabeeじゃねえって何度も言ってるだろ

x64非互換な脳内Larrabeeの話はよそでどうぞ
完全準拠は確定してます。

488 名前：Socket774[sage] 投稿日：2008/08/24(日) 16:48:54 ID:dxY2QGlA
>>486
> HPC用に用意されるソケット版はXeonとプラットフォーム互換で、QPIで相互インターコネクトされる。
だからそれはLarrabeeじゃねえって何度も言ってるだろ
488 名前：Socket774[sage] 投稿日：2008/08/24(日) 16:48:54 ID:dxY2QGlA
>>486
> HPC用に用意されるソケット版はXeonとプラットフォーム互換で、QPIで相互インターコネクトされる。
だからそれはLarrabeeじゃねえって何度も言ってるだろ
488 名前：Socket774[sage] 投稿日：2008/08/24(日) 16:48:54 ID:dxY2QGlA
>>486
> HPC用に用意されるソケット版はXeonとプラットフォーム互換で、QPIで相互インターコネクトされる。
だからそれはLarrabeeじゃねえって何度も言ってるだろ



あーあ、このスレもフェンスに中途半端に完了させられるみたいだな。

どうした団子、勇ましく>>5を否定したらどうだ

ところでさ、面白いもの見つけたんだがｗｗｗｗ
中途半端にフェンスに完了させられる（笑）ってのはこんなニーモニックの命令かね？

↓

vscatvps/vscatvpd/vpscatvb/vpscatvw/vpscatvd


ククククク

お前は死ぬよ。確実に。

>>13
否定しないよ。ようやく解ったようだね。

ただ、フェンス命令があってはならない理由って結局何なんだね？
何かわからないけど他に互換でない要因があるに違いない
と思い込みたい状態？

んじゃ、これも否定してくれ

団子> フェンス命令をしないといけないのはアクセスするアドレスが重なるときだよ。やっぱり君は解ってないな。

488 名前：Socket774[sage] 投稿日：2008/08/24(日) 16:48:54 ID:dxY2QGlA
>>486
> HPC用に用意されるソケット版はXeonとプラットフォーム互換で、QPIで相互インターコネクトされる。
だからそれはLarrabeeじゃねえって何度も言ってるだろ


これ撤回するならな。

いい加減Larrabee＝EM64T準拠を認めてくれよ

>>17
で、スキャタ命令は、フェンス命令をせずにどうやってコンシステンシを守るんだい？
後続命令からのメモリ汚染をどうやって防ぐの？

君の仮想世界に存在する脳内Larrabeeの話はいいから

>>18
やなこった

んで、まだ

団子> フェンス命令をしないといけないのはアクセスするアドレスが重なるときだよ。やっぱり君は解ってないな。

こんなアホみたいな主張を続けるのか

20 名前：Socket774[sage] 投稿日：2008/08/29(金) 02:23:18 ID:Yk6PbdtE
>>18
やなこった



現実から逃げるなｗｗｗｗ

>>20
撤回済みだけど前スレで

これは認めてくれるのかなぁ？

826 名前： Socket774 [sage] 投稿日： 2008/08/27(水) 10:44:10 ID:qWNCgzHN
団子> フェンス命令をしないといけないのはアクセスするアドレスが重なるときだよ。やっぱり君は解ってないな。

メモリマップドI/Oで
a番地にデータを書きこみ、b番地へのライトでI/O開始
といった場合に
I/O開始時に、I/Oユニットがa番地のデータを正しく読めるよう
a番地へのライトとb番地へのライトの間にフェンス命令を挟むのが典型的な使い方の一つ

なので、アクセスする番地が重なるとは限らない

といったことを書いたはずだが…

>>22
本当に撤回してたんならアンカー出してコピペしてくれよw

キャッシュライン管理の特性上、確実に汚されない組み合わせが存在するのも事実だよ
でも君が指定したあのアドレス指定だと普通セグメンテーションフォルトだからどのみちフェンスの必要がない。

絶対アドレス指定であれはありえない。

先生！ID:Yk6PbdtEはLarrabeeがEM64T準拠でないといってます。

ついでにおれが最初から正しくフェンス命令の動作を理解していたのも認めるかね？

最初から誤解してた

理解してたらこんな馬鹿なことは書かない

＞　LarrabeeにはScatter/Gatherがあるだろ、
＞　1命令で16要素のメモリアクセスするから、スレッド数にあわせて4段のパイプラインだと、
＞　全部で64アクセスをバッファにためないといけない
＞
＞　それをSSE的にフェンスするとなると、下手すれば全スレッドが止まる

そしてこれ
488 名前：Socket774[sage] 投稿日：2008/08/24(日) 16:48:54 ID:dxY2QGlA
>>486
> HPC用に用意されるソケット版はXeonとプラットフォーム互換で、QPIで相互インターコネクトされる。
だからそれはLarrabeeじゃねえって何度も言ってるだろ

団子はフェンスの動作を完全に誤解していたが、いまとけつつある？

おれは最初から完全に正しい動作を説明していた

これでOK?

フェンスの動作を全く理解していなかったことを認めざるを得ない団子がファビョッて

なんの関係もないレスを、しかもコメントを何もつけられずにコピペするだけで

難局を乗り切ろうと足掻く様は愉快だな

SSEは厳しいモデルだと言ってた奴がフェンス命令の仕様を理解しているわけがない。
CPUIDにフェンスの効果があることすら知らなかったんだからな

CPUID命令って、CPUのバージョンやベンダー名、対応命令を取得するだけでなく
副作用としてフェンスする効果もある。
CPUIDからeax:edx:ecx:ebxを汚さず、フェンス機能のみを使うのが、*FENCE

*FENCEが動作に干渉する命令は当然CPUIDを使っても干渉する。




ID:Yk6PbdtEの主張
「CPUIDの場合はフェンスをスルーすればいい」

561 名前：Socket774[sage] 投稿日：2008/08/24(日) 23:19:19 ID:dxY2QGlA
>>552
CPUID等の直列化作用のほうをVPUには緩めると思う
が、直列化以外の意義のないフェンス命令はナンセンス



どうみてもフェンス理解してない人の発言
俺が指摘してから調べたんだろ

868 名前： 728-729 [sage] 投稿日： 2008/08/27(水) 16:11:10 ID:54ZJgqnI
団子は団子で、教科書的知識に対する理解不足を晒しているところがある
というのを理解しなよ。

と指摘されて

972 名前： ,,・´∀｀・,, 投稿日： 2008/08/28(木) 23:13:49 ID:vX5clrui
(略)
ストア対象のアドレスが一部でも重なる場合にフェンスが必要なわけで
前後でロード・ストア対象のアドレスが重ならないことが最初から
解ってればフェンスを挟む必要がない。

マニュアルにも載ってる　　常　　識　　で　　す。


975 名前： ,,・´∀｀・,, [sage] 投稿日： 2008/08/28(木) 23:39:13 ID:vX5clrui
アドレスが重複しないのに、
どうしてフェンスが必要だと思ったんですか？
それは仕様書が、というよりは文章が読めてないってことですよね。


868で指摘されて972や975でもこんな勇ましいことを言っていた君が、どこで無理解に気付いたのかな

978のnminoru氏のプレゼン読んでようやく分ったか？www
それでもまだトンチンカンなことを言っているが

「中途半端にフェンスに完了させられる」

これはフェンスを理解してる人の発言ではない

フェンスを理解していなかった団子
フェンスを理解していなかった団子
フェンスを理解していなかった団子
認めざるを得なくなった団子

くやしいのう くやしいのうwwwwwww

> LarrabeeにはScatter/Gatherがあるだろ、
> 1命令で16要素のメモリアクセスするから、スレッド数にあわせて4段のパイプラインだと、
> 全部で64アクセスをバッファにためないといけない

ところが全部ページ内に収まるかを解決してしまえばバッファリングそのものが不要です

知識も素養もないのにマニュアルだけ読んで フェンスを理解できなかった団子
しかも1スレにわたって偉そうな態度で大間違いを吹聴していた団子
くやしいっ…でも気持ちいいっ…

ま、MACオタよりよっぽどマシな態度なんで、いじめるのはここまでにします

今日は団子が理解を深めたことと、素直ではないが自分の間違いを受け入れられるような人間に成長したことを素直に祝いましょう

↓彼はこの時点までライトコンバインを知らない
　　ちなみにCPUIDがフェンス作用があるのも俺が指摘して気づいた


763 名前：Socket774[sage] 投稿日：2008/08/26(火) 20:56:01 ID:JnmrWmO4
>>761
> リタイアまでは見届けてもデータの正しさには保証がない。

リタイアしたストア命令が、データを正しくストアしている保証はない、という意味か？

766 名前：Socket774[sage] 投稿日：2008/08/26(火) 21:17:10 ID:JnmrWmO4
>>765
すまないが、君と話すことはもうなにもない

「リタイアしたストア命令が、データを正しくストアしている保証はない」

なんて、x86に限らず、ありえない

勝利宣言ｗｗｗｗ

でも君は死ぬんだ。確実に。
Larrabeeは完全なEM64T準拠ですから。

これに懲りたらちゃんと最新の分厚い教科書読んでね
どういうプライドから読まないのか知らないが、読んで損はしないよ

っていうかライトコンバイン命令のリタイヤ条件を把握してない奴が
フェンス命令の仕様を理解してるわけがないしさ。

766 名前：Socket774[sage] 投稿日：2008/08/26(火) 21:17:10 ID:JnmrWmO4
>>765
すまないが、君と話すことはもうなにもない

「リタイアしたストア命令が、データを正しくストアしている保証はない」

なんて、x86に限らず、ありえない

>>43
懲りるのはお前だよ。
なぜならLarrabeeにSSE*は実装されることは確定なのだから。

>>44
> っていうかライトコンバイン命令のリタイヤ条件を把握してない奴が

そもそもライトコンバイン命令のリタイヤ条件というのがどういう意味かわからんが、よかったら説明してくれ

リタイヤするための条件なのか？
リタイヤ後に満している条件なのか？

団子の言い方ではそれすらわからん

> リストベクトルなんて有名な性能ボトルネックじゃん
> リソースの投入し甲斐のある箇所だよ、ベクトル機みたいにね

こんなことを言う馬鹿がなぜか回路の制約でSSEはサポートできないと言う

どこでリタイヤとみなすかなんて実装定義だが、
ライトコンバインはメモリまでストアするわけだから、もし、確実にストアできるまで
待つという仕様だと、それがすむまで待たなきゃならんよな。
すなわちストアなら100クロック以上待たないといけない。

でもそんなことやってない。
こんな風にしてフェンス命令を挟んでかかったクロック数計測してみればいい

movntps [ecx], xmm0
sfence
movntps [ecx+16], xmm1
sfence
movntps [ecx+32], xmm2
sfence
movntps [ecx+48], xmm3
sfence

フェンスは前の命令が全部リタイヤするまで次の命令をフェッチさせない仕様なんだから
逆にパイプライン段数の差をとれば、リタイヤと見なすのにかかってるクロックがわかる。
何クロックかかるかなんてのはそれこそ実装依存だが。
それでも、リタイヤと見なすのに逆算して数クロック分しかかかってないことがわかる。
つまり、確実にストアされたかなんてフェンスを使った時すら見てない。
実験してみればわかることだよ。



ちなみにスキャタ命令はMASKMOV*やMOVNT*と同じくライトスルーな。
AoSの読み書きはキャッシュのスラッシングが起きやすいから、キャッシュを
介さないことが好ましい。逆にむしろライトスルーでないと帯域が生かせない。
通常のストアはライトバック制御のせいで待たされるからね。性能を殺す要因。

また、ライトスルー命令だからこそ通常のアクセスとの境界にフェンス命令が【要る】わけよ。
これは常識な。

前スレの発言は撤回する気がないようなのでしつこく粘着してやる

> ページフォールトハンドラ内では当然共有データのページテーブルを更新するだろう
> なのでフェンス命令は必ず実行される

ハンドラに捕捉されるとパイプラインは全部流れます。
そもそもフェンス命令の「実行」状態って何を言うんだろうか？
まだ未完了の実行ユニットのポートをが数サイクルにわたって占拠され
その後ろで実行ステージを待ってる状態を実行中とは言わない。

フェンス命令によって中途半端にストアさせられるｗｗｗｗとかさ

ちなみにページスラッシングはOSじゃなくてマイクロコードでやる仕事ですので
例外ハンドラは全然関係ない。


> scatterの全てのメモリアクセスをバッファリングしておいて、すべてのアドレスがページインした状態を保証してからバッファを書きだすと
> 意味論的には正しいが、バッファリングのコストと、実際のストアまでの余計な遅延がある

ページインかどうかはアドレス指定に用いるレジスタに含まれるオフセット値の最大と最小だけとって
その範囲を見れば判別できるので全てを物理アドレスに変換しストアパケット作ってから
バッファリングするような手間をかけるまでもなく簡単に保証できる。

まだやってるのか…

どうでもいいけどARMのコード資産は見えないところに行き渡ってる。見えるエコシステムのx86界隈とは文化そのものが違うね。

見えるって言うか実際CPUターゲット別のプログラマ人口で一番多いのがx86だろ。
ソフト市場規模で見てもね。

ARMもいいんだけどでもIntelはXScaleやめちゃったしなぁ
WirelessMMXは本家ARMのSIMDより好きだったんだが。
俺もARMのアセンブリコードくらいは読めます。
てか、まさに、取ってきた仕事のために読んでる。
プレディケートの概念は直感的でいいね
3レジスタオペランドマンセー

>>48
なーんだ
やっぱりわかってないじゃん(プ

>>49に補足
そもそもヴァカの間違いは
「フェンス命令は一度パイプラインにフェッチ前の命令で例外が起きても破棄できない」
という思い込み

実際には、例外が起きればパイプラインは全部フラッシュされ、
もちろんフェンス命令も「パイプラインに取り込まれてない」状態に巻き戻されます。
分岐予測ミス時にパイプラインを破棄するのと同じ理屈です。
正常処理できなかったフローは破棄します。

どーせパイプラインに取り込んじゃったら、例外が起きようとフェンス命令をリタイヤ
するまでは継続しないといけないと思ってるんだろ。前の命令を押し出してでも。
だってそうじゃないと「中途半端な状態でフェンスに中断させられる」とか言わないもんな。

　基本、こいつはただの　馬　鹿　だ　か　ら


前の命令に影響を与える命令は存在しません。
そんなんあったらノイマン型コンピュータの原則に反します。
だから、教科書にも書いてある常識です。

後続の命令は実行前ならいつでも破棄出来ます。
パイプラインが実装されてからずっと、そういう構造になってます。
でも頭弱いから、フェンス命令が残ったまんまだと思ってるんだぜ。

その思い込みを根拠に、一貫性云々のこじつけでSSEがサポートできないとか言ってるんだぜ。
いまだに。
ちなみに、例外時に破棄することを前提としたストアバッファは存在しません。
例外チェックをクリアしてからストアバッファに溜まります。


で、フェンス命令のどこが厳しいだって？ｗｗｗｗ

そもそもの前提として、例外が起きたらフェンス命令は溜まったままになりませんｗｗｗｗ

スキャタのアドレス解決機構は、フェンス命令の実装の有無と関係なく
備えていないといけない話だし

>>52
なんだ、いまだにわからないのか。決定的な勘違いが。

×「フェンス命令は一度パイプラインにフェッチ前の命令で例外が起きても破棄できない」
○「フェンス命令は一度パイプラインにフェッチされたら、前の命令で例外が起きても破棄できない」

>>48
ヒント

シングルCPUのユーザープロセスにはフェンス命令はいらない

馬鹿だなCore 2で計測してんのに。
計測して反証しろよ。
お前アセンブラ知らないから無理か。まあ馬鹿には無理なのはわかってるし。

x86の話してるのに、x86の命令に存在しない

　　「s　t　o　r　e　」

とか書いちゃうくらいだもんな。ぷぷぷ

それより>>53で図星なんだろ？
でないとフェンス命令が干渉するなんて世界で1人だけの妄想は
起こりえない

http://aceshardware.freeforums.org/consequences-of-extending-xmm-registers-to-ymm-t539.html
ここにx86プログラマ界の重鎮Agner氏がいるから
自分が思ってるフェンス命令の動作を説明してきてごらんよ


一発で論破されるから

MOVNT系はノンテンポラルとかいう Intel 用語で呼ばないといかんでしょう
ライトスルーはライトスルーで別物だし
ライトコンバインは他にも色々あるからさ

というか、ノンテンポラル命令のWrite Combineプロトコルって、
M,E → Cache Line と Write Data を Combine して burst write
S →　RFO後、辻褄が合うようにwrite (実装依存?)
I → マスク付で Write Data を burst write
で、必ず I に落ちるプロトコルっしょ
(勘違いがあったらごめん)

ライトスルーってのは Valid か Invalid しかないのよ

>>48
> また、ライトスルー命令だからこそ通常のアクセスとの境界にフェンス命令が【要る】わけよ。
> これは常識な。

プププププ

LarrabeeでSSEが動くのはTera×3以前からIntel自身に言われてたこと。
むしろAVXやLNIは今年になってからの新事実。
Larrabeeには、既存命令と干渉するような新命令なら、最初から載せないだろう

たしかに、キャッシュに収まりきらない大きい多次元配列のアクセスは
ノンテンポラルを使うべきというのはPen3の頃からインテルが言ってた事項だよ。
シーケンシャルならまだいいが、ストライド次第では壮絶なキャッシュミス地獄になるからね。

団子> 【現実のIntel/AMD/VIAの実装】
団子> ストアバッファはあくまでキャッシュ帯域の節約のため一括転送するために貯めておくもの。

プププププ

> >>22
> 本当に撤回してたんならアンカー出してコピペしてくれよw

コピペマダー？

>>20
> 団子> フェンス命令をしないといけないのはアクセスするアドレスが重なるときだよ。やっぱり君は解ってないな。
> こんなアホみたいな主張を続けるのか

>>22
団子> >>20
団子> 撤回済みだけど前スレで

フェンスをちゃんと理解したと思ったら

>>48
団子> また、ライトスルー命令だからこそ通常のアクセスとの境界にフェンス命令が【要る】わけよ。
団子> これは常識な。

やっぱりわかっちゃいねー！！

団子の浅薄な理解はラッキョのごとし

正解も書いておいてやるぞ

Weak Consistencyに於いては
2つのメモリアクセスの順序を**CPU外部**に対して保証する場合には、必ずフェンスを間に挟む必要あり
それ以外の場合にはフェンスは全く不要

ライトスルーとかもう全然関係ナシ

で、その必要な命令を、マルチコアアーキテクチャのLarrabeeでは
SSEごと「サポートできない」と言ってる馬鹿がいる。

その理由も、既に完全否定されているにもかかわらず、である。
フェンス専用命令のサポートを消して全部CPUIDで済ませろって？
20倍のクロックも待たされる上にEAX:EDX:ECX:EBXレジスタを汚すCPUIDを？

まあ、嘘を言ったのは認めるさ。
まあ、「storeなんて命令なんて無い」って言われて必死に調べたんだろうと
思って、軽くあしらっただけなんだけどさ。
でもアレのコードはプログラミング作法としちゃ駄目だよ
スタックとかヒープとかデータセグメントに対する相対アドレッシング
とかじゃなしに10000000とかの即値でアドレッシングする時点で
安全にストアできる保証がない。
即値はアプリケーションの作法としてはありえない。
そういう意味ではどのみちフェンスがあろうがなかろうが、
一般保護違反になる可能性高いから、あろうがなかろうが同じってことで。


まあいいけど、問題でも出しておくか
add eax, [edx+ecx*2+12345678h]
のModR/Mバイトのエンコードを16進数で答えよ。
これはx86アーキを知る上では常識だけどさ。

というかスレッド間で共有するアドレスならなおさら、
データセグメントなりヒープのポインタを使ったアドレッシングになるわけで
「即値」になるわけがない

何故そこで86になるような問題にしないのか

>>67
調べりゃすぐわかることを好きこのんで覚える趣味はないが、まだちょっとだけ覚えている

op modrm sib offset

add eaxはopバイトで指定
modrmがsibの存在とオフセットを指定
siバイトは、スケール2 インデックスecx ベースedx

だっけ

オペコードの割り当てはわすれたが、26hくらい
7ビット目は0、6-4ビットでALUの機能を指定、3-1ビットでアドレッシング、0ビット目でbyte/word

レジスタはeax,ebx,ecx,edx,esp,ebp,esi,ediの順で0から7にエンコード

modrmは、md rrr mmm
modはアドレッシング形式を指定する
mod!=0とmmm=5でsibバイトの存在を指定する

mod=0がレジスタ-レジスタ
mod=1,2,3がレジスタ-メモリでオフセットサイズがそれぞれ0,1,4バイト、かな

sibはss iii bbb
スケールは1,2,4,8なので、*2はss=01

オフセットはリトルエンディアン

結局

26 C5 53 78 56 34 12


20年ぶりにしてはよく覚えてるだろww

>>70
×add eaxはopバイトで指定
○addはopバイトで指定

おまけ

20 add eax,eax
21 add eax,ebx
22 add eax,ecx
23 add eax,edx
24 add eax,imm
25 add eax,[offset]
26 add r, r/m
27 add r/m, r

modrmのmmmは

000 [eax]
001 [ebx]
002 [ecx]
003 [edx]
004 [esp]
005 sib
006 [esi]
007 [edi]

で、modの値に応じてそれぞれにオフセットがつく
mod=0のときは、そのままレジスタ番号

じゃなかったけか

>>71
> 7ビット目は0、6-4ビットでALUの機能を指定、3-1ビットでアドレッシング、0ビット目でbyte/word

あ、これと矛盾するなあ

b/wの指定はどうすんだっけな。。

20年ぶりってｗｗｗおっさんだね。
それならもうアルツハイマー始まっててもおかしくねーわな。

最近のOSセグメント管理知らなくて当然だな
共有変数を即値でとるとか、マルチプロセッサ環境としてにありえないことを
平気で言ってのけられるわけだ。
なっとく（笑）

OSレスならある意味フリーダムだけどね。そんかわりマルチプロセッサの管理が面倒だ。

つーか
Agner氏も当然のごとくLarrabeeではSSEは載るって見てるようだけどその点はどうよ？

>>73
OSレスな環境の経験はないのか

そはともかくエンコーディングのクイズはどうよ？

>>67
> まあ、嘘を言ったのは認めるさ。
> まあ、「storeなんて命令なんて無い」って言われて必死に調べたんだろうと
以下略

負 け 犬 の 遠 吠 え

OSレスでマルチコアでは結局OSの機能を自分で作る羽目になるだけだからな
組み込みでもマルチコア使う用途じゃ審美餡やらWinCEやらLinuxを使うのが一般的だぞ

ほい
http://maelific.dyndns.org/projects/myos/browser/tags/All/trunk/MyOS/src/dosutil/myasm/etc/%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E6%8C%87%E5%AE%9A%E5%BD%A2%E5%BC%8F%E6%8C%87%E5%AE%9A%E5%AD%90%E3%83%90%E3%82%A4%E3%83%88(32bit).xls?rev=87&format=raw

でも即値指定だけはないわー

＞負け犬の遠吠え
っていうか即値アドレス指定の時点でマルチタスクOS上のアプリケーション
の共有変数として有り得ないしー（笑）
コードシーケンスとして論外（笑）

>>78
負 け 犬 の 遠 吠 え

79 ：Socket774：2008/08/29(金) 14:11:11 ID:Yk6PbdtE
>>78
負 け 犬 の 遠 吠 え

と負け犬が遠吠えしてます

出題者が間違えるなんてありえませんから。残念。

「フェンスに完了させられる」の誤解はいつ辞めるの？
その誤解の上にSSEをサポートできないのトンでも論理が構築されてるわけで
Agner氏にメールで聞いても「有り得ない」って回答だよ。

>>81
> 「フェンスに完了させられる」の誤解はいつ辞めるの？

全く正しい表現だよ

比喩的ではあるから、表面的な理解もあやしい団子には難しかったかもしれないね

> Agner氏にメールで聞いても「有り得ない」って回答だよ。

引用してくれ

つーかIntel自身が「Intel 64準拠」だって言ってるんだがなぁ
Intelのx86 64bit拡張はIntel 64（旧称EM64T; Clackamas）以外に無いんだよ。
YamhillはMSその他に揉みつぶされました。
まあ、がんばってSSE非対応の根拠探してくれよ。

ネット上で同意者探すだけでもいいかもよ。
ま、徳川の埋蔵金なみに見つからないと思うけど。

まだ投げられてないサイコロの目をどうこうじゃなくて
既に決定した論理であり、しかも一部にはIntel(R) 64 Technology準拠
であると情報が漏れてる上で
ネットの片隅でSSEサポートでないと言ってる馬鹿一名
せいぜい全てが公開されるまで思い込みで踊れよ愚者め

Intelの公式フォーラムに参加してるx86システム技術者の重鎮ですら
XSAVEを用いたLarrabeeのワイドベクトルレジスタの退避モデルについて
フォーラムで意見を交わしているような既にそんな状況。
SSEがサポートされないなんていってる奴は後藤とこいつ以外みたことが無い

1)先行するストア命令が完了したのを、フェンス命令によって保証されてから、後続のストア命令が完了する

が、より比喩的でない表現かな

2)先行するストア命令が、フェンス命令によって完了させられてから、後続のストア命令が完了する

ちょっと比喩的ではあるけど、わかっている人には1)はくどいし、まさか団子がフェンスを理解していなかったとは思わなかったからさ、ごめんな

1)も本質的でないが不正確なところもあるけどね
フェンスは先行するストアが後続するストアより「先に」完了することだけ保証すれば、実装はどうでもいい

SSEのフェンスみたいに後続命令をブロックするのだけが可能な実装ではない

自分でメールしろよ。とんでもないこと言ってるのお前だけなんだから
英語でおｋ。氏はデンマーク人だけど。

後続命令はパイプラインに載ってない状態になるんだぞ
バッファなんて要らないジャン

お前聞いてないんじゃないかよww

別にそれが誤ってるなんて言ってねーよ
例外が起きてもフェンス効果が有効だと思ってるがゆえに馬鹿なんだよ
しかもExecuteより手前のステージは分岐予測ミスや例外発生時に
しょっちゅう破棄されてる。もちろんフェンス命令も含めてだ。

フェンス命令の作用自体、仕様書どおり「常にフェッチを止める」というよりは
フェンス命令が実行ステージに入ったときに前の命令がリタイヤするまで後続命令列の
フラッシュを繰り返すことで実現されてるんじゃないかと思ってたりするが。
ま、それこそ実装に依存した話になるが。
実行ステージに入っても無いのにフェンス効果が利く必要は一切ない。
いつでも破棄できることが重要。

で、PF等が起きたらパイプラインを破棄して立て直せばよく
ストアバッファを破棄できる仕様にする必要が無い。
ま、16Wayでもそんなに大きいとは思わないがな
VIAのインオーダの省電力CPUですらWCバッファが数Wayとかだろ。

>>87
だから「SSEサポートできない」なんてこの世界で後藤とお前くらいしか
思ってないないんだから、お前が直接識者に聞いてみろよ。
どうせ自分の間違い認められないんだろ？

っていうか
前の命令が完了してない時点で、フェンス命令はExecuteの手前のステージってのは
わかる？
わかってない？
だから馬鹿は氏ねよ

>>88
> 例外が起きてもフェンス効果が有効だと思ってるがゆえに馬鹿なんだよ

また人が言ってもいないことを〜
例外ハンドラ内の話してただろ

>>89
相手のいることなので、団子のためだけにそんな手間かけんのはやなこった

↑
SSEサポートできないなんていってる奴が
お前と後藤以外に誰がいるんだよ
つまりお前が人の意見に合わせられないゴミなの

＞例外ハンドラ内の話してただろ

例外ハンドラってのはOSがトラップしてアプリのcatchブロックなんかに
投げるアレだけど、それでいいのか？

例外処理ブロックに飛ぶってことは、その時点でオペレーション失敗時に
読み書きしたメモリがクリーンである保証はそもそも無いんだよ。
保証をすることは規格にも無い。
だからバッファリングなんてする必要はないんだ。

それよりさっさと、どこのきょうかしょなのかおしえてよ。

そのきょうかしょ（笑）に基づけば「SSEがサポートできない理論」を説明できるのか？
なら1000円までなら尼損で買ってやんよ。


っていうか50過ぎのおっさんなんだろ？無理するな

>>93に補足すれば

そもそも例外を検出してないときですら、コンピュータは正しく
データを読み書きしてる保証なんてどこにもない。
ECCメモリのビット誤り検出にしてもそう。100パーセントの
信頼保証は有り得ない。

逆にもし完全に保証できたら、TMRによる多数決冗長系が組める
x86に対するItanium2の優位性は何なのよって話になるだろ。

>>89
　　------------------
　　だから「SSEサポートできない」なんてこの世界で後藤とお前くらいしか思ってない
　　------------------
できるできないわ別にして、私もx87やSSEをサポートしない可能性わ有ると思っているす。

仕様書見たけど不正な操作に対するコンシステンシ保証なんて
元々規定されてないじゃん。

命令レベルでall or nothingなんて保証したところでそもそも

保　証　す　る　意　味　が　ね　ー　し。

アプリケーションとしてall or nothingであったほうがいいのは、
あくまで関数レベル・機能レベルの話になるわな。
命令レベルで保証されても、命令レベルで�dでリカバリーとか
無駄だからね。
例外トラップ機構なんて高級言語向けのものだから命令レベルで
順序保証されてても意味ねー。
するだけトランジスタの無駄。

フェンス命令は正常なフロー(all)にだけ順序保証をすればいい。
というかそういうもともと仕様のはずだが。

それがなんでscatterと干渉するんだよｗｗｗ
マジ頭悪くね？

SSEサポートの程度わ不明という点でわ、Anandも同意見の様す。
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3367&p=3
　　------------------
　　64-bit x86
　　SSEn support?
　　Parallel/Graphics?
　　------------------

>>96
AVXのマニュアルではちょっとだけ
SSEのソフトエミュレーションについて言及してたね
利用頻度の少なくなった命令は#UDをOSに投げて、
トラップしてエミュレーション実行するとか
AMD64だったか忘れたがx87についても
エミュレーションについて言及されてたな。

でもそれは「サポートしない」って言わないんじゃね？
SPARC/Solarisがそんな感じのマイナー命令サポートだし

しかしだな

SSEでも現状利用頻度が多い以上は、ハードワイヤードロジックで
実装する理由がある。
ついでに言うとOSによるSSE*エミュレーションの実装は、
現状影も形も無いわけで、じゃあ誰が提供するのって話になる。
Linuxならpinでも使って実装する手もあるけどさ。
エミュレーション自体、SSEがほとんど誰にも使われなくなった場合の
オプションとして、ゆくゆくは、の話であって、
移行もしてないうちから切り捨てるのはセオリーに反してるべ。

おまいさんの信奉するAppleじゃ日常茶飯事かもしれんが
Intelに取っちゃ死活問題だべ。

>>98
Intelの言うところの「64bitサポート」は、
AMD64のLongモードとのISA互換＋SSE3＋CMPXCHG16B
までを要件としてるからそこまでは確定だべ。

逆にSSSE3/SSE4.1/SSE4.2/AES/CLMULのサポートはどこまでかは
俺にもわからんべ。
それこそソフトエミュレーションかもしれんべ。

同様な疑問を提示しているサイトす。
http://techgage.com/article/clearing_up_misconceptions_about_cuda_and_larrabee/
　　-------------------
　　- Will apps written for today's Intel CPUs run unmodified on Larrabee?
　　- Will apps written for Larrabee run unmodified on today's Intel multi-core CPUs?
　　- The SIMD part of Larrabee is different from Intel's CPUs - so won't that create compatibility
　　　problems?

　　The first two questions are quite similar, and the straight answer is "No.". But, there's a caveat.
　　If we were to change 'apps' to 'code', then the story would change, because as it stands, Intel
　　claims that the same Larrabee code can be compiled to run on either the CPU or GPU (Larrabee).
　　It's all a matter of what you choose in the compiler to do.

　　Intel noted that the code wouldn't be compiled for both the CPU and GPU at the same time,
　　since the compiler will optimize the binary for the respective architecture. They went on to say
　　that it could technically be compiled for both, but that would not be the ideal scenario, due to
　　various optimizations.
　　-------------------
Larrabee論文の「要リコンパイル」の行を重視している模様す。

>>99-100
広い世界にわ、LarrabeeのISAサポートに関して疑念を持っているヒト達がいる例ということで。

>>93
> 例外ハンドラってのはOSがトラップしてアプリのcatchブロックなんかに
> 投げるアレだけど、それでいいのか？

プ

>>97
> 命令レベルでall or nothingなんて保証したところでそもそも
>
> 保　証　す　る　意　味　が　ね　ー　し。

ププ

>>101
OSは動く必要はあるでしょ。
x64のOSはAMD64の基本命令まで最低限動くことを前提に作られてるから
動かないと話にならない。
IntelはMSに却下されたYamhillをしぶしぶ廃案にし、Longモードで使える
命令をAMD由来の特権命令も含めてサポートすることで、
それがx86の64ビット版の統一仕様になった。
それを1命令でも欠いてると、対応OSがない可能性がある。

SSE2までは有無を言わさず確定。
でもそれ以降の拡張命令は完全にサポート任意だから
サポート決めうちで最適化コード組んでればリコンパイルが必要ってのは
確かにそうなんじゃね？アセンブラやIntrinsics決めうちだと
リコンパイルどころじゃすみそうにないけどな。

俺はむしろリコンパイルが必要ってのは性能問題だと思ったが。
命令サポートが同じでも、インオーダだと専用のスケジューリングが
必要だし、あと論理CPU数分のスレッドを起こさないといけない。
性能が出せなきゃLarrabeeを使う意味が無いからな。
同じコードで同じスレッド数ならXeonよりはるかに遅い。

>>103←馬鹿だねこいつ。もうプしか言えないだろ。
得意の教科書で攻撃してこいや屑め

>>101
っていうかそれ
サポート命令が同じなら性能が同じだと思ってる素人アナリスト臭い

はっきり言って考察として読むに値しない。

誰かと思えばRob Williamsか。組み込みRTOSの本書いてる人だね。
こらMACヲタ、記者名くらい引用汁

>>107
　　-------------------
　　記者名くらい引用汁
　　-------------------
だから何時も安易に他人のことをバカバカ書くなと。。。(笑)

それでも記事レベルで数を競うなら、「x64」として書いてる記事のほうがよっぽど多いんだよな
http://www.google.co.jp/search?q=Larrabee+x64

Larrabee "x64 incompatible"
だと2件しかヒットしない。しかもまったく関係ないページ
http://www.google.co.jp/search?q=Larrabee+%22x64+incompatible%22

LinuxのXSAVE/XRESTRサポートのためのパッチ送った企業ってどこだったっけ？
まあそういうこっちゃ
ヘッダの拡張フィールドによって1024ビットSIMDとかの時代まで対応できる命令とされる。

Intel's Larrabee GPU Will Support Linux
http://www.phoronix.com/scan.php?page=news_item&px=NjYzOA

面白いことになったね

？
Xの話じゃないの

Siggarph2008のLarrabeeプレゼン見つけたす。
http://s08.idav.ucdavis.edu/forsyth-larrabee-graphics-architecture.pdf
興味深いところわ、この辺すか。
　- in-orderでも遅くない (p.7)
　- U/Vパイプのペアリング(制限？)わPentiumと同じ (p.7)
　- スカラ命令わシングルサイクルレイテンシ (p.7)
　- SMTわクロックごとの粒度のFGMT (p.7)
　　　ただし、スリープしているスレッドわ除く (p.11)
　- SIMD ISAで引数の内、ペナルティ無しにメモリを指定できるのわ、一つだけ (p.8)
　- SIMDユニットで大半の命令わ実行レイテンシ8サイクル以下 (p.8)
　- SIMDの数値精度わビット表現レベルで"fast mode" SSEに同じ (p.8)
　- SIMDユニットで4-byeより小さいデータ型わサポートしない (p.9)
　　　16-bit Float, byte, shortわ、自動符号拡張
　　　グラフィック用の構造体も低レイテンシで変換
　- Scatter/Gatherわ16-wideベクトルの各要素に32-bitオフセットで指定 (p.9)
　　　スカラコードの自動SIMD化に適用
　- SMTの主目的わキャッシュミスの隠蔽 (p.11)
　　　でも命令レイテンシの隠蔽にも有効
　- スレッド間でTLBも共有 (p.11)

今月のパワレポでの後藤

「LarrabeeはMMX/SSE以降の拡張命令のほとんどを採用しないと見られる」

みたいなこと言ってた。
"ほとんど"という言葉が入ったのがネット記事との違いか。

>>100
　　-------------------
　　Intelの言うところの「64bitサポート」は、
　　AMD64のLongモードとのISA互換＋SSE3＋CMPXCHG16B
　　までを要件としてるからそこまでは確定だべ。
　　-------------------
そのIntel謹製の資料で、x64ともx86-64ともEM64TともIntel64とも書かずに、
　　===================
　　Plus standard 64-bit instruction extensions
　　===================
と書いているのにわ、意味があるのかもしれないす。"standard"すから、X64を指すと受け取るのも
アリと思うすけど。。。

>　- SMTの主目的わキャッシュミスの隠蔽 (p.11)
>　　　でも命令レイテンシの隠蔽にも有効 。

なー、MACヲタよ。命令レイテンシの隠蔽できるってよ。
加減算は1サイクルだから意味無いす（笑）か？

Xでlarrabeeが使えることの何が面白いの？

＞standard 64-bit instruction extensions
そりゃ「standard」って言ったらAMD64/Intel 64の共通規格のアレ以外ないでしょ。
それ以外にstandardはないでしょ
basicだったら微妙だしsubsetって言ってるなら非互換だろうけどさ。

まあSSE2までは少なくとも確定、SSE3もおそらくいける。
3バイトOpcodeを使うSSSE3以降が微妙。デコードアルゴリズムの拡張が必要だからね。
OSが最低限動くためにはSSSE3/SSE4は必ずしも対応させる必要はない。
この世代のx86は相対的にデコーダのコストが大きいから。

1ダイに16コアとか32コアとか強力なx86デコーダが載るのかと考えればぞっとする。

>>116
　　-----------------
　　なー、MACヲタよ。命令レイテンシの隠蔽できるってよ。
　　加減算は1サイクルだから意味無いす（笑）か？
　　-----------------
日本語が読めないことを思い出させて、わざわざ恥をかくことも無いと思うすけど。。。　
私の書いた内容わ、コレす。
　　=================
　　191 名前：MACオタ＞団子 さん 投稿日：2008/08/17(日) 13:15:36 ID:Zsenu7UF
　　　　>>190
　　　　　　---------------
　　　　　　命令間のレイテンシ隠蔽のための方策も全然違う。
　　　　　　4Wayのマルチスレッドによりプログラム側から見たレイテンシを小さくしたのがLarrabee
　　　　　　---------------
　　　　4-wayマルチスレッドわロード・ストアの隠蔽だと思われるす。
　　　　ショートパイプラインが売り(多分クロックわ低め)すから、命令レイテンシわ隠蔽するまでもなく
　　　　小さいんじゃないすかね。
　　　　レジスタわ少なそうすから、後続命令への演算結果のフォワーディングがCell/B.E.より重要になるし。。。
　　=================
で、積和わ綺麗にパイプライン化されているとのことすから、一生懸命レイテンシ短縮しなくても
動作に問題わ無いす。
　　==================
　　- Ternary, multiply-add, one clock throughput (p.8)
　　==================

それとも、MACオタ用語的には「standard」に規格外って意味でもあるのか？

で、Xでlarrabeeが使えることの何が面白いの？

面白いから面白いだけ

>>120
　　-------------------
　　MACオタ用語的には「standard」に規格外って意味でもあるのか？
　　-------------------
日本語が読めるなら>>115を読み直せば判ると思うす(笑)

＞standard 64-bit instruction extensions
　~~~~~~~~
さて、ここはどう弁解しよう？

オッサンのトンデモ論的にはLNIと干渉するんだろ？ｗｗｗｗ

ふぅん

>>123
なにか？AMD64準拠ならOSが動く条件はクリアだよね
暗黙にCMOV/SSE/SSE2も含まれる。

つまり「彼」の死亡条件がクリアされましたｗｗｗ

SSE3もCMPXCHG16Bも今はAMD64の規格に含まれてる。
だがAMDは3DNow!と同じく実装は任意としている。

SSE3/CMPXCHG16Bも実装しとかないとAMD64互換であってもIntel 64非互換になっちゃうんだよね。
それIntel的にはまずいでしょ（メンツ的な意味で

> 111 名前：,,・´∀｀・,, 投稿日：2008/08/29(金) 19:06:12 ID:XA+DpWi/
> Intel's Larrabee GPU Will Support Linux
> http://www.phoronix.com/scan.php?page=news_item&px=NjYzOA
>
> 面白いことになったね
>
>
> 112 名前：Socket774 投稿日：2008/08/29(金) 19:24:32 ID:0dK6Hl59
> ？
> Xの話じゃないの

面白いテンプレが出来たね

>>128
いいから死ね

OpenGL(MESA)はXを介さずにフレームバッファにダイレクトに書くんだが。

DirectXがGDIでないのと同じレベルで別物。
無知って恥ずかしいね。

ふぅん
で、なにが面白いことになるの

X.Org 7.5 should be out before Larrabee ships and hopefully X.Org 7.6, but based upon the recent X history, who knows?

>>113すけど、上の階層を漁るともう2つSiggraphのプレゼンが見つかるす。
http://s08.idav.ucdavis.edu/lefohn-programming-larrabee.pdf
http://s08.idav.ucdavis.edu/pharr-advanced-rendering-on-larrabee.pdf
前者わ、ちょうどLarrabeeにおける『ソフトウェアコンテキストの細粒度切替による命令レイテンシの
隠蔽』を語っているす。ちなみに後者わグラフィックよりの話題す。

この中に出てくるLarrabeeにおけるコンテキストの最小単位"Fiber"って、リソースがダブらないよう
に複数の処理をするコードを自前で書けという意味にも取れるす。
特にハードウェア的な支援が無いように見えるすけど、「リソースがダブらないように」を満たすために
予想以上にレジスタファイルが大きいとか？

>>131
イジメよくない

私の肛門もフェンス命令に強制リタイアさせられそうです(笑)

LNIとSSEは共存できるが、Larrabeeの実装では、VPUにSSE命令を100%コンパチで実装するのは難しい
(笑)

【テンプレ】

> つか、万が一でもSSE*を100％サポートだったら死ぬの？

いいともさ
そのかわり、ごくささいな互換性でも失なわれていたらお前が死ねよ

なんか独り言いい始めたぞ

SSEがサポートできない（プ

私のバッファにもスキャット命令が溜め込まれそうです
フェンスに貫かれそうです
アーッ！

>>137
お前があんまりいじめるからだろ

先生、フェンスに完了させられてしまいました。

先生、ららびいがSSEをサポートしない理由教えてください

なんだ団子か

なんだ自殺宣言した人か

ララビーのアレ(ストリームプロセッサ？)はインオーダー型のデュアルイシューじゃなかったっけ？

CPUコアのほうがインオーダー型のデュアルイシューなのは既出だけど
デュアルのうち片方だけは簡易にしてSIMDを載せない可能性があるとかいう話があった気がする。そのへんどうなってるんだろ。

で、いつ死ぬの？

は？

>>143
バラスナヨ

フェンスに強制完了させられた短い人生だったな

何を言ってるんだろうねこの人は

どんなCPUだろうと、GPUだろうと、GPGPUだろうと、DSPだろうと
呼び方違えど同じマイクロチップ(材質はシリコン(半導体))の仲間だ

ナウなヤングにバカウケ

>>132の続きすけど、よく読むと最初のプレゼンのp.25にFiberの説明があるす。
　　-------------------
　　・ Fibers 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
　　--------------------
レジスタの退避が必要ということわ、レジスタが増えている訳でも無さそうす。
そもそも同じページに"No hardware or OS support"って書いてあるす。。。

Larrabeeのスケジュール管理の話題で、どの辺が画期的なのか誰か教えて欲しいす。

ローエンドGPUのことなんてどうでもいいっす

scatter命令のためにSSEをサポートしないのが画期的

>>145
Larrabeeの命令イシューは、VPU命令の大半は片方からのみ、ベクトルストア命令のみもう片方からも発行可能

とインテル資料にあった、はず

>>153
2000年より前に、マイクロソフトのコンパイラの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

これだけ見るとMSの説明と同じだね

Saves live registerというのは、liveでないレジスタは退避しないということ
MSのfiberは、特にスタックフレームを共用していた

>>156
一言でいえば、fiber≒コルーチン

>>156
fiberの解説感謝するす。しかし、
　　-------------------
　　liveでないレジスタは退避しないということ
　　-------------------
これAltiVecならvrsaveレジスタでハードウェアサポートがあるような話すけど。。。
http://www.ibm.com/developerworks/power/library/pa-unrollav1/
　　====================
　　You might think that the overhead of saving thirty-two 128-bit registers would be a little
　　steep, and the designers of AltiVec would agree. To this end, a 32-bit register called VRSAVE
　　has been provided. When the operating system switches context, it saves only the registers
　　whose corresponding bit in the VRSAVE register has been set to one.
　　====================

>>158
fiberは完全にソフトウェアで切り替えるので、切り替え時にliveなレジスタセットはコンパイラが完全に把握しているから
そういう機能は不要

AltiVecのはプリエンプティブなコンテクストスイッチをする場合に有用

>>145
All instructions can issue on the primary pipeline, which minimizes the combinatorial problems for a compiler.
The secondary pipeline can execute a large subset of the scalar x86 instruction set,
including loads, stores, simple ALU operations, branches, cache manipulation instructions, and vector stores.

だってさ

>>159
全然知らんのだが、AltiVecのレジスタに書き込むと、VRSAVEレジスタの対応するビットが自動的に1になるんだろ？

>>105
> >>103←馬鹿だねこいつ。もうプしか言えないだろ。

団子の変な理解が端的に現れているところを挙げてみたんだが、確かにもうプププとしか言えないねww

団子さんここにいたのか
プログラム板の連中が寂しがってたぞ

FiberはマイクロOS上の実行単位じゃね？GPGPUとして使った場合の。


Xeonソケットに刺さるGPUじゃない方の、あるいは純粋なCPUとして使った場合の
プログラミングモデルはまだ示されてない気がする。

どっかの海外記事に普通(regular)のOSは容易に移植もしくはそのままで動くらしく、
マイクロOSとは別個のメモリ空間が割り当てられるとか書いてあった。
これはハイパーバイザで仮想マシンを複数サポートする方法があることを意味するかもしれない。
それってつまりVTもしくはそれ以上の仮想化機構をサポートするってことになるんだが。

変な理解とは

・フェンス命令は一度パイプラインに入ったらリタイアするまでパイプラインをブロックし
たとえ前の命令が例外を起こした時でもパイプラインからフラッシュされないという思いこみ。
・前の制約により破棄可能なストアバッファリング機構が必要であるという思いこみ。
・SSEはLarrabeeではサポートせずx64非準拠になるという思いこみ。



アハハハハ

城島「Intelに『standardな64ビット拡張』って言われてみて、どう思った？」

ま、解ったなら、落とし前はつけような。

つか、かの人はもう一つとんでもない思い違いをしてたかもわからんね。

ここで問題です。
パラメータに依存して複数サイクルかかるような複合タイプの命令を、
マイクロコードに置き換える機能があるのは次のうちどれでしょう？

1.デコーダ
2.実行ユニット




それ考えたら、シンプルデコーダ側でVPUのストア（思うにそれすら一部のみ）
だけしかデコードできない技術的理由は俺はなんとなく解ったよ。

訂正

ここで問題です。
パイプラインにおいて、パラメータに依存して複数サイクルかかるような複合タイプの命令を、
マイクロコードに置き換える機能があるのは次のうちどれでしょう？

1.デコーダ
2.実行ユニット

>>165
> ・フェンス命令は一度パイプラインに入ったらリタイアするまでパイプラインをブロックし
たとえ前の命令が例外を起こした時でもパイプラインからフラッシュされないという思いこみ。

フェンスを理解していないお前がおれの指摘を正しく理解できてないだけだろ…

以下同様

>>168
> ここで問題です。
> パラメータに依存して複数サイクルかかるような複合タイプの命令を、
> マイクロコードに置き換える機能があるのは次のうちどれでしょう？
>
> 1.デコーダ
> 2.実行ユニット
>

何を言いたいんだろう

マイクロコードでもステートマシンでもいいわけだが、
団子頭では

複数サイクル命令==マイクロコードで実装

なんだろうか

>>165
そうそう

> ・フェンス命令は一度パイプラインに入ったらリタイアするまでパイプラインをブロックし
> たとえ前の命令が例外を起こした時でもパイプラインからフラッシュされないという思いこみ。

おれがこういう主張をしているというのなら、該当箇所にアンカーふってくれ
今すぐ首吊ってやんよ

>>172
おれが挙げた例は

「scatter命令が例外を起して、例外ハンドラに処理が移ってからフェンス命令を実行した場合」

だからね
この違いが理解できなかったんだね

>>171
うん、やっぱり団子頭では

「複数サイクル命令は、マイクロコードで実装されなければならない」

ということになってるようだね

やっぱりばかだね

ていうか
たとえばCPUIDの主作用である実行の本質知ってる？
EAXで指定した値を元に、デコーダにぶら下がってるマイクロコードROMを参照し、各汎用レジスタに即値ロードする内部命令に置き換えるんだが。

例のリコール騒ぎになったDIVのバグもマイクロコードのテーブルの誤りだったのは有名な話

LarrabeeがP5が土台ということはマイクロコードベースなんだよ。
というかP6以降はもっと極端で、Complex Decoder Pathを強制される命令は例外なくマイクロコードを参照する。

scatter/gatherに限ってマイクロコード実装にしないという理由がない。
むしろscatter/gatherにエラッタがあった場合
マイクロコードでなければROM更新ではなくリコールするしかない。

>>175
はいはい

gather/scatterがマイクロコード命令でなかったら首吊ってれるかい？

「SSEサポートだったら死ぬ」と明言し
x64準拠と判明しても見苦しく詭弁を
まき散らす行為を、君の定義で「死ぬ」というのなら

俺はそんなみっともない真似はお断りだ

>俺はそんなみっともない真似はお断りだ

団子さんからこんな言葉が聞けるなんて
ちょっと感動

>>177
> x64準拠と判明しても

インテルのどの資料？

>>177
> 俺はそんなみっともない真似はお断りだ

人気のないところで潔く首吊るか腹を切るかしてくれれば結構

電車などは迷惑がかかるからやめてね

さーな、俺の情報筋はWebじゃねーし。

ソースの在処はMACオタにでも聞けよ
>>115って言ってることだし。

これから死ぬ人間にやるような約束などないよ

最後までバカだったね

とりあえずSSEをサポートしない64ビット拡張が未だかつて「standard」であったためしは無いからね。
AMD64/Intel64(EM64T)以外にないんだよ。

>>181
> さーな、俺の情報筋はWebじゃねーし。

さすがに団子の妄想を根拠に首を吊るわけにはいかんからなあ

>>182
> これから死ぬ人間にやるような約束などないよ

お、団子の敗北宣言か？

> scatter/gatherに限ってマイクロコード実装にしないという理由がない。

これが怪しいことに気づいたかな？
ほかの軒かな？

じゃ、MACヲタの出したソースを根拠に死ね

>>175
> scatter/gatherに限ってマイクロコード実装にしないという理由がない。

ごく一般的な物の考え方として、マイクロコードとステートマシンの二通り(と、その組み合わせ)がある場合には

それぞれの長所短所を考えるものだが、団子にはそんなことが念頭によぎった気配すらない

>>183
いまのところ>>96の意見なので、私を引き合いに出すのわ勘弁して欲しいす。
　　---------------------
　　とりあえずSSEをサポートしない64ビット拡張が未だかつて「standard」であったためしは無い
　　---------------------
この業界、自分に都合の良い部分だけ切り取って『業界標準』(industry standard)を名乗るのわ、
ありふれた話なんすけど。。。

>>175
補足すけど、これスカラ整数ユニット限定す。
　　-----------------
　　LarrabeeがP5が土台ということはマイクロコードベースなんだよ。
　　-----------------
躁状態になると騙りやらコピぺやら、何でもアリの相手すから、死ね死ね言わない方が良いと
思うすけどね。。。

既存のIAでSSEのミスアラインドロード・ストア命令は例外なくマイクロコードだったな。
agner.orgにオペレーション数の解析結果まで載ってる。

複数回かかる仕様のロード・ストア命令がマイクロコード実装なのは
P5以降Intelアーキテクチャでは100％そうだし

逆に、実行ユニットで初めて分解するようなのはP5ベースではなく
新規のマイクロアーキテクチャということになってしまう。
実行ステージに突っ込むまでサイクル数が解らないオペレーションなんて、
スケジューラで管理しきれないしさ(笑

>>190
　　------------------
　　既存のIAでSSEのミスアラインドロード・ストア命令は例外なくマイクロコードだったな。
　　agner.orgにオペレーション数の解析結果まで載ってる。
　　------------------
複数のuopsに分解するという話と、マイクロコード実行わ『別物』でわ？

＞MACオタ
君の解釈は聞いてないからただソースだけを貼ってくれ。

>>192
x86わ良く知らないんで質問しているすけど、何か痛い所を突かれて逆切れしたすか？

>>192
> 君の解釈は聞いてないからただソースだけを貼ってくれ。

団子さんからこんな言葉が聞けるなんて
ちょっと感動

>191
本質的同じものだよ。粒度が違うだけ。
IntelのいうマイクロオペレーションはP6で初めて使いだした言葉で、
マイクロコードに対してもっと粒度の小さいRISCライクオペレーションという意味。
複数マイクロオペレーション使う命令は必ずマイクロコードROMを参照する。

あ、PenM以降のμOPs Fusion可能なものだけは、一般デコーダでダイレクトにデコードできるけどね。
いずれにしても各実行ステージの手前で切り離す。

妙に報道が少なかったHot Chips 20すけど、富士通の発表もあってか安藤氏わ参加していた
様す。とりあえず今日の更新わ、Larrabeeとr龍芯、3Leaf Systems社のネットワーク経由でのccNuma
の話題す。
http://www.geocities.jp/andosprocinfo/wadai08/20080830.htm

ちなみに最後のわ、EDNのブログでも取り上げていたす。
http://www.edn.com/blog/980000298/post/450032245.html

>>195
　　----------------
　　本質的同じものだよ。粒度が違うだけ。
　　----------------
それでわ、何故マイクロコード実行わCRISCの概念より古いすか？
agner氏の資料を見れば明らかなように、単一のuopsで複数サイクル実行のモノもあるし。。。

浮動小数のこと？

P5にはP6にあるようなfxchによる依存関係の解消の機構がないから
レイテンシがそのままサイクル数になってしまうだけだよ。

ロードやストア回数が複数にわたる場合は必ずその回数分以上の
マイクロコードあるいはマイクロオペレーション数に分解されているはずだ。

おっとrepは小さいループに変換されるだけだがな

>>198
　　----------------
　　P5にはP6にあるようなfxchによる依存関係の解消の機構がないから
　　----------------
P5にuops分解機能わ無いす。P6で複数サイクル実行のuopsを含む命令わ、
IMUL, AAM, DIV, IDIV, 複雑なFP命令(SSE含)す。

>>199
ARMでもか？

別にもったいをつけるつもりわ無いすけど、ハードウェアロジックでも複数のユニットを占有したり、
回帰計算を行うために複数サイクル必要な命令わ在るす。

おそらく現代的な設計のプロセッサで、実行ステージでマイクロコードROMを一々読んでプログラムを
実行するモノわ無いと思われるす。
命令に関するエラッタが存在したとしても、パッチわデコードユニットでトラップして代替命令に置き換
える程度じゃ無いすかね。

たとえば
add eax,[edx]
を
分解せずに実行してたのがP5まででありいわゆる従来のCISC
ロードと加算に分解して実行するのがP6でありいわゆる内部RISCと言われるやつ。

その意味ではK7やPenM以降はCRISCって言っていいのかは疑問だな。まあ最終的には分解してるんだが。

分解しないと実行できないような複雑命令はそもそも載せないのが
P&Hの理論にもあるような純RISCだったじゃね？

複雑な命令の実行をマイクロコードに頼ってたのはCISC

でも昔ながらのRISCをうたうCellですら倍精度はマイクロコードだったような。POWERには8バイト命令もあって、固定長ですらないしな。


CISC/RISC論は既に現代では通用しない。

>>205
やっぱりマイクロコードとステートマシンの違いがわかってないようだ

>>206
おっと、実行ユニットがマイクロコードを持っていることもあるから、正しく団子用語の

>>168
> パイプラインにおいて、パラメータに依存して複数サイクルかかるような複合タイプの命令を、
> マイクロコードに置き換える機能があるのは次のうちどれでしょう？
>
> 1.デコーダ
> 2.実行ユニット

＞実行ユニットがマイクロコード

はい？
それいつの時代のどこのアーキテクチャですか？
もちろんIntelのP5以降のCPUの話ですよね？
パイプライン化すらされてない時代の話なら笑うしかないよ？



ま、どっちにしろ、まだExecuteにも達してないフェンス命令が前の命令の例外が起きてもパイプラインから棄てられないなんて
脳内動作の根拠にはならないんだが。

まあ、こいつはおそらくP5以降のIntelアーキテクチャのブロックダイアグラムで
マイクロコードROMがどこにぶら下がってるか見たこともないんだろうな。

デコーダで解決した方がデコード後のスケジューリングコストがかからないんだけどな。

>>208
> ま、どっちにしろ、まだExecuteにも達してないフェンス命令が前の命令の例外が起きてもパイプラインから棄てられないなんて
> 脳内動作の根拠にはならないんだが。

そりゃこんなこと言ってるの団子だけだし

おれが言ってるのは「例外ハンドラ内で」フェンス命令を実行した場合

＞例外ハンドラ内で
バカすぎる
なんの目的で使うんだよ
お前プログラム組んだことないだろ

あ、例外発生前にパイプラインに投入されたフェンス命令が例外後も残ってるなんてのは論外な

>>211
> ＞例外ハンドラ内で
> バカすぎる
> なんの目的で使うんだよ

あっ、団子は例外ハンドラがどういうものか理解してなかったんだよな、ゴメンゴメン

例外が発生した後は、どうしても
・共有データであるところのページテーブルを更新したり
・ページインのためにI/Oを開始
したりするんだぜ？

バカでもわかりやすいかと思って「例外ハンドラ内で」というシチュエーションを考えたけど、逆効果だったかな
例外ハンドラから抜けてからフェンス命令を発行しても同じこと

中断したscatterの扱いはどうなるの？

余談だけど、ノンテンポラルストアはLarrabeeにおいてはキャッシュプライオリティモデル
おける優先度最低のそのまた下と位置付ければ、
プライオリティモデルに基づく既存プロトコルの延長でL1をスルーする動作を実現できるかもしれないね。
実装次第ではフェンス命令はNOP扱いしてよくなる。

>>214
上半分もトンチキだが

> 実装次第ではフェンス命令はNOP扱いしてよくなる。

まーだこんなこと言ってやがんの
プププのプ

＞例外ハンドラ

昔は知らんが最近はC++/javaでいうcatchブロックなんかののことを言う。
現行32ビットアーキでは復帰可能なページフォルトはCPU内で解決される。
OS→アプリに通知されるのは無効命令やアクセス違反など続行不可能なもの。

何年もののバカだよ

まあ#PFが飛んでくる条件なんて32ビットOSのソースもさわったことないおっさんには解らんだろうがな
レベル低すぎる

まさかリアルモードでSSE使おうとか思ってねーよな？

>>216
団子はちゃんと答えてくれるんで好感度は高いが

> ＞例外ハンドラ
> 昔は知らんが最近はC++/javaでいうcatchブロックなんかののことを言う。

一般的に例外ハンドラというのは、CPUが例外を起したときに、例外ベクトルテーブルを参照して飛んでいく先のこと
団子も説明も嘘ではないけど、文脈的におかしいんだわ

x86だと、IDTで例外ベクトルテーブルを指定してたっけ
インテルのマニュアルにも例外ハンドラの説明あると思うよ


> 現行32ビットアーキでは復帰可能なページフォルトはCPU内で解決される。

それはページミスの説明

> OS→アプリに通知されるのは無効命令やアクセス違反など続行不可能なもの。

ページフォールトは、こちらの続行不可能なものに入る


これでは話が通じないわけだ

だからOSのソースも読まずに妄想ほざいてろ。
どこに例外拾って*fenceを呼ぶ実装があるんだよ。
Linuxカーネルのソースでもgrepして引っかからないのを確認して
そして即刻氏ね

一番シンプルな説明だと

TLBにヒットしない→ページミス

　ページミスすると、CPUが自動的にページテーブルを参照して、必要なページテーブルエントリを探す

　　必要なページテーブルエントリがない場合→ページフォールト

　　　ページフォールトが発生すると、CPUは例外テーブルを参照して、(通常はOS内の)例外ハンドラに制御がうつる

はい、その時点で復帰不可能だよ。

>>222
復帰不可能というのをどういう意味で使っているのかがわからんのだが
少なくとも半分は正しい

とりあえず>>221を理解して、
> 現行32ビットアーキでは復帰可能なページフォルトはCPU内で解決される。
これを撤回してくれるかな？

めんどいからLinuxカーネルソースでいうどこのコードの何行目でやってるか引用してみろ。

>>224
お前さんが一般論が苦手なのは知っているが、説明のためのただの一例に、そのまでするのはやなこった

OSに飛ぶ段階で既にOSがフェンスを呼ぶ必要はない。
それとも、キャッシュをバイパスして例外ハンドラのコードをフェッチできるんか？

>>226
> OSに飛ぶ段階で既にOSがフェンスを呼ぶ必要はない。

なんか妙なこだわりがあるな

ページフォールトを起こした命令と、OS内(でもどこでも)のフェンス命令は、無関係だよ

ページフォールトが「起きたから」、フェンスを呼ぶ必要があると捉えているなら、間違いだ

アプリプログラマの団子とは縁のない命令だが、iretにはそもそも逐次化作用があるんだけど、忘れてたのかな？

OSがトラップする前にCPUは自分自身である程度の後始末はすんでる。
とりあえず例外ハンドラの実装読んでみろと。
読まないことには始まらない。

俺が指摘するまでCPUIDのフェンス効果も知らなかったバカがなんか言ってるよ

>>229
> OSがトラップする前にCPUは自分自身である程度の後始末はすんでる。

どういう例外の場合にはどういう処理をするのかな？
ニヤニヤ

Intelが64ビット拡張が「standard」であることを示すソースを未だに探せない頭の悪い子にはうまく説明する自信がないな。
ヒント：今年で20回目

>>232
話を逸らさなくても優しくしてやるから、ページミスとページフォールトの違いについては理解できたかな？

ていうか>>113

まあトラップの仕組みはまあいいよ。ミスした命令を再実行すればいいじゃん。
どう考えても破棄可能なバッファは必要ないね。

>>234
Plus standard 64-bit instruction extensions
は
Plus Intel64(R) instruction extensions
じゃないよね？

>>235
> まあトラップの仕組みはまあいいよ。ミスした命令を再実行すればいいじゃん。

誤ちを認めてくれるのは結構なこった
が、気軽に
> ミスした命令を再実行すればいいじゃん。 どう考えても破棄可能なバッファは必要ないね。
こんなことを言ってくれるようでは困る

で、なんで二度書きしたら困るんだ？ﾆﾔﾆﾔ

>>238
アプリプログラマの知らなくていいことだけど、I/Oなんかの都合上とてもまずい

>>236
どこにx64以外のstandardがあるんですか？バカですか？
だからとっとと死ね

I/Oの都合がある処理でSSEなんて使わないから。ハイハイ

むしろ規格準拠くらいの意味だな

>>241
> I/Oの都合がある処理でSSEなんて使わないから。ハイハイ

団子の大好きなインテルのマニュアルに、I/O領域に対するメモリアクセス禁止って書いてあるの？

＞I/O領域
ハードウェア予約領域のことか？
そもそもアプリじゃさわりませんｗｗｗ

>>244
アプリプログラマに聞く質問じゃなかったサーセン

ライトコンバインなんてカーネルモードですらやんねーよ普通
マルチスレッドなんぞ論外だし

カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。

>>247で団子さんの書いているのわ、この話題す。(ということで良いすか？)
http://www.nabble.com/ABI-change-for-device-drivers-using-future-AVX-instruction-set-tc18116359.html

>>248
どっちにしろ、おれの出した話題とは何の関係もないのだが

> >>247で団子さんの書いているのわ、この話題す。(ということで良いすか？)

これが本当なら、

団子> カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。

One problem that has not been resolved yet, AFAIK, is how to handle the
possible use of YMM registers in device drivers. Should these registers
be saved before calling a device driver from an interrupt or should it
be the responsibility of the device driver?

聞いてない。
x86の64ビット拡張の「standard」とは何ですか？
さっさとけじめつけろや、ｺﾞﾙｧ

>>250
インテルがIntel64(R)でなくstandardとしか言ってない以上、わかるかボケ

>>250
んで、
団子> カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。
のソースは>>248でいいのか

いいわきゃないよな？こんな恥かしい間違いわ

standardがx64以外にあるかボケ
詭弁も甚だしい


結論から言ってカーネルモードで使えるけど保証はないのはガチ。

>>253
団子> カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。

誰がどこから何という回答を貰ったのかな〜？
Agnerという人は"One problem that has not been resolved yet"って言ってるよ

>>253
おっと

> 結論から言ってカーネルモードで使えるけど保証はないのはガチ。

「保証はないのはガチ」ってねえ、>>248のリンク先ちゃんと読んだの？
memcpyのあたりだよ

>>255
3. When compiling a device driver, the compiler may insert implicit
calls to library functions such as memcpy and memset. These functions
typically have a CPU dispatcher that chooses the largest register size
available. The device driver may therefore use YMM registers without the
knowledge of the programmer and without compiling with the AVX switch on.

「死人」には黙ってて貰いたい。ゾンビくん。
俺は一切回答もしないよ。
それとも未だにx64非準拠の確信(笑)あるのかな
単に生きたいだけかな？ｗｗｗ

>>257
> 俺は一切回答もしないよ。

まあ、これ以上何か言ったところで恥の上塗りだから、それがいいと思うよ

> カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。

団子の英語力からすれば>>248を理解できなかったは不思議ではないが、これは許してやんよ
まさかお前の妄想に箔をつけるためにAgner氏の名前をデッチ上げたんじゃないだろうな

で、ローエンドGPUのlarrabeeでXが使えるようになると
何が面白いのかね

生き恥がなんか言ってるよｗｗｗ
ま、ライトコンバインなんかまともに動く保証はないんじゃね？

>>260
今なら白状しても許すよ
「わたくしこと団子は、Agner氏の名前で大嘘をデッチあげました」

> ま、ライトコンバインなんかまともに動く保証はないんじゃね？

SSE完全互換じゃなかったの？？

団子> カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。

Agner> One problem that has not been resolved yet, AFAIK,
Agner> is how to handle the possible use of YMM registers in device drivers.

＞Xが使える
生き恥のさらに上塗りだな。
「X」なんてVESA準拠のカードなら専用ドライバなんてなくても使えるよ。
GPUの機能使わずフレームバッファに直に書くだけならな。
PS3のLinuxもRSXのドライバは用意されてない（アクセスすら禁止されてる）がGNOMEが普通に立ち上がる。

ま、OpenGLのドライバが使えるのは有意義だよ。かなり。
ぶっちゃけMS環境自体にはあまり期待できないんだよ。
メニーコア周りのサポートとか。
未だに上限32or64スレッドまでしか使えないし。

その点、IntelコンパイラもLinux版は無償で使えるからな。

だからそれの何が面白いことになったの？
発言者さん

Larrabeeでlinuxを動かして、本体CPUをXアクセラレータにして遊ぶ

x用のドライバが出来ても
OpenGLが使えるかどうかってのは
また別なはなしだが

専用ドライバなしでもWindowsすら動くしな
死ぬほど遅いけどww

よりにもよって「Xが動く」ｗｗｗｗｗｗ
ドライバすらいらねーっつーのｗｗｗｗｗｗ

>>266←ｗｗｗｗｗｗ

おい団子、他の人に迷惑かけるな

団子> カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。
これのソースはどこなんだよ

MACヲタに代理回答なんて頼んだ覚えはないが。

ま、推奨か非推奨かはIntelのマニュアルにもあることだな

死人は棺桶のなかでおとなしくしてて下さい。
書き込むだけで迷惑ｗｗｗｗｗｗ


Intelがｗｗｗｗｗｗ
Larrabeeでｗｗｗｗｗｗ
SSEをｗｗｗｗｗｗ
サポートしたくないｗｗｗｗｗｗ

「IntelはSSEをサポートしたくない」のソースをお願いします。

他人にソースを求める立場ではないの自覚しような

x.orgのドライバーだけでGLXが動くと思ってる馬鹿がいるな
仕様を公開してるATIやVIAならともかく・・

フェンス命令に中途半端に完了
のソースまだー？


死人に無知鬱

>>269
　　---------------------
　　団子> カーネルモードドライバではSSEもAVXも利用は想定されてない。Agner氏がIntelからもらった回答。
　　これのソースはどこなんだよ
　　---------------------
英語が読めないのか、groups.google.com型のサイトの読み方が判らないのかどちらかだと思うすけど、
>>248のリンク先にわ、intelのArjan van de Ven氏から次のような回答が寄せられているす。
　　======================
　　Let me repeat this loud and clear:
　　It is not allowed to use floating point, SSE of AVX in device drivers.
　　======================
ちなみに団子さんと同じ資料を読んでも、私が>>96のような意見なのわレガシーなx86コードの大半が
Linuxカーネルと同じ状況だからす。

団子は何か勘違いしている

おれのは予想で、出しているのは傍証
証拠もないのに事実だと決めつけているのはお前だけだ

予想と事実、傍証と証拠の違いくらいわかるよな？

Arjan van de Ven氏の身分の参考に。
http://www.linuxjournal.com/content/interview-arjan-van-de-ven-intel-and-lesswattsorg
　　-------------------
　　Linux Journal recently caught up with Intel's Arjan van de Ven. Van de Ven leads Intel's green
　　Lesswatts.org initiative and is the developer of PowerTOP, one of the most acclaimed power
　　management tools on the Linux platform.
　　-------------------

GLXｗｗｗｗｗｗ

つかOpenGL自体プログラミングスタックにあるし。
IntelがLinux環境に好意的なのは有名な話だしな。
AtomベースMIDのSDKはLinux版以外あったっけな

「Standard」の意味が解らないと見苦しい事を言ってる馬鹿ならいるな

standard 64-bit extensionの意味も解らないって素敵だね。
英語がわからないから約束守る必要ないなんて理屈がまかり通るなら
英語知らない方がいいようだな

standard 64-bit extensionにフェンス命令は含まないんですか？
Intelは含めたくないんですか？

P5アーキがデコーダでマイクロコードに展開するという常識もない人間に傍証も糞もない
詭弁とこじつけだけ

はいはーい、またまた精神破綻者の独り言の始まり始まり

あ？精神病がなんか言ってるよ
死ぬって言って死なないのはメンヘル女の特権だぞボケ

男ならけじめつけろや

>>275
続きがあったのは気づかなかったが
Arjanとケンカしてんじゃん
Andiの指摘までAgnerは納得してない

だいたいこれ、Linux固有の話しじゃん
一般論のできない君らとはいえ、こいつぁひどい

P5のマイクロコードがデコーダから供給されることも知らない人の一般論には
説得力があるな

>>286
捏造するのはヤメテ
罵倒するときはアンカーつけて

AMD64/Intel64はx86の64ビット拡張のstandardでない
ですね、わかります

SSEやCPUIDを排除してLNIをサポートしたのを64ビット新標準にすればいいですね、わかります

>>288
十分条件と必要条件の区別のつかない団子らしい発言です

>>289
CPUIDを実装しないなんて一言も言ってないが
他人を罵倒するために捏造するのはやめて

確かに288は頭の悪すぎる発言だなw

捏造しているのか、理解できていないのかはともかく、
罵倒するときはアンカーかコピペたのんます

x86アーキにおいてスタンダードな64ビット拡張であるにはx64準拠は必要条件。
x64準拠であることはSSEサポートの十分条件。

ですね、わかります。


わかったら氏ね

standardであることとSSEをサポートしないことは「矛盾」

完璧であったはずの論理が覆されたのはどう思った？

前提に誤りがあると微塵も思わないんだもんなー
固定観念に縛られすぎて常識とずれてしまってることは自覚しような。

「ページフォールト時のスワップ処理」
→ビデオカードにはそもそもスワップできるデバイスなんて載らないよ。フローなんて復帰できるわけがないよ。
あとHPC版はメモリ馬鹿みたいに積むからなあ。スワップ？なにそれおいしいの？
ま、スワップアウトありでいいや。でも
「ページ解決後に2度書きするのイクナイ！」
→なんならプログレスカウントに汎用レジスタでも使う仕様にすれば？
たとえば1ビット×16でストア対象要素を指定し、正常完了したものから対応するビットにマスクをかける。
最終的に0またはFFFFになる。そうすれば途中中断しても復帰できるよ。
スカラとベクタは並列実行できるし。

「メモリコンシステンシモデルを緩める必要がある」
→だからそうすればいいじゃん。フェンス命令の実装関係ない。

「SSEは非対応。x64とは非互換になる」→Intelは標準の64ビット拡張と言ってはりますよ。どこにそんな標準があるんですか？

ま、せっかくだから「ぼくのかんがえたさいきょうのめいれい」書いておくか。ま、我ながらいかにも「Intelアーキらしい」仕様だな

vscatvps [mem32],zmm1,zmm2

[mem]：起点アドレス
zmm1：ストアデータ
zmm2：アドレスのオフセット×16

ecx：下位16ビットで処理するビットのマスクを指定。ストア毎に順次要素に対応するビットをマスクしていく。

これもあくまで一案だが、デコーダのマイクロコードで実装するから可能な仕様だな。
VPU実行ステージでマイクロコード分解するなんてIntelが経験したことない珍妙な仕様じゃ不可能だよね。

ストリング命令同様、スワップを挟んでも復帰できる仕様は満たせる。



ま、俺も彼の言い分を理解してなかったのは認める。
カーネルソース読んでみて言いたいことの意味分かったよ。
俺もスワップなんて想定してるとは想定外だったからね。
ビデオカードにHDDでも接続するなんて発想はなかったからさｗｗｗ
HPC版じゃスワップなんて普通させないくらいメモリ積むだろうし。

WDDM2.0からVRAMをスワップアウトするようになったはずだけど

今回のネタでbinutilsのソースが引用されたついでにPOWER7のVSX ISAの公開部分について
調べてみたす。
　- 命令フォーマット
　　XX1(引数1)とXX3(引数3)のフォーマットの存在が確認。4引数の命令が無いため、積和や
　　vector permute命令わ、ソースを上書きする？

　- データ形式
　　今のところ8-byte x 2データ以外の言及わ無し

　- 命令 (XT/XS/XA6/XB6: VSXレジスタ, RA/RB, 汎用レジスタ)
　　lxvd2x XT, RA, RB (Load Floating-Point Double X-Vecor Indexed X-form?)
　　　RAとRBの和で求められる実効アドレスから2つの倍精度浮動小数点データをXTにロード
　　　　　　　　　　　　　　　
　　lxvd2ux XT, RA, RB (Load Floating-Point Double X-Vecor with Update Indexed X-form?)
　　　RAとRBの和で求められる実効アドレスから2つの倍精度浮動小数点データをXTにロード後、
　　　RAに実効アドレスを格納

　　stxvd2x XS, RA, RB (Store Floating-Point Double X-Vector Indexed X-form?)
　　　RAとRBの和で求められる実効アドレスへXSの内容(double x 2)をストア

　　stxvd2ux XS, RA, RB (Store Floating-Point Double X-Vector with Update Indexed X-form?)
　　　RAとRBの和で求められる実効アドレスへXSの内容(double x 2)をストア後、RAに実効アドレス
　　　を格納

　　xxmrghd XT6, XA6, XB6 (X-Vector Marge High Floating-Point Double?)
　　　XA6の上位倍精度浮動小数点データとXB6の上位倍精度浮動小数点データを並べてXT6に格納

　　xxmrgld XT6, XA6, XB6 (X-Vector Marge Low Floating-Point Double?)
　　　XA6の下位倍精度浮動小数点データとXB6の下位倍精度浮動小数点データを並べてXT6に格納

　　xxpermdi XT6, XA6, XB6, DM (Permute Floating-Point Double Immediate?)
　　　XA6とXB6の倍精度浮動小数点ベクトルを2bitのDMフィールド表現に従って並び替えてXT6へ
　　　格納

　　xvcpsgndp XT6, XA6, XB6 (X-Vector Copy Sign of Floating-Point Double?)
　　　XB6の倍精度浮動小数点ベクトルを符号ビットのみXA6からコピーして、XT6へ格納

"xxpermdi"命令すけど、DMフィールドが4-bitなら曲がりなりにもvector permuteっぽい動作に
なるすけど、何故か2-bitの模様す。単なるコピーとやsplat命令、"xxmrghd", "xxmrgld"命令と組み
合わせて全16通りをカバーするのかもしれないす。

でも、これ並べ替えをレジスタの内容でダイナミックに変更できるAltivecのvperm命令と比較すると
命令や直値で指定するのって、何か意味があるすかね？

決めうちできる場合は1命令減らせる。

自分でカーネルプログラミングに浮動小数点わ無い(>>275参照)とか書いておきながら、データを
倍精度浮動小数点とか書いていたのわ大間違いす。ニーモニックに含まれる"d"わ"Doubleword"の
略すね。。。
で、命令の行わ修正す。

　- 命令 (XT/XS/XA6/XB6: VSXレジスタ, RA/RB, 汎用レジスタ)
　　lxvd2x XT, RA, RB (Load Doubleword X-Vecor Indexed X-form ?)
　　　RAとRBの和で求められる実効アドレスから2つの64-bit整数データをXTにロード
　　　　　　　　　　　　　　　
　　lxvd2ux XT, RA, RB (Load Doubleword X-Vecor with Update Indexed X-form ?)
　　　RAとRBの和で求められる実効アドレスから2つの64-bit整数データをXTにロード後、
　　　RAに実効アドレスを格納

　　stxvd2x XS, RA, RB (Store Doubleword X-Vector Indexed X-form ?)
　　　RAとRBの和で求められる実効アドレスへXSの内容(64-bit整数 x 2)をストア

　　stxvd2ux XS, RA, RB (Store Doubleword X-Vector with Update Indexed X-form ?)
　　　RAとRBの和で求められる実効アドレスへXSの内容(64-bit整数 x 2)をストア後、RAに実効アドレス
　　　を格納

　　xxmrghd XT6, XA6, XB6 (X-Vector Marge High Doubleword ?)
　　　XA6の上位64-bit整数データとXB6の上位64-bit整数データを並べてXT6に格納

　　xxmrgld XT6, XA6, XB6 (X-Vector Marge Low Doubleword ?)
　　　XA6の下位64-bit整数データとXB6の下位64-bit整数データを並べてXT6に格納

　　xxpermdi XT6, XA6, XB6, DM (Permute Doubleword Immediate ?)
　　　XA6とXB6の64-bit整数ベクトルを2bitのDMフィールド表現に従って並び替えてXT6へ
　　　格納

　　xvcpsgndp XT6, XA6, XB6 (X-Vector Copy Sign of Doubleword?)
　　　XB6の64-bit整数ベクトルを符号ビットのみXA6からコピーして、XT6へ格納

>>303
なるほど、コメント感謝するす。

AVXのvpermil2psって便利だな。
xmm1,xmm2,xmm3,xmm4から任意の要素をピックアップしてxmm0にマージする場合
メモリにパターンデータを用意しておいて

vmovdqa xmm7,[mem]
vpermil2ps xmm0,xmm1,xmm2,xmm7,2
vpermil2ps xmm5,xmm3,xmm4,xmm7,3
vorps xmm0,xmm0,xmm5

逆に256ビット版がいまいち使いにくい。128ビット版AVXの2並列実行でしかないからね。

>300
GPUが自発的に？

>>307
「自発的に」の意味を明確にしてくれないとなんとも。
CPUのスワップアウトだってCPUが「自発的に」HDDにアクセスするなんて曖昧な表現しないだろ？
もっとも、4亀によればOSに対してGPU自身が「自発的に」スワップアウトを要求するそうだけど。
多分GPUがやる仕事は、コマンドプロセッサでタスク毎にメモリ不足を検出してドライバ側に通知するのと
ドライバが用意したスペースにDMA転送するくらいだろうね。
ttp://www.4gamer.net/news/history/2006.05/20060530200736detail.html

団子の実装では、Larrabeeは自意識に目覚めて自発的にページングします

書き込み制限が解除されたよ！

>>298
言い訳がまじっていて見苦しいが、そう的を外してなさそうだからいいか

ダ> 「メモリコンシステンシモデルを緩める必要がある」
ダ> →だからそうすればいいじゃん。フェンス命令の実装関係ない。

これは半分正しいし、半分は団子の主張と一貫性が書けてるんだ

マイクロOS側で透過的にやれるのか、ホスト側のドライバで確保してやるのかって話だよ。


SSEをサポートしてないことにしたい珍説の新作が見たいものだ。

現時点の公開情報をみてもSSE非サポートってのはまずあり得ないわけだし、
スワップを考慮した実装要件から新命令の仕様考える方が有意義だと思うけどね。

新命令の仕様の思いこみありきで整合の取れない既存の概念を否定しようとするから
事実上の自殺宣言になっちゃうんだよ。
ちなみに俺はx64命令セット準拠って最初から知ってたぞ。何度も言うことだけど。

>>311
一応言っとくと300=308≠ID:PukrVIoWね。
透過的にとかそこら辺の具体的な意味がわからないとなんとも言えないてばさ。

資料読んで気づいたこと
P5ではUとV、どっちでデコードするかで実行ユニットもU側かV側か決まってしまっていたが
Larrabeeはデコードは2機のうちComplex/Simpleどっちを経由してもデコード後にマイクロ命令が合流し
Scaler/Vectorどちらに流し込むか改めて振り分けを行うように見える。

この構造はぶっちゃけP5というよりはAtomに近い。

【standard 64-bit extensionなんて表現をした理由】

他の用語を使いたくなかっただけじゃね？
・Intel 64
Core2 Duoで初めて使った言葉だから、SSSE3までを含むと誤認されるかもしれない。

・EM64T
旧称だから使いたくない

・AMD64/x86-64/x64
すごく、屈辱です

結局のところSSSE3以降をサポートしないんじゃね？デコード容易とは言い難いし。
逆に3バイトOpcodeデコードに対応するならSSE4まで全部対応できそう。

邪推してもしかたないな。
ただ単にあくまで学会発表だから、Marketecture的な名称を出すのを
避けただけという考えるのが妥当かもしれんよ。
たとえば「Hyper-Threading」ではなくSMT(FGMT)というようなレポートになってるし。

「Intel 64」とかの具体的名称が出るのは次のIDFくらいじゃね？

>>315
裏を取っているなら、そんなにキョドる必要わ無いと思うすけど。。。
　　--------------------
　　・Intel 64
　　Core2 Duoで初めて使った言葉だから、SSSE3までを含むと誤認されるかもしれない。
　　[中略]
　　ただ単にあくまで学会発表だから、Marketecture的な名称を出すのを
　　避けただけという考えるのが妥当かもしれんよ。
　　--------------------
Siggraphより遥かに格の高いISSCCの論文で、サポート命令をどのように記述しているか自分で
確認してみれば良いかと思うす。
http://download.intel.com/pressroom/kits/isscc/ISSC_Intel_Paper_Silverthorne.pdf

個々の命令サポートまでは知らないよ。
俺が知り得た情報はx64既存の64ビットOS（カーネルだけじゃなしに周辺プログラム含む）
がそのまま、あるいはほとんど変更なしで使えるという情報。
この時点でSSE2までは無条件でサポートしてることが前提だからね。
あとはいつIntelが明言するかの話。

むしろ仮想化技術について言及しないことが謎。

Hot Chips 20のSUN Rockのプレゼンす。
http://www.c0t0d0s0.org/archives/4774-Presentation-about-Rock.html

去年の段階で、命令セットレベルでのホモジニアス性を保つ云々は、後藤は
自分の記事で扱ってるんだよな。さんざん互換性を重視するIntelの姿勢を
伝えてきた。
「SSEはおそらくサポートしない」なんて迷言がなんでいまさら
彼の記事から飛び出したのか謎なんだがな。

結局のところ、事実をありのままに伝える後藤は良い後藤で
自分の頭で考えて推論を述べる後藤は悪い誤答なんだろうね。

http://pc.watch.impress.co.jp/docs/2007/0611/kaigai364.htm
>　システムまたはチップの中に、ヘテロジニアスなコアが混在しても、
> 命令セットはできる限りホモジニアスに保ち、アプリケーションからは
> 可能な限り隠蔽する。それがIntelのポリシーのようだ。異なるコアタイプの
> 制御を行なうとしても、それはOSやHypervisor層がハンドルするという
> 構想だ。

ところでこっちのソースに基づけばμOS自体もHypervisor配下のゲストOSという扱いなんだろうか。
まあ、そうなんだろうね。
↓Larrabee上でのOSの実行形態についていろいろ
http://arstechnica.com/news.ars/post/20080804-larrabee-intels-biggest-leap-ahead-since-the-pentium-pro.html

つーか、「Pentium Pro以来の最大の革新」ってうたい文句、Pentium 4のときにも
Core 2 Duoの時にも、更にNehalemにも言ってる気がするんだが。
「一生のお願い」とか「俺の18番」とか「芦屋に家が建つ」並みの意味ってことでOK？

いや、
もうPentium Pro以上の大革新は二度とおこせ無い
今回もPentium Pro未満の革新でした。
って意味だよ。

こういうのもネット弁慶の一種なんだろうな
否、2ch弁慶か

HOT CHIPS 20 - Tukwila、SPARC64 VII
http://journal.mycom.co.jp/articles/2008/09/02/hotchips3/index.html

>>321
オマエモナー

Intel: AVX
POWER: VMX
SPARC64: HPC-ACE

団子どこいったの？

いつも思うんだが、
intelとかAMDの一般人程度が買えるチップセッットのIOPSってどの程度のものなの？
最近の事情をみているとCPUの処理能力上げるより、チップセットのIO能力あげたほうが、
システムの性能あげやすくないか？

個人だとチップセットよりも先にHDDに足を引っ張られるんじゃないか？
鯖みたいにアクセス一杯くるからRAIDとかいうわけでもないだろうし。
SSDレベルだとどうなんだろうな。

>>325
ｵﾚの隣で寝てるよ

>>328
あぁ、お前団子と一緒に食った水羊羹か
まだ消化されてなかったのな

妻乱

POWER7のスーパーコンピュータ"Blue Waters"が予算を獲得したらしいす。
http://www.networkworld.com/community/node/32152
　　----------------------
　　The 200,000 processor core system known as Blue Waters got the green light recently as
　　the University of Illinois at Urbana-Champaign and its National Center for Supercomputing
　　Applications (NCSA) said it has finalized the contract with IBM to build the world's first
　　sustained petascale computational system.
　　[中略]
　　Blue Waters will be based on what researchers called PERCS (Productive, Easy-to-use,
　　Reliable Computing System).
　　----------------------
Blue Watersに関するThe Registerのスクープわコレす。
http://www.theregister.co.uk/2008/07/11/ibm_power7_ncsa/

上のニュースに関するNCSAのプレスリリースす。
http://www.ncsa.uiuc.edu/News/08/0827Universityof.html

＞"Blue Waters"
…ナディア？

今　君の目に　いっぱいの未来♪

すべってーをー　かーあがーーやかすー

TGDailyによるとIntelわ2月に買収したゲーム企業Offset TechnologyにLarrabee対応のゲームエンジン
を開発させるんだとか。
http://www.tgdaily.com/content/view/39211/135/
　　---------------------
　　To demonstrate its horsepower, Intel will have to have at least one compelling launch title --
　　and to make sure that it will exploit everything Larrabee has to offer, the company purchased
　　Offset Software in early 2008.
　　---------------------

Ando's Microprocessor Informationの今日の更新ってMYCOMのレポートより詳しいのわ
何故なんすかね。。。ちなみに主なお題わRockとSPARC64 VIIす。
MYCOMのHot Chipsレポートもスライド画像が少なくてがっかりしたす。

HOT CHIPS 20 - Intelのグラフィックプロセサ「Larrabee」
http://journal.mycom.co.jp/articles/2008/09/06/hotchips5/001.html
Q.
何故、32ビット×16並列の512ビット幅のベクタ演算器なのか、256ビット幅にし
てNehalemの次世代のSandyBridgeで実装予定のAVX(Advanced Vector Extension)
との機能の共通化をしないのは何故か
A.
AVXは汎用的な計算処理を目指しているが、Larrabeeのベクタユニットはグラフィ
ックス処理をメインに考えており、最適化のポイントが違う

今晩わ安藤氏のHot ChipレポートでMYCOMが怒涛の更新の様す。>>338以外にも
Rock http://journal.mycom.co.jp/articles/2008/09/06/hotchips6/index.html
龍芯 http://journal.mycom.co.jp/articles/2008/09/06/hotchips7/index.html
FPGA http://journal.mycom.co.jp/articles/2008/09/06/hotchips8/index.html

>>337で失礼なことを書いてしまってお詫びいたします。

そう言えば、何故「龍芯 (Loongson)」=Godsonなのかと思っていたすけど、"son"の方わ、そのままとして
「龍」=「神」なんすか？中華的に。

>>339
乙

ついにでたか
次に投機的スレッド実行を実装するのはどこになるんだろう?
ページングと同じようにCPUに実装される標準技術になるのか、それともROCK専用機能になるのか
昨今のCPUは必ず性能が上がることがわかっていても
トランジスタを食う技術はなかなか実装しそうにないしな

もしかしたらキャッシュを小量ですませる技術として流行るかもしれん

Core2で既にクロックゲーティングを含むロジック部よりSRAM部のほうがでかいくらいだし、
多少はいいんじゃね？


CellのSPEはソフトレベルでスカウトスレッディングみたいなことは出来そうだけど
そういうテクニックは未だに活用されてる話を聞かないな。

>>342-343
こう言っちゃ悪いすけど、Rockのスカウトスレッドと同様の機能わPOWER6でload lookahead機能
として実装済みだと思うす。
http://www.research.ibm.com/journal/rd/516/le.html

MACオタの書き込みってどんどん姑息になってるな。
やっぱ基地外度ではMACオタがトップだと思う。
MACオタは読み手にわかりにくくやっているところが酷い。

同じin-orderアーキテクチャであるPOWER6にもload lookaheadと呼ばれるprefetch機能が
あったすけど、これとRockのスカウトスレッド機能と結果がどう違うかよくわからないす。

>In order to enhance performance, load lookahead (LLA) execution is employed to facilitate load prefetching
>to the L1 D-cache after a load miss or ERAT miss. When a miss occurs, the IDU will enter LLA mode, whereby
>instructions after the missed load continue to be dispatched from the I-buffer and executed. In LLA mode,
>the instructions can produce the result and pass it to the dependent instructions before the data reaches the
>writeback stage. (以下略)

>>346
　　----------------
　　同じin-orderアーキテクチャであるPOWER6にも
　　----------------
RockわOoOEなんすけど。。。
http://journal.mycom.co.jp/articles/2008/09/06/hotchips6/005.html
　　================
　　Rockのマイクロコアは、65nmプロセスを使用し、14平方mmと非常に小さいが、Out-of-Order実行
　　の4命令Issue構造を持つ。
　　================

Rockからスカウトスレッドを取ったらin-order実行すけど、
MACオタより少々理解しすぎていたみたいで申し訳ないす。

スカウトスレッドって、単に実装が多少ふうがわりなOoOでしかなくね？

>>345
いや、普通に大学の情報工でアーキテクチャの講義受けただけの俺でも大体わかるぞ？

なんか勘違いしてるな。
当の本人がload lookahead実行やらスカウトスレッドやらを理解してないのに
他人を見下しながら、貼り逃げはないだろ。

実はMACオタってのは海外の掲示板で出たネタはってるだけなのよ。
それならそれらしく>>346程度の書き方に押さえてときゃいいってこと。
2ch読んでるだけだとなかなかわからないと思うが。

>>351
　　----------------
　　海外の掲示板で出たネタはってるだけなのよ。
　　----------------
RealWorldTech, AcesHardware, Arstechnica, XtremeSytems等からネタを引っ張ってることわ否定しない
すけど、ソースわ書いているつもりす。
それ以前に、私が書いている話わ情報が新しいだけで技術的にわ『当たり前』のレベルす。ところが
この当たり前の内容に自称専門家の知ったかさんが噛み付いてくる不思議(笑)

まぁあれだ、独自の解釈がアレなだけで
引用元の信用性まで疑われてるわけじゃない。

事実だけを解釈の歪みなく引用してくれる分には有意義だ。








まあそうならないんだけどな

>>353
　　-------------------
　　独自の解釈がアレ
　　-------------------
Nehalemの命令帯域やらLarrabeeのベクトル幅やらの『独自解釈』で大恥をかいたヒトのことすか？

いいや、P5の浮動小数加減が1クロックとかROBがIntel用語なんて言った
大恥を通り越した超恥の人

で、どっちでもいいから
ふたりの投機的スレッド実行の実装についての考えをきかせてくれよ
アレは性能/トランジスタのコスパがいい技術なのか
ISAの実装によってはとんでもなくお荷物になる技術なのか

あと、OoOの亜種っぽいという見方も上のほうででてたけど
OoOと統合したほうが合理的なのか
それとも分離して考えたほうが合理的なのか等。

結局再コンパイルが必要なんじゃ大して意味はないんじゃないかな。
個々の実装に関しては、向かないものは向かないんじゃね？
レジスタなりローカルストレージなりがある程度大きくないとね。
キャッシュコヒーレントモデルの縛りがある。

Intelが「Ct」なんて新言語を作ってマルチコアに対応しようとしてるあたり、x86-ISAとしての空気はだいたい読めるよね。
また、シングルスレッド性能はSIMDの強化が主体かと。

>>354 >>355
おまえらで2ch羞恥心ユニットでも組めよw

ま、不確定情報に対する予想って当たれど外れど2chの醍醐味じゃね？
恥ずかしいなんていったらそれこそ有意義な議論は生まれんよ。

ま、確定情報を堂々と間違えるどっかの誰かは己の恥という概念がないらしいが

なるほど、恥をさらすのが楽しくて書くんですね。その気持ち私には分かりかねます…

そうは言ってない。恥を知らないやつが他人の恥をどうこう言うのがただただ滑稽だけ。
１００歩が５０歩を笑うようなもの。

他人の恥を指摘することができるのは
自分自身の恥を指摘される覚悟のある奴だけです。

その覚悟は俺にはあるしどっかのＦＵＣＫヲタには無い。

>ＦＵＣＫヲタ
おいおい、逆にかっこいいからやめてくれw

当たれど外れど2chの醍醐味とか書きながら言い訳がましすｗ

火傷して単発IDで自演とかするから台詞が似合わないよ

>>365
それＭＡＣヲタの説明ですか？
俺の流儀じゃねーな

>>366
ＭＡＣヲタはその点に関して言えばそこまで意地汚くないよ。
おまえさんだよ。と惚けなさんな。
まいい、お前さんの人格などはどーでも。
面白い技術ネタがあれば話しを戻せ。さもなくばねてちゃんと仕事行け。この弁慶が。

>>364
そうだよ。
でも、不確定事柄に対する「予想」だからね。2chの醍醐味ジャン。
不確定なものについて論じる以上は誰しもいくらかは間違える。
しかし間違うことを恐れたら何も論じることはできなくなるだろ。

間違いは、いくらでも指摘してもらってかまわない。
その代わりお互い様。自分のは指摘しないでくれなんて理屈は通らない。
フェアプレイ万歳。


ＭＡＣヲタの迷言の記録なんてログ探せばどれをピックアップすればいいか
逆に迷うほど溢れているわけで、俺に噛み付く行為そのものが自滅行為なんだよね。
こちとら●持ちだから他の板も含め全部探れますよ。
ケツの穴まで覗かれてる立場であることを自覚したうえでやってくれる分には何の問題もないが
そんな度胸無いのになんで噛み付くのかねぇ

予想ならともかく不確定でもないことを堂々と間違えられると爆笑するしかないわけで


ところであの彼はSandy Bridgeに「256ビットのSIMDユニット」が載ると思い込んでて
たまに俺を煽ってくるんだけどさ

何度も言うけど俺が確信するにSandy BridgeのSIMDユニットは128ビットのまんまです。←これ保存しとけよ

Sandy BridgeにはLoadユニットが2本（資料にもハッキリ「2nd load port」の存在が示されてる）で、
これで256-bit aligned loadと128-bit misaligned loadに対応してるらしいけど
もし仮に256ビット×2なら256ビットデータもmisalignedでロードできる筈なんだよ。
どう考えても内部128ビットです。本当にありがとうございました。

命令の仕様からして新命令も含め256ビットのは128ビットSIMD命令を2回実行してるだけだし。
浮動小数に関連する部分だけって時点で気づかなければいけない。
浮動小数はレイテンシが大きいからアンロール用としてでもレジスタを引き伸ばす意味がある。
そんな単純な理由だよ。
ネイティブ256ビットになるのはHaswellあたりかそれ以降になるんじゃないかな？

ＦＵＣＫヲタ、カコイイ！

いい加減聞かれてもいないのに同じ事を何度も書き込むのを止めればいいのにね

>>356
実はインオーダーとOoOは連続していて、
命令を実行ユニットに供給できるところは何箇所あるか？という違いが本質
つまり、インオーダーだと命令発行は一箇所から、Rockだと2箇所、OoOだと命令ウィンドウのエントリ数だけある

> アレは性能/トランジスタのコスパがいい技術なのか

したがって、魔法の技術じゃないし、コストも性能も中間だが、トレードオフの選択肢が増えるのは有意義

>>372
OoO性を導入しようとするとどうしても必要になるのが、逆依存の解消とインオーダー状態の維持だけど、
Rockの場合はそれにマルチスレッドととトランザクショナルメモリを使っている
うまい使いまわしだと思う、というか、トリックにとどまらない本質みたいなのがあるんだろうね

と思ったが、逆依存の解消そのものはdeferred queueでやるんだが、これは普通のSMTにはない機構だな

>>346
POWER6のlookaheadわ、スカウトスレッド相当品の実行結果わ全部捨ててしまうように見えるす

>>375
というのも真面目に実装するのも大変で、Rockみたいなdeferred queueもなく、所詮わオマケ機能だと思うす

いちおう2つのモードがあって、
1. キャッシュミス等を起したスレッドがそのまま実行継続、ただしレジスタ等のステートの更新しない
2. SMTの相手方のユニットで実行継続、相手方のステートわ更新する
で、1わプリフェッチアドレスが不正確に、2わSMTが使えないと問題も多いす

ARM、IntelによるAtom優位の主張に強く反論
http://pc.watch.impress.co.jp/docs/2008/0910/arm.htm

いよいよ全面戦争か

>>375-376
またキチガイのヒトが。。。と思ったら、正しいことを書いてるんでOKす(笑)

でも、>>372が変なんすけど。。。
　　----------------------
　　インオーダーだと命令発行は一箇所から、Rockだと2箇所、OoOだと命令ウィンドウの
　　エントリ数だけある
　　----------------------
ここの下の図 http://journal.mycom.co.jp/articles/2008/09/06/hotchips6/001.html
でも、>>318のリンク先のP.6を見ても良いすけど、あなたの大好きな"Reservation Station"やら
"RA"やらが各実行ユニットの前に鎮座しているのが見えないすか？このReservation Stationの
深さが、スカウト機構無しの状態での『命令ウィンドウのエントリ数』す。

>>369
　　-------------------
　　不確定でもないことを堂々と間違えられると爆笑するしかないわけで
　　-------------------
虚言癖ってヤツなんすかね。。。バレバレなんで実害ないすけど(笑)
前スレから抽出するだけでも団子さんの『間違った知識自慢』わ色々と。。。
http://pc11.2ch.net/test/read.cgi/jisaku/1214999146/
　　------------------------------
　　256 名前：,,・´∀｀・,,）っ 投稿日：2008/08/17(日) 20:37:06 ID:C0ppS6h9
　　　　＞フォワーディングネットワーク
　　　　これ予約機構のことかね？
　　　　Intel用語ではActive Register FileといってP6アーキのレジスタリネーミング機構
　　　　の特徴の一つです。
　　------------------------------
　　503 名前：,,・´∀｀・,,）っ-○●◎ 投稿日：2008/08/24(日) 19:50:02 ID:fXUc5UmU
　　　　でさ、scatter/gather命令の仕様なんだけどさ
　　[MACオタ注: 以下、妄想を開陳。実際にわ論文に実装についてのアリ]
　　------------------------------
　　517 名前：,,・´∀｀・,,）っ-○●◎ 投稿日：2008/08/24(日) 21:36:34 ID:fXUc5UmU
　　　　ページフォルトで命令キャンセルなんて聞いたことがない
　　------------------------------

引き続き前スレからのお笑い言行録を
http://pc11.2ch.net/test/read.cgi/jisaku/1214999146/
　　------------------------------
　　631 名前：,,・´∀｀・,,）っ 投稿日：2008/08/25(月) 02:38:52 ID:a77HGQP1
　　　　IAにストアバッファなんて最初からないし、あった試しがない。

　　| MACオタ注:当然嘘。以下、Pentium Processor Family Developer Manual Vol.3 P.18-7
　　| 　　　　　より引用 ftp://download.intel.com/design/pentium/manuals/24143004.pdf
　　| ============================
　　| 18.7. WRITE BUFFERS
　　| The Pentium processor utilizes write buffers for memory operands and for each
　　| pipeline.
　　| ===========================　　　　
　　------------------------------
　　840 名前：,,・´∀｀・,, 投稿日：2008/08/27(水) 13:26:01 ID:5PB5oEGN
　　　　＞ライトコンバインでは、まずフィルバッファに書くんだよ
　　　　はい、その仕様は何ページに書かれていますか？
　　| MACオタ注:しっかりディベロッパーズマニュアルに書いてあるす。以下、引用
　　| 　　　　　http://download.intel.com/design/processor/manuals/253668.pdf (p.10-9)
　　| ============================
　　| 10.3.1 Buffering of Write Combining Memory Locations
　　| Writes to the WC memory type are not cached in the typical sense of the word
　　| cached. They are retained in an internal write combining buffer (WC buffer) that is
　　| separate from the internal L1, L2, and L3 caches and the store buffer.
　　------------------------------
この品質の書き込みが延々と繰り返されているのが、なんともはや(笑)

処理性能とか消費電力はひとまずおいとくとしても
x86のブラウザにおける優位性ってすでに崩れ始めてるように感じるんだけど、その辺Intelはどう考えてんだろ

いいよいいよ。
お前が言うな100連発なんだけどね

MACオタじゃなくて別のコテにして＞もう一人の方
紛らわしくて遺憾。

>>384
了解

>>379
本気でそう思ってる？

>>379
以下はRockの話
> このReservation Stationの 深さが、スカウト機構無しの状態での『命令ウィンドウのエントリ数』す。

まず、スカウト機構「あり」でも「命令ウィンドウのエントリ数」ということは理解しているよね？

ITJungleのMorgan記者によると、コア数を2倍にしたPOWERサーバーが噂されているとのことす。
POWER6+すかね。。。
http://www.itjungle.com/tfh/tfh090808-story01.html
　　---------------------
　　Specifically, I hear that IBM is going to double up the processor core count on the Power 550
　　to eight Power6 cores and double up the Power 570 to 32 cores.
　　---------------------
クアドコア化するのか、実装密度を上げるのかわ不明す。

>>386
　　-----------------
　　まず、スカウト機構「あり」でも「命令ウィンドウのエントリ数」ということは理解しているよね？
　　-----------------
この妄言(>>348参照)を書いたのがあなたで無いのなら失礼したす。
　　=================
　　Rockからスカウトスレッドを取ったらin-order実行すけど、
　　=================

龍芯3のx86互換に関する情報が来てるす。
エミュレーション支援？用にMIS ISAに200命令追加してるんだとか。。。
http://news.cnet.com/8301-1001_3-10034825-92.html
　　-------------------
　　"The most interesting part of the chip is that they're adding about 200 new instructions to
　　assist with x86 compatibility," Halfhill [MACオタ注: Tom Halfhill, analyst of In-Stat] said.

　　At its core, it is a MIPS RISC processor--but one that proposes to run Intel-compatible
　　software efficiently enough that most Chinese may not notice the difference. "It won't be
　　an x86 processor. But the 200 instructions will optimize the (Intel) performance," Halfhill said.
　　-------------------

>>388
書いたのわおれじゃないけど、スカウト抜きのRockわ典型的なin-order実行すよ
もっとも今日日のインオーダープロセッサわ、POWER6のようにMostly in-orderだけど、
もしかしてMACオタわそこに拘ってグダグダ言ってるすか？

>>339で自分が貼った安藤さんの記事にも書いてあるじゃん

>>390
　　-------------------
　　POWER6のようにMostly in-orderだけど、
　　-------------------
POWER6わイシュー時に先行命令を追い越すことわ無いす。
http://www.research.ibm.com/journal/rd/516/le.html
　　----------------------
　　- A group cannot use more resources than are available in the POWER6 processor.
　　　Available resources are two FXUs, two LSUs, two FP or VMX units, and one branch unit.
　　----------------------

ひょっとして2ページ目読んでなかったのかな？

一応、整数演算パイプラインの話に限定しておいて欲しいす。
POWER6でもFPUやVUわ別途イシューキューがあって、OoOEすから。。。

>>393
？

>>392
POWER6でわなくてRockの話でわなかったすか？
相変らず間違いを指摘されると話をそらすのわ止めてほしいものす。

>>382
ブラウザっていうかネット端末として？
x86云々以前にPCの優位性にならないかそれ？
現実にはIEでないと見れないサイトが山ほどあるしな。
逆に携帯なんかのちっこい画面で見られる限られた情報に価値があるかね。
恋空(笑)とかやっぱナウなヤングにバカウケなのか？ｗｗｗ

もとい、情報市場という広いパラダイムで見れば、Wave(放送波)からWeb(双方向メディア)への
パラダイムシフトというのがまずあって、PC市場は例に漏れず拡大を続けてる。

むしろWeb端末としてのPCの需要なんてここ数年の話だぜ。
森さんが「イット革命」なんて言ってた時代のちょっと前には
LANにすら繋がれてないPCがオフィスにゴロゴロしてた時代があり・・・。

そもそもIntelがどう思ってるかもなにも、x86が駄目な命令セットアーキなのはIntel自身わかってて
莫大な金をかけて何度もx86アーキを捨てようとしたけど、ことごとく失敗し続けてんだよね。

XScaleを捨ててAtomを立ち上げたのも、x86の需要拡大を見込んだ戦略の一環ではないかな。
既に「ネットトップ」「ネットブック」といった新市場が形成されつつある。

もちろん無線LANの普及がCentrinoのキャンペーンの功績であることも忘れてはならない。
Intelの優位性はそういった新市場創出の功績そのものだよ。

携帯なんかに載ってるARMとPCのx86の台数比較なんてしたところで、たいした意味はない

>>396
話をそらすつもりわ無いすけど、「先行命令を追い越さないOoOE」とか、「先行命令を追い越すイン
オーダー」とかが理解できないだけす。

http://journal.mycom.co.jp/articles/2008/09/06/hotchips7/001.html
> GodsonプロセサはMIPSアーキテクチャのプロセサであるが、x86命令を
> エミュレーションするサポート機能を備えていることが一つの特徴である。
> Godson-3の汎用コアでは、x86互換のために200以上の命令を実装して、
> 現在のGodson-2に比べてx86互換機能を強化する。これらの命令の実装
> に必要な追加のシリコン面積は5%であるという。これによりx86命令の実効
> 性能をMIPSネーティブ命令の80%程度に引き上げるのが目標であるが、
> 現状では、40%〜50%しか性能が出ていないという正直な発表であった。

>>399
お恥ずかしい。何を勘違いしたか、確かに読んでいなかったす。

>>398
これを誰が言ったのか、引用して明確にした書き込みをして欲しいす
MACオタの一人相撲に付き合う気わないす

> 「先行命令を追い越さないOoOE」
> 「先行命令を追い越すイン オーダー」

ついに一般向けSpursEngineカード登場す。
http://pc.watch.impress.co.jp/docs/2008/0910/leadtek.htm
　　----------------------
　　リードテックのWinFast PxVC1100は、デスクトップPCに増設できるPCI Express x1接続の
　　LowProfile対応カードの形状。10月以降に、一般向けのリテール販売を予定している。価格は未定。
　　----------------------

>>401
判りにくかったなら失礼したす。
>>390
　　----------------------
　　スカウト抜きのRockわ典型的なin-order実行すよ
　　----------------------
Reservation Stationが存在して、この中から先行命令を追い越して実行ユニットにイシューすることが
できるRockが何故『in-order実行』なんすか？
スカウトわ"OoOリタイア"を可能にする技術なので、命令実行についてわ有無にかかわらずアウトオブ
オーダーだと思われるす。

なんつーか、すげえマルチスレッドｗ

>>403
> Reservation Stationが存在して、この中から先行命令を追い越して実行ユニットにイシューすることが
> できるRockが何故『in-order実行』なんすか？

それこそMostly in-orderというやつすよ
MACオタわやっぱり用語に振り回されているようすね

> スカウトわ"OoOリタイア"を可能にする技術なので

ほんとに用語スキーなんすね
でも、間違いではないにしろ、違うす

>>390
> もっとも今日日のインオーダープロセッサわ、POWER6のようにMostly in-orderだけど、
> もしかしてMACオタわそこに拘ってグダグダ言ってるすか？

>>397
＞現実にはIEでないと見れないサイトが山ほどあるしな。
ああうん、Intelがなりふり構わずIEでなきゃ見れないサイトが多いんだよって主張するなら納得なんだけどね
ただ今更x86だから〜って言うのは遅すぎない？っと思った

いじめるなよ。
自分が恥ずかしい人間だと思いたくないナイーブな子何だから。

>>405
まともな回答をくれるつもりも無さそうすね。
OoO実行、インオーダーリタイアならCore2を含むほぼ全てのOoOEプロセッサに当てはまるす。

いまAppleイベントの中継を見てるので、今日はもうお終いにするす。知ったかぶりたいなら、
次回わ、もう少し内容のあるコメントを是非に。

>>406
あ、そこは別にFireFoxでもなんでも構わない。

ただ、今のx86の需要は市場が選んだもので、つまり結果論なんだ。
Intelの思惑どおりに市場が動いてたら今頃俺のマシンもItanium2にでもなってたよ。

Intelとしちゃ、ARMみたいな単価100円単位の組み込みCPU市場の覇権なんて
欲しくも何ともないだろ。

>>408
だからMACオタわ用語に振り回されているから、OoOと(Mostly)in-orderの違いがわかんなくなってんのよ

OoOは「積極的に逆依存を解消して」、out-of-orderで実行する

そうでないのが(Mostly)in-order、あまりコストをかけずに若干のOoO性は持たせてあることはごく普通です

Core2みたいな大抵のOoOプロセッサは、レジスタリネーミングで逆依存の解消をしているし、
Rockはスカウトスレッドとdeferred queueで逆依存の解消をしている

スカウトなしのRockにOoOを実現する機構はないよ

ところで、MACオタは
> Reservation Stationが存在して、この中から先行命令を追い越して実行ユニットにイシューすることが
> できるRock
これをどこで読んだのかな？

ソースは出せないんだろ？
用語に拘った挙句の思い込みだろ？

>>410
実際のところ、Rockはキャッシュミスすると命令フェッチもスカウトに切り替わるわけだし、

Core2みたいに「キャッシュミスしたロードに直接間接に依存した命令」をRSに長く待たせることはないので、

実装もCore2のように連想メモリではなく、ただのキューで十分だろう

>>410
訂正するす

×OoOと(Mostly)in-orderの違いがわかんなくなってんのよ

最初からわかってるはずがないすね(笑)

おまけ:
Rockは実行できない命令をdeferred queueにつっこむわけだけど、オペランドのうち使えるものがあれば値を読んで、
命令といっしょにdeferred queueに書く
これでこの命令のソースオペランドが後続の命令で上書きされても(WAR)大丈夫==逆依存の解消

つまり、レジスタリネームじゃなくて、値そのものをコピーするわけ

LarrabeeってまんまCellGPUがやりたかったこと実現しちゃってるな。
バス幅に余裕のあるリングバス、
インテリジェンスなキャッシュコントローラーが管理するコア間で横断可能なキャッシュ、
アホみたいな量のALU
Nativeコンパイラも期待できるし、これで2GHz/20コアとか動いちゃったらちょっと凄いわ

>>403
とりあえずMACオタには、これのソースを出してもらいましょう

> Reservation Stationが存在して、この中から先行命令を追い越して実行ユニットにイシューすることが
> できるRockが何故『in-order実行』なんすか？
> スカウトわ"OoOリタイア"を可能にする技術なので、命令実行についてわ有無にかかわらずアウトオブ
> オーダーだと思われるす。

RSとROBの区別もついてないお前が、Reservation Stationだから当然す、なんて言うなよ

あと、期待に違わずMACオタは「OoOリタイア」についても理解してないようで安心したww

Opera、「NVIDIA Tegra」に最適化されたブラウザ提供へ
ttp://internet.watch.impress.co.jp/cda/news/2008/09/10/20810.html
Opera Softwareは9日、「NVIDIA Tegra」ファミリーに最適化されたフルブラウザを提供することで、
NVIDIAと提携したと発表した。ハードウェアの力を生かし、JavaScriptや高速ベクター、動画をサポートし、
デスクトップと同じレベルのブラウザをスマートフォンや携帯機器に提供できることになる。


今後MID用プロセッサとしてのAtomのセールスポイントがどうなっていくのか気になる
こんな話も

Nvidia Tegra is based on GeForce 6
ttp://www.tgdaily.com/content/view/39215/135/

Industry sources told us that the next-generation Tegra will add certain features from the GeForce GTX 280
such as full support for CUDA and dual-precision FP64 processing.
The hardware is likely to be based on a single 8-shader processor node, which would result in about 30 GFlops of processing power.

携帯/MIDに倍精度って必要あるんかしら

ろっくはOoO実行、in orderリタイヤだろ
sunがなんと言おうが、スカウトスレッド実行開始時点と
整合性を取ってコミットしなきゃ、実行結果の完全な反映はできないよ

>>416って検討外れかも
そんなわけでロールバック
AV女優はTバック
必殺技はア○ルフ○ック

スカウトスレッドしないときのRockはin orderだろ
現時点での情報だとそんな感じ
スカウトって、高速化に寄与する割合のでかいロードのOoOが
低コストで実現されてるっぽくて素敵
C2Dとかの実装わかんないから低コストってのは直感だけど

キャッシュはグラフィックスに馴染まない
っつーのは、ライン置換にLRUみたいな
単純なアルゴリズムのみを使うんじゃなくて
ラインとかブロック毎に置換優先順位を設定してやれば
あっさり解決できる弱点なのね、たぶん
この単純なことが分かるまで、人類はLararbeeを
待たなくてはいけなかった、
これがマイクロプロセッサの、ある機構の実現可能時期と
実装される時期との乖離というわけです

いやー、世の中って難しいですね
っーわけで、デリヘル呼びます
いじょ

質問していい?

その置換優先順位ってだれがつけるの?

んとね、コード書く人
コンパイラやハードが自動的にやるとかないゆ

キャッシュ置換ポリシーをコンパイラにやらせる研究もあるけどね
インテルは実装してくるかもしれないけど、今の商用コンパイラにはないんじゃないか

ハードにやらせる研究もないではないようだ
こちらはメモリアクセスパターンを認識して、という話だから、
自動プリフェッチと似たような話

おれもデリ呼べる家に住みたいのう

ストリーミングデータによるキャッシュポリューションについては、
置換ポリシでなんとかなるが、SRAMや主記憶バンド幅とかの利用効率の
悪さはもうちょっと根が深いと思うぞよ

書いた本人ですが何か?

MACオタ(本人)が用語スキーというのに激しく同意。
定番OOO実装の説明が全くないから皆(安藤氏もそうだった)悩んでいるのですよ。
Sunは今までがin-orderだったからOOOを新しいものとして売りにしてきた。
IBMは今までがOOOだったからin-order回帰を新しいものとして売りにしてきた。
この両者のアピールポイントはくだらない用語の定義論におちいりかねないし、たいした意味はない。

どちらもスケジューラを簡素なままに、新しい工夫でコアのスループットをあげようとしている
って言うのが重要なの。

Atomも多少in-orderなりの工夫があり。
これらがin-order回帰なのと、Larrabeeがin-orderのP5コアを使い回したのではかなり事情が違うね。

POWER6のload lookaheadがオマケ程度なのが気になる
Ahead状態は整数レジスタだけでいいし（もしかしてRockもか？）
ポート不要なそのバックアップすらケチったということか

>>372
>実はインオーダーとOoOは連続していて、
>命令を実行ユニットに供給できるところは何箇所あるか？という違いが本質
ピンサロが団子やMACオタよりOOOを理解しているのは間違いないが、これはさすがにない。
OOO実行は逆依存の解消の方が本質。
もちろんMACオタ(本人)がいっている先行命令を追い越して発行とかもちがうけど。

すまんがOoOの話題にはノータッチ。
俺はそのへんの機構はたとえばx86ならどの命令が並列化できるとかしか興味なし。
中の人に程遠いルーマーが他人に説明するなど愚かしいことよ。

>>427
OoOの本質が逆依存の解消は了解

Rockはメインとスカウトの二つのin-orderスレッド間のOoOness

Core2のはガバガバフェッチした命令間のOoOnessを連想メモリで抽出

まだ騙りさんが出没しているすか。つまらないプライドを捨てきれないのか、バレバレなんで
実害わ無さそうす。

それわそれとして。。。

OoOEを名乗る商用プロセッサの多くがイシュー・キューの深さがほんの数命令程度で、直前の
先行命令を追い越せる程度す。リネームレジスタが無いとOoOEの条件を満たさない。。。なんて
のわ、実物のチップのデータシートを読んだことが無い机上の空論というヤツかと。

>つまらないプライドを捨てきれないのか
えっ?
にちゃんねる屈指のつまらないプライドの持ち主とは誰のことだっ!!

>イシュー・キューの深さがほんの数命令程度で、直前の
>先行命令を追い越せる程度す
妄想どうも。

>リネームレジスタが無いとOoOEの条件を満たさない
そんなん誰かいったか?

いつにも増して書き込みのクオリティが低いですよ、ご本人さん。。。

MACオタが用語以上のことを言い出すと一挙に無理解をさらすわけで

話がそれてきたが、
MACオタはレスの付け方が下品すぎるというのがもともと言いたかったのよ。
書き込みしている人の意図や書き込みの内容の大筋をつかまないで、
つまらない揚げ足取りや、相手をいかにして追い込むか
に終始してるんだよな。
初心に帰って、発展的なレスができるようににちゃんねる人生をやりなおして欲しいものだ。

ああ、変な書き込みしてるが、これが最後。
ROMっている人も含めて、これからはみんなどんどんMACオタと議論して欲しいw
極端なMACオタが嫌いがいる理由が身をもってわかるだろう。
スレ的にもその方が盛り上がるだろうし。

オタと議論しようとする時点で
もまいは２ちゃん素人

たしかにレジスタリネームそのものはOoOとは可分の機能だ。
Itaniumのレジスタローテーションもそうだし

ところでおまいらルネサスや芝セミの中の人か何かか？

十分なレジスタ数がありソースとデスティネーションが独立してれば
レジスタリネーミングなしのOoOでも十分な性能は出る。
逆に消費トランジスタ数が許すならレジスタリネーミングはインオーダでも有用な技術だ。
x86/x87のISAは逆にレジスタリネーミングなしじゃOoOで性能でない。

CellのSPは命令レベルで使えるレジスタが多い反面、レイテンシを埋めるため
明示的なループアンロールが必要だ。
これは結果としてコードサイズの増大を招く。
場合にもよるが、コードサイズが小さくできることはSRAMを有効利用できることになり
結果的に電力当たり性能向上につながりうる。

>>438
定量的な例示があると分かりやすいんですが

intelはlarrabeeについては自社のCtよりも
DX11期待してるってさ

Compute ShaderてLarrabeeのためにあるような機能だしな

それってx86関係なくなるじゃん

Compute shaderってただのDX11の拡張じゃん。

Larrabeeはどうやらx86のバイナリをそのまま食わせることは出来ないらしいけどc/c++のコードが普通に走るし、
SPEと違ってDMAとかじゃないんだぜ。
周りのコアのL2にデータあればそれ読めちゃう。
レイテンシは伸びるだろうけど、コア数が増えるとシームレスにアクセス出来る共有L2が増えてくとかすごい。

そもそも普及する見込みが無いから
CtよりDX11って考えなんだろ

>>431
　　------------------
　　妄想どうも。
　　------------------
確認してみることをお勧めするす。
　・ARM Cortex-A9: 6命令 (ただしレジスタリネーム有)
　・PowerPC 440: 2命令
　・PowerPC 744x:/745x 3命令 (ただしレジスタリネーム有)
ついでに命令ウィンドウわ大きい目なのにリネームレジスタが無い例わ、POWER6のFPU/VUキューが
あるす。
　・POWER6 (FPQ): 8命令

　　-------------------
　　>リネームレジスタが無いとOoOEの条件を満たさない
　　そんなん誰かいったか?
　　-------------------
>>427
　　===================
　　OOO実行は逆依存の解消の方が本質。
　　===================

NECがIBMの(バルクシリコンの)プロセス連合に加入したす。
http://pc.watch.impress.co.jp/docs/2008/0911/necel.htm
　　----------------------
　　今回の合意に基づき、ＮＥＣエレクトロニクスは３２ナノメートル（ナノは１０億分の１、以下ｎｍ）
　　世代の次世代ＣＭＯＳプロセス技術の共同開発プロジェクトおよび将来の最先端半導体技術
　　に関する先進的な基礎研究に参加します。ＮＥＣエレクトロニクスは、次世代シリコン技術の大
　　幅な性能向上及び消費電力低減を加速させるための共同開発を行っているＩＢＭの共同開発
　　アライアンスの８社目の半導体製造会社となります。
　　[中略]
　　なお、ＩＢＭの他の半導体共同開発パートナーは、チャータード・セミコンダクター、フリースケー
　　ル・セミコンダクタ、インフィニオンテクノロジーズ、サムスン電子、STマイクロエレクトロニクス
　　および東芝です。
　　----------------------

>>443
そりゃマイクロOS上で走る専用の実行形式じゃないとだめだろ（ソケット版はともかく）

もといCOFF形式ならモジュールレベルではそのまま使えそうだが。

おりしもEETimesによると、富士通の半導体子会社もどこかのプロセス連合への加入を検討
しているとか。。。
http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=210600995
　　-------------------------
　　In an interview with the news agency, Haruki Okada, the president of Fujitsu Microelectronics,
　　said: "From co-development to business integration, there are some potential ways for us to
　　go. We are keeping the door open on all options, and our talks have not got into specifics yet."
　　-------------------------

それ、元ネタはロイターだろ？
http://ascii.jp/elem/000/000/170/170791/

過去ログを一切合財なくして傷心のピンサロオタです。
でもMACオタの無学と用語スキーぶりは期待にたがわないね。

>>410　>>427
で、翻訳氏とピンサロは「OoOの本質は逆依存の解消」と主張している。
逆依存を解消するメカニズムには、レジスタリネームと、スカウトスレッド+deferred queue方式がある。
前者はWARハザードを起こすペアの依存「先」の命令の出力レジスタをリネームする。
後者はWARハザードを起こすペアの依存「元」の命令のオペランドを読み出し、命令と一緒にdeferred queueにつっこむ。

つまり、
「OoO実行は逆依存の解消が本質で、実装としてはレジスタリネーム以外にも、スカウト+queueもある」

ところがMACオタは

>>445
> 　　-------------------
> 　　>リネームレジスタが無いとOoOEの条件を満たさない
> 　　そんなん誰かいったか?
> 　　-------------------
> >>427
> 　　===================
> 　　OOO実行は逆依存の解消の方が本質。
> 　　===================

これが反論になっていると思っている（笑）
用語にこだわるあまりに、もとから怪しい論理まで破綻してしまったようだ。

AMDはx86版のARMにでもなりたいのか、ファブを分離するっていってるし、
結果的にPC市場の勝利者はintelになっちゃう。

これって今後の双方のアーキテクチャにモロ影響を与えると思うんだけど
だれか予想できる?

>>427
大変わかりにくい記述だったが、つまりこういうこと

Rockでは、メインスレッドがキャッシュミスした命令（に依存した命令）Aで止まってスカウトスレッドが起動する
スカウトスレッドはAに依存した命令Bは実行できないので、「Bのオペランドを読み出してコピーし、Bと一緒に」deferred queueに放り込む
スカウトスレッドはBの逆依存のsinkになっていた命令Cは、Bより先に実行できる
なぜなら、Cが書き込むレジスタが持つ古い値は、Bと一緒にdeferred queueに入っているので、Bの実行にはそちらの値を参照すればよい
→つまり、逆依存を解消して実行するOoOそのもの

ただし逆依存が解消されるのは、deferred queue内の命令と、スカウトスレッドが実行する命令の間だけであって、
queue内やスカウトスレッド内どうしの命令間では、逆依存の解消はしていないことに注意

これが、「Rockが逆依存を解消し並列に命令を供給できるのが二箇所」の意味

通常のOoOマシンでは、命令ウィンドウ内には逆依存が解消された状態で格納されているので、ここから任意の命令を取ってこれる


たしかに>>372の記述じゃわからんな

>>451
もっと消極的な理由だよ。K8好調期にFab作りまくったけどCore2以降自社CPUの出荷が落ち込み
製造ライン止まってるか、あるいは赤値で売り叩かざるを得ない状況だから。

言ってみればバブル期の過剰投資のつけが回ってきた感じかな？

手放す理由は単にTSMCとかに委託した方が自社以上の最先端プロセスが使えて、
かつ生産量の調整がしやすくリスクが少ないだけ。

仮にも組み込みでトップクラスのシェアを誇るARMと一緒にすべきではない。

創業者追放ですか。

単独でプロセスの微細化に投資するよりも、他所と一緒にやった方がマシって事？

ましというか何というか、リーク電流問題が顕在化する前と今とでは微細化にかかるコストの事情が全く違うのは一つの事実かと。

AMDの場合IBMと連合組んでもああいうことになったのは、
Intelが衰退してAMD64がx86市場を掌握するという希望的観測のもとに本来の立ち位置に見合わない投資を重ねたから。
まあ根本的にはIntelと張り合い続けるには体力が違いすぎたし早かれ遅かれこうなっただろうけどね。

Intel戦略以外もいろいろ打算的だったのも事実。
もともとはGPUの製造もAMD自社Fabでまかなうつもりだったのが、
GPUのプロセスルールのほうがCPUを追い越して支援どころか足枷になっちゃった

IBMが「AMDはプロセスルールの進化についていけなくなる」と予想した、という記事が数年前にあったっけ

32nmプロセスより先を担うのは、どのみち厳しかったと思う

25億�jで建てた自社fabがある以上、
そこで作る石は競争力を持たなくてはならない。
より小さなダイで他社より性能優位なチップを用意した上で、
フル回転で造って造って売って売って設備を償却する。
その造るチップとはSOIとがっぷり四つであるK8やK10。
ATIのバルクCMOSチップではなかったのだ。

MeyeがATI買収＝54億�jのギャンプルに後悔の念を抱くのは無理もない。
その金の5分の1でもK10開発に上乗せしていれば・・・・
・・・・いや、上乗せしたところでどうにもならんか。
だんごの言う通り自社fab自体、体力に見合わない投資だった。

>>458
　　-------------------
　　自社fab自体、体力に見合わない投資だった。
　　-------------------
昨今の経営の誤りわ別にして"Only real men have fabs."ってのわ創業者Jerry Sanders以来の
社是す。
http://pc.watch.impress.co.jp/docs/2006/0427/kaigai265.htm

男はでっかいfabをもてってね

がっぷり四つの使い方に違和感を覚える

難しい判断だ…

自社でfabを持たないリスクと、持つリスクと、両方ある訳だから。
PC向けCPUなら、ある程度の自社fab持ってないとどうにもならんだろ…。

文字通りのIP屋やるんじゃね？
PC？どうだかね。

Intelの強制分割を狙った自爆テロの線も見えてきた。

最近の評価ではfabﾚｽ側の惨敗だったと記憶しているが

それは周回遅れの（＝枯れた）プロセスルールが現役の組込CPUだからこそ言えることでは？

AMDは同じ命令セットアーキテクチャの市場でIntelと対抗し続ける唯一のメーカー。
2年周期で新プロセスルールに移行していくのは体力的にどうよって話。

金を作んなくちゃならなくなって売るもんないから身を切り売りしました
が正解かな。

ところで*fence命令の効果はAtomでは単にNOPだぞオイ
レイテンシ1とかｗｗｗ
インオーダのアーキテクチャでは順序保証専用命令などそもそも不要らしいな。
つか、スループット見るにWCプロトコルを使う命令もL1をスルーしてないんじゃないかという疑惑。
Larrabee的にも「最低プライオリティでストア」でいけるな。

>>466
　　------------------
　　ところで*fence命令の効果はAtomでは単にNOPだぞオイ
　　レイテンシ1とかｗｗｗ
　　------------------
自分が読んだモノを皆が読んでいると思い込んで書き込むから、唐突でキチガイじみて見えるす。
別に珍しいソースでも無いすから、ソースくらい示すべきかと。
http://www.freeweb.hu/instlatx64/InstLat_GenuineIntel00106c2_Atom_Silverthorne_1600MHz.txt

ところで単純にNOPだと、この計測法でわ0.5サイクルということになるのでわ？

mfence＝NOP×2だよ

ところでそれだけで解るのか？
メモリロード・ストアの間にフェンスを挟んだ結果ではないぞ。
机上論で説明できるのならやってみてくれ。
ちなみに俺には計測環境があるんだな。

つまるところそんな資料は役に立たない。
だからお前は脳内なんだよ。

>>469
　　-----------------
　　ちなみに俺には計測環境があるんだな。
　　-----------------
実測なら実測と書くことが重要す。『測定条件も併せて書き込めば』、非常に有用なデータす。

「測定結果」、「リファレンスのある情報」、「考察(またわ妄想)」を区別して書かないから、
まともな科学教育を受けてないという疑惑を持たれるのだと思うす。

同じ命令を連続投入してる以上はメモリアクセスは伴わないので
フェンス命令の本来の作用にたいする計測としては意味をなさない。
文字通りNOPを1,2個投入してるのと同じことになるな。

答えの合否はともかく導出過程が間違い。

>>471
自己紹介乙


同じ命令を投入するだけのベンチで何が計測できるかそもそもお前は理解してないんだよ。低脳

>>472
FENCE命令の話とわ別すけど、instlatx64の資料わ、命令のペアリングを含めて、
広範囲に調べている方だと思うす。

ところで「インオーダーなので無条件にNOP扱い」ということなら、命令の組み合わせわ関係無い
のでわ？

ちなみに、メモリアクセスの間にフェンス命令を挟むのと挟まないのとで、それぞれ掛かったクロックの差分をとるだけだよ。
エベレストはそういう計測はやってない。

メモリフェンス命令はメモリアクセスでないものに対する保証は原則的に不要なのだから
メモリフェンスを並べてもメモリアクセス保証にかかるクロックの計測としては何の意味もないんだよ。

>>474
残念だがやってない。ベンチプログラムの逆アセンブルでもやってみたか？

やってないだろ？何も知らないからこそそんな迷言が吐ける。

「NOP扱い」云々は俺の計測に基づく推論だろ？

そのベンチが何をやってるかも理解せずに他人の出した数字だけで結論づけるのは危険だな。
それこそ科学教育を受けた人間のやることではない。だからお前は脳内なんだよ。

>>475
間違ったことを書いている訳じゃないので、単なるコメントす。
　　---------------------
　　メモリアクセス保証にかかるクロックの計測
　　---------------------
これわシステム依存の話で、ある命令の「効果」を測定していることになるす。
単純にプロセッサコアのみに依存する、命令の「オーバーヘッド」を測定する資料があっても良いか
と思うす。

>>476
　　----------------
　　「NOP扱い」云々は俺の計測に基づく推論だろ？
　　----------------
その推論について質問しているだけなんすけど。。。

私わあなたのお母さんじゃ無いすから、あなたに全幅の信頼をおいている訳じゃ無いす。
匿名掲示板に限らず、そういった一般の聴衆を納得させるにわ推論に至るまでに確かめた事項
と、論理的な筋道を示す必要があるす。

余談すけど、intelのサイトにこんなページとサンプルコードがあるす。
http://softwarecommunity.intel.com/articles/eng/2322.htm

詭弁だな
まあエベレストがやってるのが「オーバーヘッドの計測」でしかないのは正しいが。
で、Atomにおけるメモリフェンスに伴うクロック遅延はオーバーヘッドだけ、
というのは実際にメモリアクセス間に挟んでみないと判断できない。

>>479
ずいぶん懐かしいな。ちなみに俺はそれ数年前に知ってたぞ。
でもその計測法じゃやっぱりメモリフェンス命令はオーバーヘッドしか計測できないね。

必死なのは理解したよ。やっぱり根本的にわかってない。

たとえば、これで計測してみてくれよ。

movntdq [edx],xmm0
mfence
movntdq [edx],xmm0
mfence
movntdq [edx],xmm0
mfence
movntdq [edx],xmm0
mfence
movntdq [edx+16],xmm0
・
・
・

movntdq単体とのスループットクロックの差分をとればそれが実際に順序保証にかかる遅延サイクル数だ。

お前みたいに他人の記事を何をやってるかも理解せずに鵜呑みにするのは科学ではない。

edxをI/O領域に設定して、デバイスが永遠にアクノリッジ返さないようにして計測kしてみてよwwwwww

どのみち直接のストア先はキャッシュだから同じじゃね？
ACKなんてそもそも見てないよ。

命令の順序保証は書き込みそのものの保証ではないんだな。

ところでSMBでネットワーク共有ドライブLANが停滞してたりすると
「遅延書き込みデータの消失」なんてダイアログをたまに目にするよね。
アレ、キャッシュしてから遅延書き込みしてるからだぜ。
NFSだってUDPベースなんだぜ？
結局I/Oに対する保証レベルはそんなもんだ。

>>485
古臭い知識の訂正だけ。
　　-------------------
　　NFSだってUDPベースなんだぜ？
　　-------------------
http://www.microsoft.com/japan/technet/windowsserver/2008/library/15ae8ffe-0f15-4d78-abac-bb0c13540979.mspx?mfr=true

確かにNFSv2以降はTCPも「選べる」よ。
しかし相変わらず本質が見えてないね。

フェンスを知らずに空ループで待つ奴はトラ技で見たことがあるが
I/O領域をキャッシャブルにする奴は初めて見た

どのレベルでのIOなのかは知らないがカーネルモードでSSEは非常識だし
ユーザーモードで文字通りのI/O領域アクセスとかバカですか？

何でもいいから計測結果貼ってみてよ。ACKが来るまで待機とか聞いたことがない。

それはそれとして、in-order/out-of-orderとオーダリングルールの
強い/弱いには直接の関連は無いぞよ。せっかく、DEC WRLのチュートリアル
紹介したんだから勉強してして。

ちなみに、x86のI/Oアクセスとfenceは関係ない可能性が高いと思う、
なぜかといふと、x86のI/Oメモリモデルがfenceの追加以前に確立したもの
をずっと踏襲している可能性が高いと思うから。

これは単なる予想、x86には詳しくないから確信は無し。

>>491
と思ったが、チュートリアルの紹介を出先から書き込もうとしてリジェクト
されてたような気もするので、改めて紹介

http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-7.pdf

>>491
非SSEのメモリI/OアクセスはPCだからフェンスは関係ないが
SSEでメモリI/OアクセスするならWCなのでフェンス必要
特殊な条件を設けてなければね

WC（というかキャッシュスルー）なのはNTかMASKの付く一部のストア命令だけだぜ。
しかも「WCプロトコル」の存在すら実装依存だぜ。

インオーダで非ライトコンバインで実行ならただのNOP扱いで構わない。

>>494
Weak Consistencyのほう
Write Combineじゃない

PC=Processor Consistency
P6あたりで定義されたんじゃなかったかな

storeスルーは苦し紛れだけれど
数年前の技術としては妥協点だった
分かってやれよ
ｵﾚは納得していないけれども

国産スパコンが米国で殿堂入り＝気象予報や商用に活
http://headlines.yahoo.co.jp/hl?a=20080913-00000099-jij-biz

http://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AC%E3%82%A4%E3%82%B9%E3%83%86%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3

Wikiのプレステ紹介より抜粋
>プレイステーションにCPUとして採用された当時のMIPSアーキテクチャは、
>組み込みやゲームコンソールにはメモリ効率が悪く、CPU自体の処理能力
>も同クロックの「80386」程度の速度であった。

MIPS2000でも486並みの性能があるんだけど、、、

>>497
NWTか、懐かしいなぁ。

>>493
プロセッサアーキテクチャのメモリモデルはアクセス先とは独立、という
ことであれば、一つの見識であるのう。

Larrabeeのキャッシュコヒーレンシとメモリモデルについて意見ある？

>>498
あいたたた

今はMIPSって無いの？

>>499
プロセッサの外部がある限り
メモリアクセスの一貫性は必要
どう保証するかはまた別の話

>>500
つ　RMI
つ　Cavium
つ　SiCoretex
つ　PSP

>>501
一貫性は必要、でも、すべてのアクセス先に関して同一モデルである必要は
ないぞ。

あ、これは>>493に対する反論ってわけじゃないぞ。

まあ、SSEアクセスでI/Oデバイス側のデータバッファにwrite gathering
バッファ介して書き込んで、そのあとメモリマップI/Oへの書き込みで通知
みたいな状況を考えるとfenceを想定したほうが自然だし。

「通知」なんて見てねーよ。

コアを出たらあとはFSBなりメモリコントローラーが順序保証するわけだからね。
プロトコルが違うのも所詮はプラットフォーム内で閉じた話。

メモリフェンス命令による遅延クロック計測したことある？
いちいちACK信号なんて待ってたら数クロックですむ筈がないよ

ACKを待つとすればストアレイテンシ＋ロードレイテンシ分は最低でもかかるわけだが

E8500な俺のマシンで実験

ストア後にsfence命令を挟んだ際の遅延クロック数
通常mov 20clk
movnt* 約130clk

20clkの方はパイプライン段数分＋ストアバッファリング分で大体計算はあう。
一方で、movntは実メモリに読み書きのACKまで待機にしてはサイクル数が短すぎる。
ロードレイテンシ計測ツールによると実メモリのロードレイテンシは約280clk(90ns)

どうみても計算あわないよ。

嘘つきは泥棒の始まり。

うわー、噛み合ってねー

もしかして、>>503の「通知」をメモリシステムからのAcknowledgeのこと
だと解釈したのか？これは、I/Oデバイスへのデータ書き込みとI/Oデバイス
へのコントロール書き込み(こっちが「通知」)の間にsfenceが必要かも、
という話だぞ。前にも書いてるが、俺は正解を知らない。

ところで、sfenceの実装のための「ACK」待ちにストアレイテンシ＋ロード
レイテンシが必要という根拠はなんだ？それとも、計測した命令シーケンス
依存でロードレイテンシが顕在化するという話をしているのか？

それから、「ストアレイテンシ」を明確に定義できるか？

ついでに、lfenceは「ロードレイテンシ」分待つ必要があるか？

ま、結局おまいらみんなMACヲタレベルなんだよ。
簡単な実験すれば解る間違いを平気で言ってのける。
自分の机上論だけに執着して現実を見ようとしない。

だから通知なんてそもそも待ってないんだって。
fenceは順序保証であって完了保証ではない。

>>509
じゃ、別の質問、>>506で観測された待ち時間増大は何だと思う？

それはそれとして、「fenceは順序保証であって完了保証ではない」は
正解だな。

メインメモリなりI/Oなりはメモリコントローラ・I/Oコントローラの仕事。
Core 2であればFSBまでのアクセス順の順序保証で十分なんだよ。

そして、最初からアクセス順が保証されてるなら何もする必要はない。

通常ストアのアクセス先はL1だがMOVNT*はFSBだから、かな。>>110

Atomマシンは仕事先での借り物であまりいじれないので、はっきりとした分析はできん。
そのうち俺専用機買うけど。

>>510
> それはそれとして、「fenceは順序保証であって完了保証ではない」は

無論その通りなのだが、プロセッサ内で順序保証したところで、最初のメモリアクセスが完了しないことには
無限にメモリアクセスリクエストを貯めこんでしまうはめになる

もちろん団子はきちんと理解してそんな細かい話をしているわけではない

>>512
FSBかどうかはともかくとして、どこかのリクエストキューに入るか何か
して順序保障が可能な状態になるのを待った、と考えるのが妥当だと思う。

ならば、これを実装するのに(プロセッサコアのwrite bufferより外の)
メモリシステム側から何らかのAcknowledgeを受け取るのを待つというのは
自然なやりかたなんじゃないかね。

実際のところどうなっているのかは知らんが。

>>513
うーん微妙な書き込みだなぁ。とりあえず>>492で紹介したやつ、じっくり
読んでよ。メモリコンシステンシ周りの事情が13年前とちっとも変ってない
ってのが分かる。

リサーチ的な進展はあったんだが、プロセッサのハード実装には結びついて
ないんだよね。

>>514
メモリシステムからのackを待ってないのは>>506より明らかなんだが。
ロードで300クロック近くかかってるのにストア完了＋ackで130clkで
すむような魔法はないよ

FSBはパケットレベルではシリアル化されてるから、CPUコア側からは
FSBまでの順序保障でよく、それより下位のメモリアクセスの読み書き保障は
CPUがしてやる必要は無いんだ。

逆に「確実な読み書き保障」が必要ってことになると、キャッシュの概念すら成立しない。

>>515
それはその当時に読んでいるし、レズリー・ランポートの論文はもっと前に読んでいますが何か
あれはメモリオーダリングの本質を書いてあるので、13年前と変わらないのは当然でしょう

KsG4ehNfはちょっと実装にふりまわされすぎ

団子やMACオタの相手をしていると調子が狂うけど

逆に20clkの内訳でも考えようか。
Penrynのパイプラインのハザードパスは14か15くらいだった気がするんだが。


ところでLarrabeeのL1はスレッド間で共有するのかな？
Pentium 4のHTは2分割するモデルが採用されたが。
いわば「再構成可能な独立キャッシュ」

>>499
PC前提の超レガシーなデバイスドライバをそのまま動かす必要がある場合なんかは、
普段はWCで、マップしたページのみPCにする、といった実装は可能だし有意義でしょう

しかしそれは特殊な例で、一般的には、「ある」プロセッサが外部にどう見せるか、なので
相手が誰でも関係ないでしょう

> Larrabeeのキャッシュコヒーレンシとメモリモデルについて意見ある？

ファンシーな機構がついてるとうれしいな
順序制御すべき一連のメモリアクセスにIDをふっておいて、それとは無関係のアクセスをブロックしないようにするとか

NehalemではFSBが近くなるからフェンス命令での待機時間も短くなることが期待できるんだが。


> Larrabeeのキャッシュコヒーレンシとメモリモデルについて意見ある？

何度もいってることだがmovnt*はキャッシュプライオリティモデルで「最低」に位置づければいい。
目的は「キャッシュの汚染を最小限にすること」なので
キャッシュコントローラの作用でさっさとパージされてしまうなら
「本物の」ライトコンバインプロトコルを用いなくても構わないわけだ。

＃もちろんmovntを通常のストアと同じように扱う実装があっても構わない。
＃それはそれで汚染は最小限だからだ。

>>519
例えば、キャッシュラインの排他的なオーナーシップを確保するロード命令と開放するストア命令といったものは、
簡単なロックを実現でき、コヒーレントキャッシュと親和性も高いんではないか

>>521
共有データが1ラインに収まらない場合は、上記の命令でサンドイッチすれば、
領域IDつきacquire/releaseみたいなものが実現できるかな

あ、なんだか盛り上がってきた、嬉しいなぁ

>>516
メモリシステムからのAckを待って、なおかつメモリアクセスレイテンシより
待ち時間が短くなるケースは存在するよ。たとえば、一般的に用いられてい
るブロードキャストベースのスヌーププロトコルでは、アドレスのブロード
キャストとキャッシュステータスの確認が完了した時点で、(読み出し、書き
込みデータの転送完了という意味での)メモリアクセス完了より早いタイミン
グで、SMPシステムグローバルなメモリアクセスの順序が確定する。

まあ、あくまでも実装依存な話だけどね。

>>519
> しかしそれは特殊な例で、一般的には、「ある」プロセッサが外部にどう
> 見せるか、なので相手が誰でも関係ないでしょう

たとえば、PowerPCだと、I/O空間はNon Cacheable & Guardedというページ
ステータスをつけること、という規定がなされていて、これをやるとstore
の実行順序が保障されるという副作用がついてきて、通常のアクセスより厳
しめなオーダリングになったりする。

こんなこともあるからレガシパワーってのは侮れんよね。

FSBまでのアクセスクロック数っていくらだったか正確に取れる方法あるけ？
Core 2はRDTSCがFSBから取得だからRDTSCそのもののオーバーヘッドを計れば
いいのけ？

>>522
ロックを欲しがっている他のプロセッサをディレクトリに登録しておいて、開放時に渡す

ロックを持ったまま例外が起きたら、ロックを開放するとともにディレクトリをたどって、待っていた連中にも例外を発生させる
スピンロック中にOSから例外上げられるのと同じ

>>498
210.149.190.* www
ttp://ja.wikipedia.org/wiki/%E3%83%8E%E3%83%BC%E3%83%88:%E3%83%97%E3%83%AC%E3%82%A4%E3%82%B9%E3%83%86%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3/2006%E5%B9%B45%E6%9C%88

既に噂に上っていた通り、Appleに買収されたP.A.Semiのスタッフわ、次世代携帯機器用の
ARMコアを開発中とのことす。
http://bits.blogs.nytimes.com/2008/09/15/new-iphone-chip-will-cost-an-arm-and-a-missile/
　　----------------------
　　Wei-han Lien, the senior manager of Apple’s chip team, dished out the morsel on LinkedIn,
　　saying he’s busy at work crafting an ARM processor for the next-generation iPhone.
　　----------------------
関連情報わ、この辺す。 http://pc11.2ch.net/test/read.cgi/jisaku/1214999146/89-92

ところで、このNY Timesの記事ってAshlee Vance記者が書いてるすけど、The Registerから移籍した
すかね？

記者の移籍と言えば、ITJungleで良質のIBM系記事を書いていたTimothy Prickett Morgan記者が、
The Registerで記事書いているす。
NECが米国のクラスタ屋Approにベクトル機を含む製品を提供するとか。
http://www.theregister.co.uk/2008/09/16/appro_nec_deal/
　　---------------------------
　　Under a partnership announced today, Appro is teaming up with NEC's HPC division to have
　　it sell Appro gear alongside its own SX-9 vector supercomputers, which have a respectable
　　peak processing capacity of 839 teraflops, and its LX Series of X64 clusters that run Linux
　　or Windows and are meshed together using InfiniBand interconnects. (NEC supports both Intel
　　and AMD chips in these LX clusters, while the SX-9 machines use a home-grown vector
　　engine - one of the remaining few left on the market. Cray also still sells vector boxes).
　　---------------------------
CrayのWintel(XeonとWindows HPC Server 2008)採用デスクサイド・スーパーコンピュータ CX1とか。
http://www.theregister.co.uk/2008/09/16/cray_baby_super/
　　---------------------------
　　The blade chassis has eight slots and runs off normal wall power, not the 240-volt power
　　required for big iron in data centers. The CC48 blade has a single Xeon socket and lots of
　　memory expansion for memory-intensive HPC workloads, while the CC54 blade has two
　　Xeon slots and a little less memory.
　　---------------------------

OrionのDS-96が脳裏をよぎった。

どうもAtomのlfenceはNOP扱いで確定だわ。全くブロッキング作用が見られない。
ま、デコーダがComplex・Simple各1基しかないのにレイテンシ・スループット0.5の時点で
ComplexでもSimpleでもデコードできることを意味するわけだがな。

逆に、Complexデコーダパス縛りのmfence/sfenceはマイクロコードROMを参照する。かも

また、キャッシュの調停にFSBを経由するヅアルコア版では動きが変わる可能性がある
・・・かもしれないね

>>529
どっちかっつーとApproがSX-9を売るって話じゃなくて
NECがApproのクラスタを売るって話じゃないの？

Morgan記者のThe Register移籍についてわ、ITJungleの方に告知があったす。
http://www.itjungle.com/tfh/tfh091508-story06.html
　　------------------------
　　Effective today, September 15, I am taking a position as Systems Editor over at British IT
　　publisher The Register, which just so happened to be looking for a smart-alek server and
　　operating system editor on the same week that I was looking for a way to better capitalize
　　on the substantial amount of writing I do in the Linux and Unix areas.
　　------------------------

>>532 さん
訂正感謝するす。Morgan記者がThe Registerで記事を書くようになったという話の方が目的だった
ので、斜め読みでいい加減に書いてしまったす。

>>531
lfenceは if(*A == 0) {C = *B;} みたいなケースでAからのデータ読み出し
が確定するまえにBのデータが読み出されるようなことが無いよう、保証
するものだからね。

in-orderプロセッサでは、普通、Aの確定を待たずに分岐後の命令の投機的
実行をガンガン進めたりしないからnop扱いでいいんじゃないかな。

>>534
全然わかってない

そんな仮定や特定の実装とも関係ない

>>535
うふふ、じゃlfenceをnopじゃなく実装する必要があるケースを教えてあげ
やう。

分岐後の命令を投機的実行するプロセッサでは、Aからの読み出しとBからの
読み出しが同時にメモリに投げられた状態が起こりえて、なんらかのはずみ
でBが先に確定しちゃったとしたら、*Aが更新される前で、*Bも更新されて
ない時の値を読んじゃうことがあり得る。ほんとだよ。

だいたい、オーダリングルールの実装のオーバーヘッドがどんなふうに生ず
るなんて、おもいっきり実装依存な話なんだからさぁ。

あ、それから、sfenceがnopみたいに見える実装ってのもありえるっつーか、
PCやSCなプロセッサはそんなもんいらんし。

>>536
あんた>>534なの？

> in-orderプロセッサでは、普通、Aの確定を待たずに分岐後の命令の投機的
> 実行をガンガン進めたりしないからnop扱いでいいんじゃないかな。

あんたの言う↓とおり、nop扱い↑ではダメなんだよ

> うふふ、じゃlfenceをnopじゃなく実装する必要があるケースを教えてあげやう。

インオーダーとか投機実行なんて何の関係もない
WCならフェンスは必要、PCやSCなら不要というだけ

Atomは定義はWCだと思うが、実装してるのかどれかなんて知るかい

>>536
ぜんぜん読んでなかったわ
あんたの出している例なんて完全にナンセンスだから
分岐とか本当に何の関係もないから

A番地を読むと銃に弾を込め、B番地を読むと引き金を引くシステムがあるとする
SCやPCのプロセッサなら、A番地を読んで続けてB番地を読めばOK
WCのプロセッサなら、ロードの順番が入れ替わらないように、
A番地を読む、lfence、B番地を読む、にする必要がある

な、分岐も投機もインオーダーも何の関係もないだろ？

>>534の例は、分岐命令がロードAにデータ依存、ロードBが分岐命令に制御依存しているから、
ロードBはロードAにがっちり依存しているわけ
メモリコンシステンシーモデルというのは、依存関係のあるなし関係なしに定義されるから、
534は条件を限定しすぎてナンセンス

>>541
こりゃこりゃ、投機的実行ってのはさ、ひとつのスレッドを高速実行するた
めに、実行するかしないか確定していない命令シーケンスも実行しちゃう
ってことなんだから、「ロードBはロードAにがっちり依存しているわけ」
とか言い切っちゃっていいのかなーいいのかなー

よく考えてみよう！

さらにデータスペキュレーションとか入っちゃったらどうする？

>>542
学生か？

> 「ロードBはロードAにがっちり依存しているわけ」とか言い切っちゃっていいのかなーいいのかなー

いいんだよ
セマンティクスと実装はわけて考えるように習わなかったの？

で、依存関係があってもなくてもメモリコンシステンシーモデルとは何の関係もないのは納得してくれたかな？

>>543
つーか、納得するもなにも、何も言ってないじゃない、君(^^;;;)

ちょっと先回りして確認しちゃうけど

もしかして、「依存関係があってもなくてもメモリコンシステンシモデル
とは何の関係もない」ってのは、競合書き込み、読み出しが発生したとき
にSCを維持することに結果の正しさが依存するような特殊なアルゴリズム
をサポートするためにコンシステンシモデルの概念がある、とか思ってるっ
てこと？

「シーケンシャルセマンティックス」ってどういう意味かわかる？
そもそも、コンシステンシモデルの概念が発達したのって、単一スレッド
内でのセマンティックスを維持した上で性能向上を目指すテクニックを
実装してったら、マルチスレッドで変なことが起こっちゃったってとこ
から始まってると思うがなぁ。

>>544
もう全く意味不明
用語を並べるのはいいけど、ちゃんと理解してからにしてくれ
あとランポートの論文も読んでくれれば助かる

メモリコンシステンシーモデルというのは、
「あるプロセッサがプログラム順にメモリアクセスを実行した場合、そのプロセッサの**外部**からはどういう順序で実行されたように見えるか？」
これが全てだよ

依存も投機も何の関係もない

でだ、
インオーダならfence命令をNOP扱いできるって結局俺が言った通りなんだが。

>>546
sfenceは違ったでしょ？

それに、in-orderプロセッサでもlfenceをnop扱いできない実装が、、、、
うーむ、考えにくいかも。ごめん。

>>545
だからさぁ、「プログラム順」と「外部からの見え方」の関係が投機実行
するかしないかによって違ってくる、したがって、同じメモリモデルでも
投機実行の有無によってfenceの実装の仕方が変わってくるって言ってるん
だけど、わっかんないかなぁ。

んで、>>214-215あたりを読み返すと。
馬鹿は死ななきゃ直らない。

>>547
なんでそんなに投機実行にこだわるわけ？
それ以外にもあらゆる要素がフェンスの実装に影響する

sfence/mfenceも事実としてSimpleデコーダではデコードできないことしか断定できないよ。
いくら実質NOPでもComplexでしかデコードできなければLat:Thpt=1:1だ。

解ったのはマイクロコードROMによって動作が替わる可能性があるということだけ。

>>549
storeと違って、loadのプログラム順的な(シーケンシャルな)セマンティク
スって、データ依存とか制御依存とかの形でプロセッサの動作を強制しちゃ
うわけさ、だから、投機実行をやらなければ、lfenceはいらないかも、とい
うことになる。

もちろん、投機実行をやらず、なおかつnopじゃないlfenceが必要なケースも
考え出せないことも無いが(lfenceとsfenceが相互作用して初めて順序付け
が成立するみたいな)、団子に言ったとおり、実用的な条件ではちょっと思
いつかんかった。

にしても>>548は言い過ぎだぞ。団子。

シングルイシューで投機実行なし、スコアボードのみのプロセッサでも、
先行するメモリアクセスが主記憶まで出ていき、後続のメモリアクセスがキャッシュにヒットすると、
外から見える順番は入れかわるよね？

ちなみに、本物のNOP命令そのものを始め、SimpleDecoderでデコード可能な命令とインタリーブすれば並列実行できる。
両命令の現状の動きは「Complexでしかデコードできない特殊なNOP」。

>>551
> storeと違って、loadのプログラム順的な(シーケンシャルな)セマンティク
スって、データ依存とか制御依存とかの形でプロセッサの動作を強制しちゃ
うわけさ

君はプロセッサの中でしか考えていない
プロセッサの外からどう見えるかがメモリコンシステンシーモデル

>>552
ところがAtomでは*fenceの使用有無にかかわらず、
L1上にない領域へのL/Sの度にストールする。追い越しは起こり得ない。
L/SともL1キャッシュヒット前提でメモリアクセスを直列化したパイプラインが組まれてるからだ。

ライトスルー？さてそんなもんが実装されてるかね。
異論があれば計測してみてくれよ。机上の空論は認めない。

>>552
そうくると思った、そうすると、次の質問は「それでどんな問題が発生
するの？」で、そうすると最初のロードと次のロードの間に何らかの依存
関係(制御 or データ)が無いと、順序の乱れがプログラムの挙動の変化と
して顕在化しないんではあるまいか、ということになる。

>>556
それは上のほうに出ていたDEC WRLの論文を読んでくれると例が出てくる

プロセッサA:
X = v1
Y = v2

プロセッサB:
v1 = v2 = 0
v2 = 2
v1 = 1

というプログラムを実行する
Bはプログラム順にv2を書き込んでからv1を書きこむとする
Aもプログラム順にv1を読んでからv2を読むと、もしX = 1ならY = 2が期待される

Aがv1とv2の読み出し順序を入れ替えてしまった場合、タイミングによっては、実行結果が
X = 1, Y = 0になってしまう可能性がある

トリビアルな例ですまんが、なんとなくでもわかってもらえるとうれしい

>>557
だからさ、そういうユースケースをほんとに想定してるの？というのが疑問
なんだけど。で、>>544に戻るっと。

もっとも、>>555を見ると、そんなん関係ないぐらいコンサバな実装をしてる
とも読めるが。

Atomはストリーミング処理をやるようなCPUではそもそもない。
エンコードは高性能なCPUで、というマーケティング上の意図もあるからね。

ノンテンポラルなストア機構は未実装でMOVNTは通常ストアのエイリアスである可能性が高い。
とすれば、まさに安かろう悪かろう、Intelの思惑通りのプロセッサ。

>>558
> だからさ、そういうユースケースをほんとに想定してるの？

万に一つの誤動作も許さないのが当然
先生に聞いてみな

Atomはあくまで可能な一実装にすぎない
Atomで一般論を語るのは誤り

Atomはどうモデルを実装しているのか？
モデルの可能な実装方式にはどういうものがあるのか？
モデルの意味論はどうなのか？
すべて異なる話

Larrabeeにおいては新命令のキャッシュのコヒーレントコントロール命令が実質的に
他のコアのスレッドから見たメモリコンシステンシモデルをゆるめる効果があると見られる。

安かろう悪かろうという割りには、無駄に性能が高いけどな。
個人的にはMMX 300MHz相当で問題ない。

>>558
ごめん、ちょっと、>>557の例をちゃんと見てなかった。

> Aがv1とv2の読み出し順序を入れ替えてしまった場合、タイミングによっては、実行結果が
> X = 1, Y = 0になってしまう可能性がある

それはない、ちゃんと考えてよ。

>>563

B: v1 = v2 = 0
A: Y = v2 (0)
B: v2 = 2
B: v1 = 1
A: X = v1 (1)

のタイミングだと、X = 1, Y = 0になるよ

>>564
どうやって、A: Y=v2がキャッシュヒットして、A:X=V1がミスするなんて
ことが起こるのさ。

少なくともこのケースでは、Bの書き込みはAにin-orderで通知されるぞ。
Bの書き込み同士の間にはsfenceがついてるんだろ？

なんか、こういうので勝ち誇るって恥ずかしくないか？

>>565
どうしてこう特殊な仮定を置きたがるかな

> どうやって、A: Y=v2がキャッシュヒットして、A:X=V1がミスるなんてことが起こるのさ。

キャッシュミスに拘っても仕方ないよ。

> 少なくともこのケースでは、Bの書き込みはAにin-orderで通知されるぞ。

通知って何だ？

> Bの書き込み同士の間にはsfenceがついてるんだろ？

フェンスがついているとも言ってないぞ


Bはあくまで、v2を書き込んでからv1を書き込むようにAに見えるように保証する、という最小の仮定しか置いていない
Aについても、プログラム順では先のv1の読み出しが、どういうわけかv2の読み出しに追い越された、という最小の仮定しか置いていない

>>562
それだと数百円クラスのARMにも余裕で負けないか？
ARMと比較してAtomを選ぶ価値がある
ことが前提
仮にも45nmつぎ込んでるわけだからダイサイズあたりの価格はCore2並にはもっていきたいところでしょうし。

>>566
それだと、>>557は、全く正常な動作で何の問題も発生していないってこと
になる。

>>568
いや、>>557は全く正常な動作なのだが、プログラムの逐次的意味論からはありえない結果になって非常に困る

Achronix、1.5GHzの内部クロック周波数を実現したFPGAを製品化
http://journal.mycom.co.jp/news/2008/09/16/038/index.html

>>569
うわああああ、うーん、まあいいや、いうべきことは過去に言ってるし、
繰り返しになるから何も書くまい、じゃ、元気でね(^^)/

>>571
捨てゼリフは結構

SCやPCより緩いモデルにおいては、プロセッサ外部から見えるメモリアクセスの順序は、プログラム順通りとは限らないため
(フェンス命令を適切に使用しなければ)システムはプログラマが意図した動作を保証することができない
それだけの事だよ

それ以外の要素は一切関係ない
投機だのインオーダーだの持ち出すのは何も理解していない証拠

Atomがどうか？という事なら、インテルがAtomはSCやPCだと明言しない限り何とも言えない
そうでなければ、アーキテクチャ定義はWCなのでWCとして扱わざるを得ない

もしかするとAtomでは極めて稀なケースでメモリアクセスの順序の入れ替えが起こるかもしれない
メモリアクセスの順序が(W->Rを除いて)全く起きない、つまりAtomは実はSC(PC)を実装しているとと言い切るためには、
チップのリバースエンジニアリングをしないといけない
命令の実行時間をどれだけ測っても無駄、馬鹿の極みだよ

MOVNT* の作用は「キャッシュ汚染を最小限にすること」であって、
WCプロトコル云々はあくまで実装依存の話。
非NTと同じ動きをしても、それは命令セットの仕様としては問題ない。

あと、HTが実装されてるとはいえL/Sは1基ずつだから、2スレッド間でのL/S順序は投入された順となる。

追い越しが問題になりそうなのはMCMのデュアルコア版。

チップのリバースエンジニアリング以前に計測すらせず
拙い机上論理と無根拠な斯くあるべきという思いこみだけで
ものを語る以上は技術論としては成立しない。
とりあえず先ずはトレースしろ。知らない奴は語るな。

先人は言いました
「思いて学ばざるはすなわち詭うし」

お団子くんは人に理解させようという心意気が足りないよな。いや最初期待してないんだけど。
むしろ相手が理解できないところをみつけてそこで理屈をこねくりまわしているという。

団子のやっていることはアマチュアの発想なんだよ
いろいろ計測したところで、すべてのケースを尽せる保証があるわけではない
無駄無駄無駄

宝くじを1万枚買って、一等が入ってないイカサマだと主張するようなもんだな

1.どういう条件下で
2.どのように計測すると
どういう結果になったか、これが科学では重要

団子は1に考えが及ばずに、Atomのlfenceは実はnopだ!という短絡的な結論にすぐ飛び付いてしまう

アマチュアの発想というより行動がガキくさいだけ。
いろいろ計測して事実を証明していくというのは本当にちゃんとやっていれば興味深いんだけど。

都合が悪くなると、おれはいつも計測しているがお前は計測していない、
おれはプロだしお前より実践しているんだ、などと内容と関係ないところで
自分の発言の正当性をアピールしようとする。
計測しているわりにまとまった成果がいままでに何もみえないし、
当人の書き込みが机上理論な人達の話と同レベルの内容・精度しかでていないので話がうさんくさい。

とりあえずメモリコンシステンシモデルが緩いだキツいだ、だのは理解の邪魔だと思うんだ。
「卵を机の上に立てる方法」を、重心がどうだの議論するがごとき愚考をしてる自覚を持ってほしい。
言葉に惑わされて本質が見えてこないでしょ。

答えは意外とシンプルなんだ。
（少なくともシングルコアの）Atomはロード・ストア順序は常にシリアル化できている。
なぜならAtomはL/SともアドレスがL1キャッシュに存在しなければストールするから。
L1にフェッチされるまで後続のL/Sも含め、待たされる。
これはP5までの動きと何らかわらない。
で、L1にある限りは読み書きのレイテンシは一定とみなせる。
だから逆転は起きないんだ。
愚直に順序どおりに実行するから順序保証の仕組みが必要ないだけ。


たとえるならモーションブラー処理が入ってると思ったら
単にLCDの反応が遅いだけでした、的な。

全体的な知識ではどうかしらないが、
使える書き込み度ではソース張ってるだけMACオタの方が遙かに上。
団子は分量が多いわりに内容がないので、読む気にもなれん。

NOPでないケースを例示してくれ。
実装とかけ離れた推測および机上論理は詭弁と見なします。

団子が想像するように、実はAtomはSCやPCを実装しているのかもしれない
しかしインテルはそれを保証していないし、
団子がどうプログラムを走らせて計測してみても、
(蓋然性は高まるかもしれないが)何の保証にもならない

つーか、団子レベルの知能で計測しても変なデータしかとれんし、信憑性ないだろ。

プロの技術者でも計算はできるけど理論の適用範囲をとり違えて意味の
ない間違った計算してるやつとかいるけど、それのソフト版が団子に近い。
結局読めばひたすら自分の脳内仮説を書いているでけで、あとからでも実証もしてないからな。
Atomでも実行開始の順番は入れ替えてるんだが、それもしらないようだしさ。

団子は論理学の基本が判っていないようだ
団子の主張: Atomのlfenceはnop
おれの主張: Atomのlfenceはnopか否かわからない

>>582
> NOPでないケースを例示してくれ。
おれに聞かれてもわからないよ

PCやSCってなんだ？やっぱり本質が見えてないな。
i486もPCやSCか？
まあパーソナルコンピューター向けのシングルコアではあるな。


そもそもシングルコアAtomはユニプロセッサだ。
「他のCPU」は同じコアで動くもう片方のスレッドに他ならない。

S/MFENCEだけはComplexデコーダパスにしたのは
マイクロコード書き換えでMCM版などでの動作を変えられるからだろ。

>>584
ばかめ、メモリアクセスは順序化されてる。

順不同なのは開始順ではなくリタイヤ順。P5で既にそうだったし。

>S/MFENCEだけはComplexデコーダパスにしたのは
>マイクロコード書き換えでMCM版などでの動作を変えられるからだろ。
とりあえず状況証拠一つで、断言する癖はやめようぜ。

状況証拠ですらない詭弁は聞きたく無いがな。
フェンス命令の実行アルゴリズムとシンプルデコーダの機構を知ってれば
AtomにおいてシンプルデコーダでもデコードできるLFENCEが常にNOPなのは机上論理でもわかる。

ヒント：P6以降のIA32およびAMDマイクロアーキはデコーダとリタイヤユニットは連動してる。

http://www.freeweb.hu/instlatx64/
とりあえず面白いのピックアップしてみた

Pentium III
Inst 763 SSE : SFENCE L: 9.12ns= 6.7c T: 9.12ns= 6.67c

Pentium M
Inst 763 SSE : SFENCE L: 4.17ns= 6.7c T: 4.17ns= 6.67c

Core 2 Duo
Inst 683 SSE : SFENCE L: 4.83ns= 9.0c T: 4.83ns= 9.00c

Pentium 4(Northwood)
Inst 763 SSE : SFENCE L: 24.31ns= 39.1c T: 24.21ns= 38.92c

Athlon 64
Inst 763 MMX+ : SFENCE L: 4.00ns= 8.0c T: 4.00ns= 8.00c

VIA C7
Inst 763 SSE : SFENCE L: 1.11ns= 1.7c T: 1.11ns= 1.67c

Atom
Inst 683 SSE : SFENCE L: 0.63ns= 1.0c T: 0.63ns= 1.00c

VIA Nano
763 SSE :SFENCE L: 7.70ns= 14.0c T: 7.70ns= 14.00c


このへんである事実に気づくよな？

命令ﾚﾍﾞﾙのクロック測定ってどんだけ意味あんだ

俺的には理想に近い感じだ。

それよりQFPやGTＸ200ってどうよ

>>591
確かに意味ないよ。
でも机上論者くんたちは空回りなのにクロック数がかかる理由すら
おそらくわかってないだろ。
実はちょうどいい教材なんだよ。

OoOなx86ではパイプラインはリングバッファみたいになってて
デコーダはリタイヤステージを監視しつつデコードを行う。
2命令リタイヤすれば2命令を新たにデコードする。

フェンス命令の実行モデルはその機構を逆手に取ったもので
Complexデコーダにてフェンス命令がデコードされると、前のロードないし
ストア命令（あるいはその両方）に依存関係を持つダミー命令を投入し
リタイアするまでデコーダを止める。

で、P6〜Core 2、K7〜K10をみれば、パイプライン段数＋αでダミー命令が
リタイアしてくることがわかる。
もちろんメモリアクセス後のフェンス実行だと、ストアの順序保障ができるところまでの
クロックが加算される。


でもAtomがベストもワーストも1クロックってのはそういう作用すらないってことなんだ。
なぜならインオーダだから。

＞で、P6〜Core 2、K7〜K10をみれば、パイプライン段数＋αでダミー命令が

ここでのパイプライン段数はマイクロオペレーションをキューイングするところからリタイヤまでな。

いい子だから今夜はもうｸﾞｯｽﾘお休み

まあアレだ

movntps [edx+0]
sfence
movntps [edx+16]
sfence
movntps [edx+32]
sfence
movntps [edx+64]
sfence

Atomでこんなコードをループまわしてクロック数計測してみれ。
ノンテンポラルストアをやってないこととsfenceに全くブロッキング作用が
ないことが同時に証明できる。

>>585
シンプルデコーダでデコードできる命令はマイクロコードによる命令の動作変更をサポートできない。
ある条件でNOPなら常にNOPなんだよ。

LFENCEが常にNOPとは限らないと主張することは
つまり、Atomの2つのデコーダはComplexデコーダ×2だと主張することになるんだぞ。
もちろん事実に反している。
てめーには論理も糞もねーんだよ。ヴァカもたいがいにしろ。

それでも実証に望んでる分だけは評価する。

某資料には2命令並列デコード時はXLATを使うって書いてあるが
これって要するにテーブルルックアップな。
prefixとかで分岐してOpcodeを辞書引きしてデコード完了。

たとえば0F AE /5 を辞書引きしたら対応するマイクロオペレーションはNOPでした。
としたらずっとNOPな。それがハードワイヤードロジックというやつだ。

これ、CPUアーキテクチャの常識な。
常識がないやつがメモリコンシステンシ云々の理論とか笑うしかないんですが


で、マイクロコードROMがぶら下がってるのは2つのデコーダのうち片方だけなので
マイクロコードROMを参照する命令のスループットは1命令/clk以下になる。

>>594
これはすごくいい線行ってると思うな。

ただ、ダミー命令が、それ以前のメモリアクセスと依存関係を持っている
必要性は必ずしも無いと思うぞ。なぜなら、リタイヤはin-orderにしか
しないし、メモリアクセスは順序性が保障できるタイミングになるまで
リタイヤしないから。

要するに、nopでもなんでも突っ込んでそれがリタイヤするまで待てば
良い。

in-orderプロセッサでは、sfenceが発行されると、write bufferに「しお
り」みたいなものを突っ込んで、すでにwrite bufferに入っているアクセス
と順序が入れ替わらないようにしたりする。

これがサイクルにどういう風に影響するかどうかについては、実装と動作状
況しだいだが、x86アーキの場合は通常のアクセスが強い順序付けだという
のも効いてくるかも(つまりデフォルトがコンサバ)。

>>597は、sfenceが間に挟まることによって、write gatheringができなく
なって書き込みスループットが落ちるといった影響が出る可能性が考えら
れるがどうなのかね？

にしても、これだけ短期間でこんなに勉強と調査をしてくるやつは初めて
見た。すごいぞ団子。

「in-orderとか、投機実行とかは命令の実行順に影響を与えるから、fence
が実行サイクルにどのような影響を与えるかと関係している」

に対して、

「SCやPCより緩いモデルにおいては、プロセッサ外部から見えるメモリアク
セスの順序は、プログラム順通りとは限らないため(フェンス命令を適切に
使用しなければ)システムはプログラマが意図した動作を保証することがで
きないそれだけの事だよ」

とか答えちゃう誰かさんとはずいぶんと違うなぁ。

>>602
ちなみにダミー命令には目印がついてて、
デコーダとしては自分自身で目印をつけた命令なのでそれだけのリタイアを追えばすむ。
一番ローコストな方法だよ。

ダミー命令を使うモデルはP6〜Core 2、K7〜K10で共通。


P5やAtom見たいなインオーダコアはそもそもリングバッファになってない。
どっちかというと心太。

なんだ、まだいたのか
群盲象を撫でるとはまさにこのことだな

「SCやPCより緩いモデルにおいては、プロセッサ外部から見えるメモリアク
セスの順序は、プログラム順通りとは限らないため(フェンス命令を適切に
使用しなければ)システムはプログラマが意図した動作を保証することがで
きないそれだけの事だよ」

これは俺の説明がまずいところをのぞけば100%正しい
間違っていたら首を吊っても腹を切ってもいいから、君の先生のところに行って判定してもらってきな

あ、もしかして学生くんは

> システムはプログラマが意図した動作を保証することができない

これを、実行するたびに、常にプログラマが意図した動作==逐次的意味論とは異なる結果をもたらす
と解釈しているのだろうか
もしそうならそれも間違いだ
逐次的意味論と異なる結果が「ごくたまに」あるかもしれないし「しょっちゅう」かもしれない、結果は不定だということだよ

> プロセッサ外部から見えるメモリアクセスの順序

L1キャッシュにあるデータを即座にメインメモリに反映しろというなら無理な話だ

なんのために「I/O専用領域」なんて作ってカーネルモードでしか触れなくしてると
思ってるんだ。
ばかもたいがいにしろ

まあ、ブロックダイアグラムの「XLAT」の意味すらわからない馬鹿は
学すらないんだろうけどな

この辺でも読んでくれよ ブロックダイアグラムも載ってるしな。
ftp://download.intel.com/corporate/pressroom/emea/deu/fotos/08-03-CeBIT/Texte/TechnicalPaper_45nm_Silverthorne.pdf
http://download.intel.com/design/processor/manuals/253665.pdf

なんかわからんがAtomのキャッシュはマルチスレッド用に設計されてるとさ。

まあとりあえずAtomはPC(パソコン)用のSC(シングルコア)なのでさっさと首釣って氏ね

>>604
うーん、これ以上この話に対して新たなネタを提供する気はないよ、ってこ
となんだけど、「捨て台詞」とか「まだいたのか」とか自意識過剰なんじゃ
ないの？

>>602をもちっとシンプルにしてみると
「fenceの実行サイクルへの影響は実装依存」
に対して
「fenceは入れなきゃいけないんだよ」

こういう噛み合ってないやり取りを続けてる限りは、これ以上情報を追加
しても意味がないでしょ？

自分の会社のCのコーディング規約を語る奴

というか脳内アーキテクチャでの思考実験でしかものを語れないから本質的に無意味。
言葉の意味に捕らわれすぎて現実が見えてない。

「ドキュメント化されてないものは解らない」
で、ドキュメント化された文言の言葉尻だけをとらえて現実とかけ離れた
脳内アーキテクチャを想像してしまう。
それは文系人間のやること。

実験から考察して固定観念を切り崩していくのが科学だ。
実験すれば解る事実すら認めないのだから、そんな教育すら受けてないんだろうな。

>>608
"Intel® 64 and IA-32 Architectures Software Developer’s Manual"
を拾い読みしてみた。

lfenceの定義は、loadの順序づけ+投機的実行の抑制、となっとるの。

ちょっと面白いのは、SSEでsfenceだけ追加してlfenceを追加していない
こと。

Pen4は投機ロードしまくりだからね
逆にパイプラインがデリケートでデータがL1に無いだけでもトレース列が総崩れする。
それで予測に基づいてL1にフェッチしてロードをプールしてしまう。
代わりにprefetcht0を使ってもL2までしかフェッチされない。

団子はエンジニアだけどサイエンティストじゃないよなー

エンジニアは99%の実証があればオッケーだが、サイエンティストは1%の不確定があれば不可だ。

んでさ、Atom の実装がどうなん、って話なら、NOP のとか面白いネタなんだけど、
やってることはエンジニアの範疇だよね。なのにサイエンスやってるみたいに振る舞うのがね。
なんかさー、サイエンスに対するコンプレックスが駄々漏れで気持ち悪いだよねー

>>616
あくまで99%だけ正しいと自覚してるんならね
団子や>>602は、そういう自覚がないから困るんだよね

>>610
違うね
メモリモデルを理解していない奴が

> 「fenceの実行サイクルへの影響は実装依存」

こんなことを言って計測しても無意味で無駄だと言ってるんだよ
団子だけじゃなくて君もだよ

> こういう噛み合ってないやり取りを続けてる限りは、これ以上情報を追加 しても意味がないでしょ？

おれの指摘は完全に正しいのだが、君達が理解できていないだけのこと

>>617
いま過去の書き込みを読み直してみたが、俺の書き込みのどれを君がパター
ンマッチしてケチをつけてるのか分かったと思う。

でもさ、「ATOMでlfenceがnop扱いじゃいけない理由」に対して「お前らバカ
だから」じゃあまり説得力が無いと思うんだよね。具体的にどのような
動作を行うプロセッサとメモリシステムでどういうケースで問題が発生する
からlfenceをnop扱いできないのか、教えてくんないかね？

>>618
> 具体的にどのような
> 動作を行うプロセッサとメモリシステムでどういうケースで問題が発生する
> からlfenceをnop扱いできないのか、教えてくんないかね？

これが君や団子が論理的な物の考えができていない証拠

おれはあくまで、
AtomはWCかPC(SC)かどうかわからない、と主張してるんだよ
AtomはWCではない、と主張しているんではないんだ

まずこの違いを認識して欲しい

まあバカに構うだけ無駄


科学者とかｗｗｗｗｗ

ただのアスペルガー症候群の痛い子なんだから
CPUの話をやりたがる割にはCPUのコードシミュレーション環境を持っていないようだし。
科学者なら科研費を億くらいもらってからほざけよ的な。CPUくらいいくらでも買えるぞ。

おまけにララビがSSEサポート(⊂x64準拠)なら死ぬという口約束すら守らない生き恥男

メモリフェンスモデルは害悪だからサポートするべきではないとかさ

どんな理論屋だよ。
どこに嫉妬してほしいの？むしろsitしてほしいの？

SimNowとかのパイプラインシミュレータとか使ったことないんだろうな。
x86のデコーダの仕事すら知らないんだぜ。ありえねえ

自称科学者とかｗｗｗｗｗ頭おかしいｗｗｗｗｗ

ハードワイヤードロジックでNOP扱いされてる事実を認めたくなくて駄々こねてるだけだろ

結局、ハードワイヤードロジックでNOP扱いされてる
結果の出てる事実を認めたくなくて駄々こねてるだけだろ

実測に勝る仮説など無いよ。

科学の根元は「無知の知」
自分の狭い了見で閉じて現実を直視できない人間を賢いとは言わないんだ。

団子ちゃん飛ばしてるなw
面白いww

まさに疑似科学にはまる工学部の先生によくある言動じゃんｗ

lfenceが単純デコーダのXLAT/FLすなわちハードワイヤードロジックでデコードできる
という100％確実な事実から導き出される、NOP扱いという真実が
どう「不確実」か説明する義務から逃げるな。

おまえの確実か不確実かなんて「standard 64-bit extention」がx64とは限らない
とかの屁理屈レベルだろ

>>628
まぁ万年科研費ゼロの落ちこぼれ教員は実験機材を買うことすらできないから
ひたすら似非理論をやるしかないからな。

そりゃそうだ

推測と事実の区別がつかないのは団子だけでいいよ

推測：LarrabeeはSSEをサポートしない
事実：x64準拠

で、どこのFランク大学の助手さんですか？

>>619
じゃ、質問を変えよう。

メモリモデルはRelease Consistency。

キャッシュコヒーレンシプロトコルはブロードキャストベースで、
Invalidationを含むトランザクションが各プロセッサやメモリに到着
する順序はsfenceで規定される順序に矛盾しない。

プロセッサパイプラインからissueされたメモリアクセスのcache tag
lookupの順序はissue順。

これって結構よくあるケースだと思うが、このときlfenceがnop扱いできな
い条件は何だ？投機的実行とかin-orderとかは関係無いんだよな？

>>633
おいおい、思ってても口に出さない方がいいことってあるぞ。「学生」とい
う言葉に妙なコンプレックスを持ってそうなところとかみるとそうかなぁ、
とも思うが。

マイクロコードROMのではなくルックアップテーブルでデコードできる命令が
状況によってNOPだったりでなかったりするケースなんて前例がない

ところでLarrabeeのVector Scat命令はキャッシュラインに対するパーシャルライトではなくLoad-Op-Storeの形だそうだな。
まあ現状MASKMOV*がそうだけど。

>>634
Release Consistencyにlfenceはないが、まあいい

>>557の例で言うと、
X = v1 のメモリアクセスが地球を一周してきて、それから実行される
その間に、Y = v2の実行がさっさと終わってしまう

こういう場合には、v1とv2の読み出しの間にlfenceが必要
投機実行もインオーダーも関係がない

>>635
ある命題が「正しい」ことを証明するには、思いつくだけの例を上げただけじゃだめなんだよ

「すべてのケース」を尽していることを証明してはじめて、「命題が正しい」と言えるんだ

＞ おいおい、思ってても口に出さない方がいいことってあるぞ。

図星だからか？
本音は崩れのニートかな。
少なくとも国から研究費をもらってる人間とは到底思えない。

＞「学生」
何年も前に引退した身分だが別に
強いて言えば暇があってうらやましいよ。

昔、Encoreという会社のGigamaxという階層バスの共有メモリマルチプロセッサシステムがあってね
当然キャッシュコヒーレンシープロトコルも備えていた

このプロトコルは、メーカーでさんざん考えつくしてシミュレーションを行なって設計したんだけど
出荷してだいぶ経ってから、形式的証明でプロトコルの穴が見つかった

コンシステンシーモデルとは違うけど、メモリシステムの設計はそれくらい難しい話なんだよ

ちなみにうちの大学は在籍時代から理研や産総研から客員が送り込まれてたりしたよ。
さすがにi社はいなかったが。

ま、ERATOやCREST、COEなんかの大型研究プロジェクトにはよくある話だが

つーか情報工学で理論屋なんて金がない負け組研究室の典型じゃん。

W？

研究室単位で見ても経産省のERATO/CRESTの予算額は文科省科研費の基盤研究Aなんかより大きかったよ。

とりあえず情報やる研究室では即技術転用ができる実践屋の方が圧倒的に勝ち組なのはガチ。

>>636
いい加減な説明だなぁ、invalidationの到着順を考えれば「地球を一周
する」なんてことあるはずないじゃない。

>>643
プロセッサAはv1を読み出そうとして、リクエストが地球を一周する
次に、Aはv2を読み出そうとして、すぐ読んでYに値を書き込む
だいぶ時間が経ってから、v1の読み出し値がAに到着して、Xに書き込む

つまり、v2よりv1のほうが先に読み出される

これだけで説明は尽きるよ
invalidationの出る幕はない

>>644
おっと、
> つまり、v2よりv1のほうが先に読み出される
×先
○後

invalidationどころか、キャッシュそのものがメモリコンシステンシーモデルとは関係がない
(「実装するときに」ややこしいことを考える必要はあるが)

SC(PC)のプロセッサA'では、こうなる

A'はv1を読み出そうとして、リクエストが地球を一周する
A'はv1の値を読み出せてXに書き込むまで、v2の値を読み出そうとしない(地球一周を待つ)
A'はv2の値を読み出してYに書き込む

多少のオーバーラップは可能だけどね、本質的にはこう

ひどい答えだなぁ、おい、v2への書き込みがv1への書き込み「より後」に
順序付されている限り、v1の読み出しがmiss、v2の読み出しがhitってケー
スは存在しないぞ。この場合。

せめてほんの少しだけでも、ものが作れそうなことを言いなよ。

今どき日本の大学で作ってるCPUなんざゴミだろｗ
某×××とか

>>647 ごめん「より後」->「より前」

>>647
上のほうにも一回書いたんだがな

A:
1. v1の読み出しリクエストを太陽系一周の旅へ出す
2. v2の読み出しリクエストを町内一周の旅へ出す

(ちょこっと後)

A:
3. 2で旅立ったリクエストが帰還する
4. v2 == 0を読み出し、Yに書き込む(Y = 0)

(しばらく後)

B:
4. v2 = 2 を実行
5. 4の実行を確認する
6. v1 = 1 を実行

(何年か後)

A
7. 1で旅立ったリクエストが帰還する
8. v1 == 1を読み出し、AがXに書き込む(X = 1)

地球一周とかｗｗｗｗｗ

低レベルI/Oに関してはx86にはキャッシュを強制スルーして読み書きを行うモデルの特権命令があり、
通常はカーネルモードでこれを使う。

ユーザーアプリケーションでのメモリ状態なんて直接外部に公開することはありえないから
キャッシュへの読み書きさえできればCPUとしてはリタイヤしていいんだよ


さて、なぜユーザーモード命令であるLFENCEがNOPでない必要なのだね？
I/Oを叩くための特権命令のいくつかはシリアル化効果がある。
したがってLFENCE自体カーネルモードドライバでは使う必要がないんだよ。

>>648
うちの教授はソフトやさんだったよ。
だが研究生全員に当時高価だったデュアルXeonマシンを用意する程度には金はあった。

俺のCPUの知識は独学だが何か問題あるかな。
知識の正しさを決定づけるのは、学ぼうとする姿勢があるか、
あるいは情報を遮断して簡単なテストでわかる計測すらしようとしないかの違いだよ。

後者は自然科学者としてはありえない。

感覚的にわかりやすいかと思ったが、

v1 = v2 = 0

A:
1. X = v1
2. Y = v2

B:
a. v2 = 2
b. v1 = 1

というプログラムがどうして変な動作になるかと言うと、

Aの1,2の順番が入れかわって、2, 1となり、そこにBのa, bが挟まってしまって、
大域的に2, a, b, 1という順番になってしまうことが原因

だからシングルコアAtomではスレッドAもスレッドBも同じコアで同じ順序化されたLSUを使うの。
いい加減わかれよハゲ。

とりあえず自分が学者だと思うならEeePCでも買ってきて検証して見ろよ。
計測したクロック数は全てを教えてはくれないが、間違った知識の見直しの材料くらいは与えてくれるぞ。

ま、マルチコアだろうと同じだけどな。L1からしかロードできない以上、MESIプロトコルに基づいてアクセスがなされる。

MESIを知らない疑惑

>>650
うーん面倒くさいなぁ、じゃあ、hit under missは許容するが、2度目の
ミスでストール、という条件を追加。

キャッシュもin-orderも投機も関係ないんだよね？

当たり前のことで、たぶんソフトを知らない奴は本当に知らないとみえることだが
*fenceの作用があるかないかにかかわらず、マルチスレッドでのデータ共有の掟は必ず守らないといけない。
すなわちクリティカルセクションなりミューテクスなりセマフォなりで
プログラムで決めた排他あるいは共有アクセス権限を獲得してから
共有するメモリにアクセスする必要がある。
そうしないとキャッシュラインレベルでコヒーレンシが保たれていようがいまいが
プログラム全体のフローからみた共有データのアクセス順序は保証でしようがない。

フェンス命令後にロックを解放すれば、コヒーレントプロトコルに基づく順序関係は確実に保証できるということだけだ。
したがってただの待機処理でしかない。
フェンス命令は、共有データに対するロックの機構そのものは提供しない。

どっかのバカはフェンス命令を使えばロックを獲得せずにそのまま読み書きできると思ってるようだが。

結局最初から最後までフェンス命令の機能をわかってないんだよな。
ソフトとハードの両方を知らないと理屈が解るわけがない。
I/0がどうとか頓珍漢なことを言ってみたりバカ丸だし。
結局自分自身が学がないんだよこのアスペルガーは

>>658
何でもいいけど、ロードがロードを追い越せない条件は付けるなよ
それはもうWCじゃなくなるから

それにしても、どうしてこうモデルと実装の区別がつかないんだろうねえ

>653がバカなのは、フェンス命令を使うか使うまいかの問題じゃなしに
ロックもなしに同じメモリにアクセスする事を前提ではなしをしてるから。

ロックをかけてアクセスを順序づけないとそもそもソフトとして成立しない。

アスペルガー君はマルチスレッド対応のソフト書いたことがないんだろうな

>>661
モデルと実装の区別がついてないのは君でしょ？lfenceがnopで済むかどう
かなんて100%実装の話だよ。

それに>>658の条件を加えても、sfenceは依然として非nop実装が必要な可能
性があるからWCはWCだよ。

まぁ、MOVNT*の仕様上はWCでも実装は非WCなのがAtomだな

>>664
> lfenceがnopで済むかどうかなんて100%実装の話だよ。

違うね
メーカーがWCだと言えば、「プログラマは」lfenceをnopだと思ってはならない
実装がどうなってるかなど、知りようがないので関係がない

x86において複数のスレッドが同じタイミングでlockプリフィクスをつけずに
同じデータにアクセスすることはソフトとして基本的に禁止しなければならない。
こんな常識すら知らないから>>653みたいな無様なレスができる。

>>666
バカだねぇ
おまえか頭が悪いから理解できてないだけで実装がNOP扱いなのは既に計測で判明してるんだよ。

まあ、ハードの実装決めうちのコードを書くのは関心はしないが

>>666
だーれーが、プログラマにlfenceのnopへの置き換えを推奨するなんて話
をしてるんだ？俺はてっきり、lfenceがプロセッサ内部の実装としてどの
ように扱われていてどれくらいのサイクルオーバーヘッドを伴うのか、
という話をしていたとばかり思っていたが？

で、妥当な想定の下で、lfenceをプロセッサがnop扱いしても大丈夫な
ケースがあったわけで、それは、パイプラインのin-ordernessとか、
投機実行とかと関連性があるわけだ。

科学者(笑)くんはマルチスレッドプログラムの基本的な規則もしらないでものを語るなよ
lfenceが絶対必要なケースは無いんだよな

>>669
プロセッサがロードの順番を入れかえるようなことを決してしなければ、lfenceはnopでもよい
ただそれだけ

投機もインオーダーもキャッシュも何の関係もない
ただの一例を見つけて、それが発見だと思ってはいけない

>>671←マルチスレッドプログラムの規則も知らないおまえが言うな

lfenceはどこで必要なのか、もう一度説明してみような

マルチスレッドでの共有メモリアクセスのセオリーはこうだ
if (共有メモリ使用中フラグが立ってない){
　共有メモリ使用中フラグを立てる
　共有メモリ読み書き（必要な処理は全てここでやる）
　共有メモリ使用中フラグを落とす
}

fenceってマルチの同期に使えるのか？
てか話し噛み合ってないんじゃね？ﾓﾏえら

>>674
使えない。排他ロック処理は別途必要。
マルチスレッドプログラムにおけるフェンスの効果は排他ロック解放前に
メモリアクセス順序保証のウェイト処理をするだけ。
フェンス命令が完了してから排他ロックを解放すれば安全なわけ。
でもこのアスペルはフェンス命令そのものがブロックすると思いこんでいる。

でも言ってるだろ
PC(パソコン)のSC(シングルコア)だって。

あと、ライトスルーとアドレスの重ならない通常ストアの間にフェンス命令が
必要かという件については実装によらず「必ずしも必要ない」らしい。

というわけで前スレの件は残念だったな。恥さらしはどっちかは明らかだね。


そもそも絶対値直接アドレッシングでストアなんてふつうはやらない
プロシージャポインタをためのleaくらいしか使わない。

>>674
使えるもなにも、他プロセッサと共有メモリを介した通信をする際には、何をどう実装するにしろフェンスは絶対に必要
アトミック操作は必須ではない(大抵は使うけどね)

あと、絶対値アドレッシングの命令エンコード(ModRM+DISP32のほう)は
x64では潰されてRIP相対に置き換えられた。知ってた？
利用頻度なんてそんなもんだからな。

>>678
いつまで動作仕様を誤解してるんだ？
フェンス命令でブロックするのはフェンス命令を発行したスレッドの流れだけで
Mutexでも使わない限り他のスレッドからの読み書きは抑制できない。

アトミック操作が必要ないのは共有データそのもので
排他ロック処理が必要ないわけではない。

>>680
ヒント: デッ(略)

ヒントにも自己弁護もなってねーよ。
なんならセマフォでもいいよ。

>>671
そっちの無茶な主張に対する反例としては「だたの一例」で十分でしょ。
それから、この例っておもいっきりキャッシュ階層とコヒーレンシの実装
依存だし、out-of-orderや投機的実行でオーダリングが乱れるから、

> 投機もインオーダーもキャッシュも何の関係もない

もダウト

>>683
> それから、この例っておもいっきりキャッシュ階層とコヒーレンシの実装 依存だし、

キャッシュ階層やコヒーレンシーの実装がどうであろうが、
v1とv2の読み出しの順番が入れかわる可能性があるならWC、そうでないことが保証されていればSC(PC)

> out-of-orderや投機的実行でオーダリングが乱れるから、

OoOや投機実行とメモリコンシステンシーモデルは何の関係もない
OoO+投機ロードかつSCな実装もいくらでもありうる

IBMの"Computational Scaling"マスクによる22nmプロセスロードマップのプレスリリースす。
http://www-03.ibm.com/press/us/en/pressrelease/25147.wss
解説わ、この辺の記事が良いす。
http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=210602297
http://www.semiconductor.net/article/CA6597205.html
要するに22nm以降のリソグラフィでEUV実用化の目処が立たないという認識の上で、数値解析で
解像度補正を行うということす。
ちと面白いのわ、Blue GeneやCELL/B.E.を使ったスーパーコンピューティングの応用であることも
強調していて、この技術で競合相手に差がつけられるならプロセスと製品の両面で大きな優位を
示すことができるという点だと思われるす。
(semiconductor.net記事より)
　　------------------------
　　Computational scaling (CS) uses complex algorithms to modify mask shapes and to control
　　the illumination source. IBM, working with Mentor, also expects to develop design hardware
　　based on its Cell processor to keep the time required to simulate mask optimization to
　　overnight runs. And the CS initiative links to IBM’s Cloud Computing strategy, which offers
　　scalable, web-based computing services.

　　IBM said the CS solution is an ecosystem that includes SMO, virtual silicon processing with
　　TCAD tools and predictive process modeling based on IBM’s Blue Gene supercomputer,
　　design-rule generation and corresponding models, design tooling, design enablement, complex
　　illumination, variance control, and mask fabrication.
　　------------------------

　　

>>684
メモリコンシステンシーモデルは実装に依存しない

モデルの選択がまずあって、それを満たすようにプロセッサを実装する

君の主張は順序が逆なんだよ

ふつうは靴を買うときには足にあったものを買う

君は、靴がピッタリあうのは、足を靴にあわせたからだと考えている

>>678
ちょっと待てよ、いくら何でも変なこと書いてるぞ。
共有メモリをアクセスするときは占有できるように同期を取って
アクセスして用が済んだらリリースだろ
その同期を取るためのメモリアクセスをSC内で維持したいというならまだ分かるが

>>688
デ(略)でも、producer-consumerタイプの通信でも、アトミックなメモリ操作は不要だよね？

>>687 >>610
勝手に相手の主張を作って反論するのはやめよう！

そもそもここでは、fenceの実行サイクルの見え方の話しかしてないし、
投機もインオーダーもキャッシュもそれに影響を与える可能性がある、
で結論は出てるよな？

君のいう「関係ない」は多分「投機やキャッシュやインオーダーといった
実装要件単独ではメモリモデルは決定しない」ってことなんでしょ？
誰もそれにはけち付けてないよ。

>>690
> そもそもここでは、fenceの実行サイクルの見え方の話しかしてないし、

んなこたぁない
君も団子もAtomのlfenceはnopだと主張している

それは正しいかもしれないが、正しいと保証はできない

>>690
わかってもらえなくて悲しい

> 君のいう「関係ない」は多分「投機やキャッシュやインオーダーといった
> 実装要件単独ではメモリモデルは決定しない」ってことなんでしょ？

実装はモデルを決定しない
モデルにあわせて実装を決める

内部ﾛｯｸが効かないｸｿarchのSIMDロードではfenceが要る
なんておちだったら、ｵｼﾞｻﾝ怒るぞｗ

>>691
lfenceのAtomパイプラインにおける動作がnopというのは妥当な実装だと
思う、というのが俺の考え。

それでオッケーな例も示したし、何か問題があるか？

lfenceは2命令を「並列実行」できるんだぜ
それどこかろかロード命令とペアリングできる。
内部NOPでないとして何なんだね。

>>694
ありまくり

> lfenceのAtomパイプラインにおける動作がnopというのは妥当な実装だと 思う、

妥当ではあっても、何の保証にもならない

時価で寿司を食って、店の評判や材料から考えて数万円くらいと推測するのは妥当かもしれないが、
10万円取られないという保証はなにもないのと同じ

NOPと区別されてるかどうかは知る由もないが、なんのブロックもやってないことは確かだな。

>>696
えーっとさ、「妥当な実装だと思う」という主張に対する反論は、「それで
は決してうまくいかない」ということを証明することでしかできないんじゃ
ないか？

「妥当な実装だと思う」->「何の保証にもならないからお前はバカ」って
日本語のやり取りとしてどうかと思うぞ。

どうも団子の検証にも説得力がありそうだし、誰も「保証」してないけど、
ひとまずの結論ってことでいいんじゃないの？

>>698
少なくとも>>534の例は間違っている

そして君らは、妥当であることと証明された正しさの区別も怪しい
モデルと実装の区別もついていない

> 誰も「保証」してないけど、

団子はAtomのlfenceはnop以外ありえないと力説していますが…

団子については、
いろいろ調べたり測ったりしたところ、Atomのlfenceはほとんどnopのようだ、
という言うのであれば、ケチのつけようもないが
勇み足でlfence==nopだと言い出すからおかしくなるのだ

ハードワイヤードロジックだから効果が変わることもあり得ない。
でも、そもそもロードの順序保証がされないことで起こる問題って何なんだ？

他のスレッドがロックなしで共有メモリをアクセス云々は論外な。
もともとアトミックでないメモリ操作には保証をしないことになっている。

>>700
別にダンゴの肩持つ訳じゃないが
そもそも反論するなら最初から論拠を示すべきでは？
さもなくば今さらそんなこと書いて何なのよ
後出しじゃんけんダンゴ以下の卑怯者
論拠も示さず他人を罵倒が研究者の仕事かよ

パイプラインを止める以外に副作用のない命令からパイプラインを止める効果をとったらなにが残ると思う？

NOP＝なにもやらない

>>699
しつこいなぁ、loadのオーダーを保障しなければいけないケースの一例
(それも典型的な)であることは間違いないでしょ？

でもって、分岐の先を投機的に実行するかしないかがモデル実装のポイント
になる場合が存在することも示したよな？

暗黙のうちに想定していた実装に関する言及が、>>534に含まれていない
ことは俺の手落ちだ、すまんかった。

これでいいか？

> 団子はAtomのlfenceはnop以外ありえないと力説していますが…

そんなこた人それぞれだ、俺は団子が持っている情報を全部持っている
わけではないから、彼と同じ確信を共有することはできないが、彼が
ここに提示した情報は、こういうところではなかなか見られない良質
な情報だったと思っている。

いいけどさ「お前はバカだ」を証明しようとして議論することほど空しい
ことはないぞ。

>>704
> そんなこた人それぞれだ、俺は団子が持っている情報を全部持っている
> わけではないから、彼と同じ確信を共有することはできないが、彼が
> ここに提示した情報は、こういうところではなかなか見られない良質
> な情報だったと思っている。

だったら黙ってROMってろ

つーか実験すらやろうとしない憶測でしか語らない自称科学者は
なにやって論文提出するんだ？科研費通るのか？

憶測をまとめただけの文章などおバカアイドルのブログと変わらん

はー、やっぱダンゴも好きになれねぇ
コンピュータ好きで頑張り屋なところは認めるが…

>>702
団子の相手は最小限にしたいんでね
まあ、>>577-578, >>585あたりをちゃんと読んでくれよ

>>704
> しつこいなぁ、loadのオーダーを保障しなければいけないケースの一例
> (それも典型的な)であることは間違いないでしょ？

間違いというか、ロードの順序以前に、依存関係があるつの
だから例としては不適切

非実験系の学科目あるいは講座に配分される校費は文部省時代の国立大学の配分でも最低クラス。

実験のできない理系学者が落ちこぼれなのは事実です。

>>708
これ以上は繰り返しだな、ナイスなタイミングでID:Uwkau9GXが冷水を
かけてくれたし、俺はROMにもどるわ。

スレ汚しすまソ

「LarrabeeはSSEをサポートしない」の珍説は断定してかかる側だったのに

今じゃ断定することに異を唱える立場
腑抜けになったもんよ

己のバカさ加減を自覚せざるを得なくなったか？

フェンスに強制完了(笑)させられた論客の末路は哀れなもんよ

larrabee(笑)

科学者くん、
lfenceを使わないことで起こる問題を答えてくれよ

movntなロード命令はSSE4.1にしかないぞ

電波が足りないぞ

もっとフェンスに強制完了させられてくれよ

いい子だから、もうｸﾞｯｽﾘお休み

が、しかーし、fenceなんて入れなきゃﾅﾗﾝのは投機的な無理してるんか
そして、SIMDもあのちっちゃなちっちゃなコアに…

依存があるものを無理とアクセスするときのためのしょうがないもの
ってやつか、まぁいいや、

ﾒﾆｺｱの流行は10数年程前の並列化への移行期のﾃﾞｼﾞｬﾋﾞｭみたいで
なんだか、またかというか…

それもｺﾚも2年ほど前にインテルが変な80コア発表して猫も杓子も…
そういやあの登記的命令がタイミングずれてずっこけたときのペナルティーはfenceよりもすごかった
ながながしたパイプライン全てパーにして一からロードし直してたｗ

>>816
それがARM(+DSP)に対する強みだよ。

SSEはソフト開発者にもっとも普及したDSP拡張命令セットだからな。
スカラとSIMDをシームレスに使い分けられる。

将来的にはAVXみたいなより高機能なSIMD拡張がAtomにも載る。


ちなみにあのブロックダイアグラムにもいろいろ間違いがあるな。
SIMDは片方にしかぶら下がってないように描かれてるが現実には2命令同時発行できる

まぁな、基本、依存無しのデータストリームにたいしてロックや同期なしに
深くパイプライン効かす効率重視だろ、んなこた我カットる

ところで、ATOMってどれくらいまで命令スロット詰められるものなの？
うまくアセンブリでハンドコーディングすれば、毎サイクル2命令実行
に近づけるのか、それとも、どこかでハザード要因にぶつかってあきら
めなければいけなくなるのか。

結局x86搭載機しか使ったことないな。

いつぞの資料によれば、Fast PathとSlow Pathってのがあって、

・Fast Pathはハードワイヤードロジック×2で2命令
・Slow Pathはマイクロコードで3サイクルかけてもっさりデコード

まず初動はSlow Pathでデコード。で、デコードできたもののうち、Fast Pathで通せるものについては
タグをつけて次からはFast Pathで走れるようにする。
よくわからんがプリデコードキャッシュ？みたいな仕組みがあるようだ。
複数マイクロオペレーションかかる命令は常にSlow Path。

で、
・デコーダ0(＝Complex Decoder)
　マイクロコード(Slow Path)
　XLAT/FL(Fast Path)

・デコーダ1(＝Simple Decoder)
　XLAT/FL(Fast Path)

と対応づければプリデコードキャッシュ？の仕組み以外は今のCore 2の2種類のデコーダ
（Complex×1, Simple×3だが）の関係とそうそう変わらないような気がする。

レジスタリネーミングも利かないし、XLAT/FLも非対称ではないかと思われる。
まあ性能を限界まで引き出すにはP5時代よろしくペアリング最適化が必要だろうな。

あと、命令フェッチ帯域の制約がかなりきつくて、8バイト/clkしかフェッチできない。

でだ、
addps xmm1, [eax+ecx*8 + 0x12345678]

なんてやると
0F+58+ModRM+SIB+DISP32

で8バイト全部使っちゃうから1命令しか供給できない。
Core 2と同じくDispを1バイト版に圧縮する努力が必要になるな。

ちなみにSIMD命令の命令長は

最短3バイト(MMXおよびSSE単精度パックド)
0F Op ModRM

最長11バイト（SSSE3以降；　64ビットならREXを入れて12バイト）
66 (REX) 0F 3A Op ModRM SIB Disp32 Imm8


でもAtomの将来バージョンにはAVXが載ることになってて

最短4バイト
VEX(2byte) Op ModRM

最長11バイト（REXの機能はVEXに内包）
VEX(3byte) Op ModRM SIB Disp32 Imm8

最短が増えてるが、しかしソースオペランド数が増えてるので実質的には命令帯域の節約になる。
更にVEX.256フラグを立てれば同じ命令長で、同じオペレーション2回分の128bit SIMDを表現できる。
（SIMD演算器が256ビットでなくともメリットを享受できる）

>>685
HPCが強いほど、HPCは強くなると。Nvidiaもやりゃいいと思うけど、ファブレスだし難しいか。
東芝もやればいいのに。

>>726
64モードでうっかり32レジスタでアドレス指定しようものなら更に+1で13バイトか。

>>727
Cellには参加してるけど東芝ってコンピューティング強いか？

パソピア馬鹿にすんな！

>>728
IBMにくらべりゃ、勝てないだろうけど、Cellの蓄積はあるから、独自に応用できるんじゃ？
まあ、連合だからIBMの成果を待っているほうがいいのかもしれないが。

まあ、そもそも、シミュレーションでどれだけ有用な結果が得られるかが？だから、
IBMみたいなとこじゃないと博打に手をだせない？

MIPSコアのSoC製品をHPC市場に売り込んでいるSciCortexすけど、TSMCの90nmプロセスで
製造しているチップの歩留まりが上がったとかで、500MHz -> 700MHzに高速化した製品を
出すとのことす。メモリ価格の下落等もあって、値段も下がるとか。
http://www.theregister.co.uk/2008/09/19/sicortex_kicker/
　　--------------------------
　　According to Kem Stewart, vice president of hardware engineering at SiCortex, improved
　　yields at partner Taiwan Semiconductor Manufacturing Corp using its 90 nanometer
　　processes against the SoC part created by SiCortex have allowed the company to boost
　　the clock speed on the six cores per chip to 700 MHz, a boost of 40 per cent.
　　--------------------------
ファンドリ企業のプロセスの進歩わ、こういったアーキテクチャ勝負の企業の活躍につながるという
意味で、大いに楽しみす。

今やx86のようなCISC由来のアーキより低クロックの泡沫RISCに「アーキテクチャとしての優位性」なんてあったのか？
4バイト固定長なんて今日日はやらないんだよ。
1チップ数百円以内の組み込みはもはや2バイト命令のSuperHやThumb命令セットを備えるARMの市場。
HPCもx86が絶好調勢力拡大中。

もはやMIPSは落ち目

というより、全盛時代すら高クロック実装は本家ではなくNECに頼ってた
RISCとしてはｱｲﾀﾀﾀなアーキテクチャだった気がする。