【隔離】P4アーキテクチャについて議論する【スレ】

ここは NetBurst アーキテクチャを語りすぎて
「P4-PCやXeon-PCてPMG4より速いんですか？その6」
http://pc.2ch.net/test/read.cgi/mac/1032957357/
を追い出された人(Solaris使いとMACオタさん)が議論を続けるスレです。
議論の展開は 675-767 をお読みください。

別スレじゃなくて別板でやってくれ。
ハードウェア板とかな。
この時点でMacとは離れてるわけだし

これまで出た論点
・ハイパーパイプラインと命令並列度の関係について
・キャッシュラインのサイズを大きくする(16→64バイト)とプリフェッチ
・ストライド付き転送命令の有効性（議論中 SIMDプリフェッチ命令と呼んでいる)
・キャッシュの連想度は何に起因してきまるのか？

板違い。去れ！

自治をせねばならぬとき！
コリンさん出番ですよ！

どんどんやっちゃってください。

削除依頼出してくれ

NetBurstの関連リンクもおねがいします。
っていうかかなり解りやすい板違いすね。

前スレを見ると分かって貰えると思うけど、NetBurst アーキテクチャを
議論することによって、POWER4 & GPUL を理解しようというのが趣旨です。
でも目立つのでもう少し下がってから開始します。

＞POWER4 & GPUL を理解しようというのが趣旨です。
だったら尚更板違い。
Macとかけ離れてしまったんだもんね。
ハードウェア板でやっても何の問題は無いだろう。

＞追い出された人(Solaris使いとMACオタさん)が議論を続けるスレです。
私的利用ならメッセンジャーでチャットでもしろよ。

削除対象だな。

>>9
その趣向を1に明記しておけばよかったのに、と思います。
で、タイトルはGPULとP4云々、にしとけば。
GPULの正体の一部？がもうすぐIBMから明らかにされる訳で、
それも交えながら楽しく電波発信できたんでは。

http://otakiller.virtualave.net/
こっちでやれ、誰の迷惑にもならん。

＞GPULの正体の一部？がもうすぐIBMから明らかにされる訳で、
それでも板違いだよ。

通報しますた

じゃあ、8vBos9Td さんに敬意を表して MAC に関係する AltiVec に関する議論から再開しましょう。
ぜひとも 8vBos9Td さんも答えてください。

問題点：
「AltiVec の dst 命令のようなストライド付きブロックプリフェッチ命令は有効か」

私の論点。
「キャッシュを前提としてレイテンシが大きくスループットが十分でない、RISC
プロセッサ上に実装するには高価すぎる命令。
プログラマに利便性をもたらす命令だが、優れたプリフェッチ命令とは言い難い」

MAC オタさんは、元スレの 733 で
> あなたが書いているロングベクトルのプロセッサの話と思われるす。
> PC用のショートベクトルのSIMDとわ共通の点と、異なる点があって
> あたりまえすけど。。。
ベクトル機の場合、メインメモリが SRAM ベースなのでアクセスレイテンシが小さく複数ブロックの転送を行ってもレイテンシの増加が少ないのです。
一方、RISC ベースのプロセッサは SDRAM ベースです。連続したデータ転送は速いのですがアクセスレイテンシが高いため、ブロック毎にペナルティをもらいます。1回の dst で長い場合は、数千サイクルを要するという状態になりませんか？
無論、dst 命令は実際のデータ転送を行う前にリタイアしてVTQ というキューに繋がりますから、パイプラインに負担は係りません。ただ、この長時間の転送を中断させるために、転送を停止する命令まで用意されているのを見ると処理が複雑すぎると思います。

> PC用のSIMDわ、現在のPC 用プロセッサの状況に合わせてつくられているのでわないすか？
> AltiVecわその中で最も優れているという評価わ一般的なものだと思うすけど。
> http://www.arstechnica.com/cpu/1q00/simd/simd-1.html
演算部分に関してはそうかもしれませんが、dst のような命令は PC 向けというよりは数値計算向けです。
ただ、本当に数値演算アプリを書くならストライド付きブロックプリフェッチ命令よりも、ストライド付きプリロード命令が欲しいのです。

議論：キャッシュラインの変更(元の議論では 16→64バイトの変更)とプリフェッチのどちらが有効か

MAC オタさんは元スレの 767 で
> ここで書いているプリフェッチわハードウェアによる実装も含むす。

ここまでずっとマルチワードキャッシュライン v.s プリフェッチ命令
(ソフトウェアプリフェッチ)の話をしていたと信じていたのですが。。。

元スレの 730 で MACオタさんが書いたように、マルチワード
キャッシュラインはハードウェアプリフェッチの1種です。
> 64byte/line = 32byte/line × 2 hardware prefetch
ただ 現在の一般に hardware prefetch と呼ばれる機構は、シーケンシャル
アクセスパターン/ストライドアクセスパターンを読んで、次のアクセスに
備えるようなタイプです。
そのため ある程度データに幅のあるストリームデータがターゲットになり、
ランダムアクセスのプリフェッチには逆効果だと思われます。

> マルチプロセスやTLP (Thread Level Paralellism)わ現代のプロセッサの
> 重要なテーマすから，タスクの種類や数に合わせてメモリアクセスを調整
> するという概念わ，今後実装されてくると思うすよ。
> 実際にPowerPCのBook E規格でわPIDレジスタという，プロセス番号をプロ
> セッサ内部で管理するレジスタが規定されているすけど，たぶんOSと強調
> してプロセス単位でプロセッサの挙動を調整するために使うんじゃないかと
> おもわれるす。
この内容には同意します。
一応、書いておくと、研究レベルではラインサイズや連想度を動的に変更
可能なアーキなんかが提案されています。

http://kasuga.csce.kyushu-u.ac.jp/~lsi-fab/CHIP/CD97-05.html
http://ne.nikkeibp.co.jp/award/papers/2002_univ19.pdf

後の pdf にはキャッシュの消費電力に関する考察もあります。

MACオタさんは元スレの 747 で、
> 命令の並列度抽出わ P4のようなアーキテクチャより、もっと大規模なスーパースカラプロ
> セッサでの問題すから。

私は元スレの 753 で、
> ご冗談でしょうファインマンさん。
> P4 はスーパースカラープロセッサの中でもっと大規模な部類に入ります。

MACオタさんは元すれの 753 で
> ファインマンさんわ正しかったのでわ？(笑)
> IU x 3, FPU(&SIMD) x 1, LSU x 2というP4わ，Athlon (IU x 3, FPU x 2,
> LSU x 4)やG4+ (IU x 4, FPU x 1, SIMD x 4, LSU x 1)と比べても少ないす。
> 並列度よりクロックを優先した普通のスーパーパイプライン構成だと思われるす。

P4 は IU 2(速)+1(遅)、FPU x2(ただし非対称)、LD x1、ST x1 です。
ただし IU (速い方)は 2 倍の速度で動作しているため、単純な整数演算は1/2
サイクルで動きます。これは仮想的に IU を増やす効果があります。
だから、実質的な整数ユニットは少なくない。FP が少ないのは確かですけどね。

747 でMAC オタさんが触れている POWER4 は、FX(IU) x2、LSU x2、FP x4(2+2)、
BR x1、CR(フラグ計算)x1 で、こちらの方が少ない気がするのですが。
しかも IU のレイテンシは 2 サイクル以上ですし、、、

>>16
そもそもRISCやショートベクトル機のプリフェッチ命令わメモリのレイテンシを隠ぺい
する程度のもので，ロングベクトル機のようにパイプラインそのものの一部でわ無いす。
ハードウェアの複雑さわ，AltiVecユニット全体でせいぜい4百万トランジスタ，面積に
して10mm.sq@180nmくらいすから現在の半導体プロセスでわ，もはや問題にならないす。

プリフェッチわメモリ-プロセッサ間とプロセッサ内部の速度差を埋めるものす。プロ
セッサ内部が十分高速な現在，プリロードでレジスタ迄送る必要わ無いし，マルチプロセス
環境でわむしろ有害す。
プリフェッチの有効性わ，むしろコアとBIU (Bus Interface Unit)の並列動作にあると
見るべきすね。

>>17
POWER4の実行ユニットわ，同時命令ディスパッチ数を上げるためにかなり工夫
したと考えられるす。IU，FPU, LSUを全て同機能のもので揃えたことわ注目
すべきじゃないすかね。
実際上，IUのSlowとFastとか，x86 FPUとSSEが同時使用されることわ無いすから。

なお，POWER4のIUのレイテンシわ1クロックす。ただし，結果をすぐにフィード
フォワードできないので依存命令わ1クロック待たされるす。詳しくわこちら。
http://groups.google.co.jp/groups?scoring=d&q=%22POWER4+integer+ALU+latencies%22+group%3Acomp.arch

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃○　　　　　　　　　　　　　　　　　　　　　　　　　　　　○┃
┃　　　　　　　　　　　　ハなイ　　　　　こ　　　　　　ま　　┃
┃　　マ　　　　　　　ボ　｜らン　　　　　こ　　　　　　　　　┃
┃　　ッ　　　　　　　ケ　ド?Aテ　　　　　は　　　　　　と　　┃
┃　　ク　　　　　　　?A　板Ｗル　　　　　マ　　　　　　　　　┃
┃　　は　　　　　　　カ　でｉ等　　　　　ッ　　　　　　め　　┃
┃　　愛　　　　　　　ス　やｎの　　　　　ク　　　　　　　　　┃
┃　　だ　　　　　　　?A　れか話　　　　　板　　　　　　よ　　┃
┃　　！　　　　　　　ク　　　　　　　　　?B　　　　　　　　　┃
┃　　　　　　　　　　ズ　　　　　　　　　　　　　　　　う　　┃
┃○　　　　　　　　　　　　　　　　　　　　　　　　　　　　○┃
┗━┳━━━━━━━━━━━━━━━━━━━━━━━━━━┳━┛

>>20
対抗する技術の間の進歩と言うものわ蛙飛びに進むものす。
お互いに相手の現世代での特長を次世代で取り込み，逆に欠点も一緒に
抱え込んだりするものす。

最後通告します

ここはMac板なのでハードウェアに関することはハードウェア板でやるように

MACオタとSolaris使い さんは出て行くように

以上

「ここはMac板なのでハードウェアに関することはハードウェア板でやるように」
って、表現が曖昧過ぎるというか、間違ってると思うんだけど。
ここはソフトウェアに限った議論しか出来ない板では無いですよね？

パーツに関する議論をするならより相応しい板があるでしょ、と言いたいのだろうか？

>対抗する技術の間の進歩と言うものわ蛙飛びに進むものす。
>お互いに相手の現世代での特長を次世代で取り込み，逆に欠点も一緒に抱え込んだりするものす。

この板で議論する理由になっていません。
削除対象なので出ていって下さい。

ここはMac板なので
実際にMacで使われていない
または使えないハードウェアに関することは

ハードウェア板でやるように。

>>25
禿同

＞23
MacにPower4が採用されたらっていう所まではよかったが
Power4自体に関する議論になりMacとは関係なくなっている。
無理矢理Altivec関連の話題を出してるが
本筋はPower4の話をしたいだけだろ。

ハードウェア板に逝くべきだよ。
その方が議論も有意義になると思う。

>>25
激しく同意

ロイターが、IBM社から発表される予定の64bitPowerPCプロセッサーに
関して伝えていました。そのプロセッサー名は「PowerPC 970」と呼ば
れ、32-bit アプリケーションも動かすことが可能(Book Eアーキテク
チャーと予想される)で、来年後半に1.8GHzで生産開始されるようです。

遅いなあ....

スレ違い、逝け！

ここはMac板なので
実際にMacで使われていない
または使えないハードウェアに関することは

ハードウェア板でやるように。

ここはMac板なので
実際にMacで使われていない
または使えないハードウェアに関することは

ハードウェア板でやるように

ここはMac板なので
実際にMacで使われていない
または使えないハードウェアに関することは
ハードウェア板でやるように。

ここはMac板なので
実際にMacで使われていない
または使えないハードウェアに関することは
ハードウェア板でやるように

>>27
うん、そういう指摘なら良いと思うんだけどね。
「ここはMac板なのでハードウェアに関することはハードウェア板でやるように」
ってのは違うだろと言いたかった。

実際んとこ、適切な板でやった方が参加者が増えて、よりよい議論が出来そうですよね。

IBMは、新しいパワーPC 970マイクロチップがそのPower4チップ(その洗練
されたコンピューター・サーバー、コード名をつけられた「レガッタ・
レース」に昨秋それはそれを送り出した)の「ライト」バージョンである
と言いました。

関係有るだろう。

>36
Mac で使われるなんて一言も書いてないけど ? ?

ところでP4やGPULのアーキテクチャ？に関する議論をするのに最適な板ってどこでしょう？
詳しい人の一番多そうな板。
ハードウェア板という所がそうなんでしょうか？

>>38
MACオタはどこの板に持ち出しても嫌がられると思われ。
ここが一番ふさわしい。

MACオタは他板でも嫌がられるかもしれないが
だからと言って板違いスレッドを存続させるわけにはいかないだろう？
よく考えてから発言してくれよ

先にこちらをコメントします。
一応断り書きを。17 で P4 と書いているのは、Pentium4 です。

>>19
> POWER4の実行ユニットわ，同時命令ディスパッチ数を上げるためにかなり工夫
> したと考えられるす。IU，FPU, LSUを全て同機能のもので揃えたことわ注目
> すべきじゃないすかね。
MAC オタさんはおそらく演算器のクラスタ化(MACオタさんの言い方で言えば VLIW 化?)を念頭において、
それぞれのクラスタに機能ユニットが一式入ることの利点を指摘したいのだと思いますが違いますか？
(一応、言っておくと POWER4 の FPU は 4個ですが、2種x 2個 で 4個です。)

> 実際上，IUのSlowとFastとか，x86 FPUとSSEが同時使用されることわ無いすから。
IU の Slow と Fast は同時実行されることは多いですよ。
Slow 側の IU は shift/rotate/multiply/divied で使います。rotate はまず使いませんが、それ以外は結構でてきます。
Fast と Slow には 4 : 1 の(実質的な)ユニット数の差があり、Slow で処理する命令は 4 サイクル以上かかるようなレイテンシの大きなものなのですから。
x86 FPU と SSE は同時使用され頻度は低いので、同じユニットで処理していますね。

Pentium4 も内部はクラスタ化されています。HT をやるから当たり前なんですけど。

>http://ime.nu/groups.google.co.jp/groups?scoring=d&q=%22POWER4+integer+ALU+latencies%22+group%3Acomp.arch
MAC オタさんの挙げた comp.arch の投稿って、IBM の POWER 開発者が答えているのですね。
POWER4 の IU が依存がなければ 1 サイクルというのは了解。
ただ IU 部が 2-way のスーパースカラーなので、すでに命令レベル並列性を使ってしまっていて、前後するサイクルに依存性がない命令を並べるのは難しいでしょうね。
(もし、それができるのであれば IU を増やす方向に行くでしょうし。)

余談としては、comp.arch の人たちが何故 Alpha の話を始めてしまうかというと、スーパースカラープロセッサの(CPU 内演算器の)グループ化(or クラスタ化)を始めたのが DEC が最初だったからです。
Alpha 21264 は 2つの演算器群をクラスタ化したばかりか、それぞれのクラスタ用にレジスタファイルを持っています。
同じ物理レジスタが 2 個あるのは、レジスタの outputstanding を実質的に上げるためと、レジスタ<->演算器の距離の縮めるため(2枚のレジスタはミラーリングをやりながら同期をとります)。
クラスタへの命令の割り付けはコンパイラの仕事で、21264 は 4命令を同時にフェッチし、奇数番を右クラスタ、偶数番を左クラスタに割り付けつけます(逆かもしれない)。

21264 をクラスタ境界できってやれば自然と SMT になります。
前に書いたけど、Pentium4 はこの構成を踏襲しています。

「板違い」なんて珍しいことでもないし、普段は全く騒いでないのに
なんでこのスレだけ必死なんすか？（笑

★☆★☆★☆　　スレ乱立警報　　★☆★☆★☆

　このスレッドは突然終了するおそれがあります。
　こちらへ移動してください。

[統一] 次世代MacのCPUを語ろう
http://pc.2ch.net/test/read.cgi/mac/1034223390/l50

>>41
今のところCMPわ考えていないすから，ちょっと違うす。
POWER3/4わLSUが2組あるのを見ても判るように，スーパースカラ構造でマルチサイクル
の命令をどんどんディスパッチしていくという方針す。逆にシングルサイクルで大半の
処理が終わるIUわ他のプロセッサと比べても多くないのも，全実行ユニットを極力
並列で動かすという方針からだと思われるす。

統一スレからはみ出してた板違いな話題だから別板でやれっていったのに

演算ユニットの数をスーパースカラの単位のように書いた私が悪いすけど，
dispatch, issue, executeの並列性わ分けて考えた方がよいかもしれないすね。

★☆★☆★☆　　スレ乱立警報　　★☆★☆★☆

　このスレッドは突然終了するおそれがあります。
　こちらへ移動してください。

　ハードウエア板

━━━━━━━━━━━━ 終了 ━━━━━━━━━━━━

>MACオタ
板違いっていってるだろ！
都合の悪いことは無視しないで下さい。
★☆★☆★☆　　スレ乱立警報　　★☆★☆★☆

　このスレッドは突然終了するおそれがあります。
　こちらへ移動してください。

　ハードウエア板

━━━━━━━━━━━━ 終了 ━━━━━━━━━━━━

>>49
別にいいじゃねーか。文句いうならもっとほかのスレがあるだろ。
2P2の隔離スレとかさ。

なーんか、腹たってきた。
Macはハードウエアじゃないのか？

ここはMac板なので
実際にMacで使われていない
または使えないハードウェアに関することは
ハードウェア板でやるように。

>>45
> 今のところCMPわ考えていないすから，ちょっと違うす。
CMP(Chip-On-Multi) ？
私は単に演算器のクラスタ化(依存関係を極力切る複数のパイプライン)の話をしています。
その先に SMT があります。

あと、この話は元スレ 747 での MACオタさんの
> 具体的なP4の実装についてわその通りす。命令の並列度抽出わ
> P4のようなアーキテクチャより、もっと大規模なスーパースカラプロ
> セッサでの問題すから。
が契機になっていますから、Pentium4 との比較だけで充分だと思います。
Pentium4 も演算器のレイテンシは単純な演算では 1 サイクルです。
(依存がある場合にレイテンシが伸びるという話は、まだ見聞きしていない)
あと、Pentium4 は演算器のクラスタ化も行っています(SMT をやるためでもある)。

>>53
じゃ，POWER4のFPUが4つというのわ どういう意味すか？2つしか無いすけど。。。

53 は 17&41 ですね。

失礼。「IBM ＠ server POWER4 System Microarchitecture」
http://www.ibm.com/servers/eserver/pseries/hardware/whitepapers/power4.pdf
の
"Two identical floating-point execution units, each capable of starting a fused multiply and add each cycle, i.e., a maximum 4 floating-point
operations (FLOPs) per cycle per core, are provided."
を読んで演算器は 2 つだが、最大2命令分発効できるキャパがあると
勘違いしていました。
POWER4 の FPU が 4 つだという点は訂正します。

>>53
並列度についてわPentium 4わ6命令/clock, POWER4わ8命令/clockで
実行ユニットにissueできるようになっているす。大きな差だと思うす。

>>42
このAlphaの実行ユニットのクラスタリングの話すけど，Pentium4の場合
http://www.intel.co.jp/jp/developer/technology/itj/2002/volume06issue01/art01_hyper/p04_implementation.htm
のように，各キューにパーティションが設けられているだけで，実行ユニット
をグループに分けているようにわ見えないす。
CRISC自体が本質的にCISC命令をμOPのグループに分けていると言われれば
その通りだと思うすけど。。。

>>18
> そもそもRISCやショートベクトル機のプリフェッチ命令わメモリのレイテンシを隠ぺい
> する程度のもので，ロングベクトル機のようにパイプラインそのものの一部でわ無いす。
> ハードウェアの複雑さわ，AltiVecユニット全体でせいぜい4百万トランジスタ，面積に
> して10mm.sq@180nmくらいすから現在の半導体プロセスでわ，もはや問題にならないす。
プロセスルールやトランジスタ数だけで決まる問題ではないです。
でも、MACオタさんがそう考えているというのなら、現在の参照資料だけで このまま議論しても平行線をたどるだけですね。
もう少しちゃんとした資料をもってきます。キャッシュの way 数に関するものも含めて。

> プリフェッチわメモリ-プロセッサ間とプロセッサ内部の速度差を埋めるものす。
> プロセッサ内部が十分高速な現在，プリロードでレジスタ迄送る必要わ無いし，
> マルチプロセス環境でわむしろ有害す。
私の立場の確認ですが、
2,4,8ライン数で連続したキャッシュラインを読みこんで来るようなプリフェッチ命令を問題にしているのではないです。
ストライドを付けて複数ブロックを読みこむマイクロアーテキクチャの立場に立てば「優秀なプリフェッチ命令の例(元スレの690)」とは言えないだろうという立場です。

プリロード命令に関しては説明不足だったかも知れません。
私が意図していたのは従来型のレジスタに転送するタイプのものではなく、
元スレの 707 で挙げたような scrratch pad に対するプリロードや、
あるいは IA-64 のスタック汎用レジスタのバッキングストア動作のようなものを想定しています。

あと、マルチプロセス環境の問題は当然考えています。
ですから、私は数値計算アプリと条件を付けています。
分かってもらえると思うのですが HPC アプリのことです。

> プリフェッチの有効性わ，むしろコアとBIU (Bus Interface Unit)の並列動作にあると
> 見るべきすね。
プリフェッチ一般に関してはそうです。

>>58
参照資料の方わよろしくお願いするす。

プリフェッチについてわ，あんまりストライドのことわ考えていないすよ。私の
頭でわpermuateと同様にデータ構造から処理したい命令をまとめて抽出する方法
と解釈されているす。むしろ最初の議論に戻って，
http://pc.2ch.net/test/read.cgi/mac/1032957357/689
のような，
　　-------------------------
　　米つきバッタ見たいに prefetch 命令を発効し続ける必要があるから。
　　-------------------------
という意見に対して，PowerPC/AltiVec流のやり方を説明しただけす。

>>58
http://pc.2ch.net/test/read.cgi/mac/1032957357/707
に関して言えば，「ソフトウェア」プリフェッチわデータ構造が判っているから
つかえるす。AltiVecの場合わトランジスタ数をケチるためにL1にscrratch pad
の機能を兼用させているだけだと思われるす。そのため，キャッシュ機能の方が
優先で"dst"命令によってデータがL1にあるかどうかわ「保証されない」ということ
になっているす。

>>58
商用プロセッサわHPC用途とマルチプロセス用途の両方をバランス良く満たすことが求め
られているす。HyperThreadingにしてもHPC用途で役に立つのわ，
http://www.intel.com/jp/developer/technology/itj/2002/volume06issue01/art03_specprecomp/p02_intro.htm
こういう話が実現されてからでわないすかね？

>>57
完全に等価なユニットが複数あるのは IU(Fast) しかなく、それ以外は共有せざる得ないので P4 で、
クラスタ化というとオーバーだったかもしれません。

スケジューラのアクティブキューの制約でもあるのですが、HT 時には同一スレッドの命令は
片側の IU(Fast) 割り当てるように、もう片方側はスケジューリングします(資料は検索中)。

いいたいことのまとめ。クラスタ化したパイプラインの中に流れる命令列を
・Alpha はコードのアドレスによって(コンパイラが生成)
・POWER4 は動的スケジューラが
・Pentium4 は HT によって
生成している。

> CRISC自体が本質的にCISC命令をμOPのグループに分けていると言われれば
> その通りだと思うすけど。。。
ここは良く分からないのですがどういう意味か説明ねがえませんか？

>>62
まず質問についてすけど，CRISCわ最初からx86命令がRISC命令の「グループ」であると
考えられて，この単位で命令の順序を管理すれば良いことが保証されているす。

POWER4のグループわdispatchとretireの順序を管理を単純にするために設けられて
いるとのことすから，こうした順序をCISC命令から抽出することわ意味があるかも
しれないという話す。

上手に固定長にならないすから，たわごとかもしれないすけどね。。。

>>62
アーキテクチャによるクラスタリングの違いの話すけど，
　・Alpha(のSMT)とPentium4：マルチスレッドで命令スロットを埋める
　・POWER4：シングルスレッドで命令スロットを埋める
と言う意味で，ちょっと違う気がするす。

>>61
Supeculative precomputation はスレッド投機実行の 1種です。
適用分野としては、むしろ HPC 以外の メモリアクセスが読みづらい
アプリをターゲットにしています。
HPC は、メモリアクセスが単純なお馬鹿な世界ですから、今のままでも
プリフェッチはちゃんとかけられます。

Hyper-threading が HPC に効きづらいのは、複数の仮想プロセッサ
エレメントが L1 や Load/Store ユニットを共有するために
メモリ<->レジスタのスループットが不足することです。

>>63
> CRISCわ最初からx86命令がRISC命令の「グループ」であると
> 考えられて，この単位で命令の順序を管理すれば良いことが保証されているす。
合点承知しました。

>>64
お忘れかもしれませんが、SMT 化を図った Alpha 21364 は陽の目をみることはなくなったので、
現行の Alpha チップはみなシングルスレッドを処理するプロセッサとなります。

>>65
それを言い出すとマルチスレッド／マルチプロセス自体がHPCでわ不要になるのでわ？
CMPのPOWER4もHPC用のp690-HPCでわ片側のコアを殺していたりするす。

AlphaについてわIU+LSUが固定した「組」になっているすね。申し訳ないことに
いままで詳細をしらなかったすけど，先ほど21264の資料で確認したす。

だいたいお互いの言い回しなんかが理解できて来たところだと思われるすけど，
最初の話わ，
　「NetBurstとHyperThreadingわメモリアクセスのレイテンシを隠ぺいできるか？」
で良いすよね？
http://pc.2ch.net/test/read.cgi/mac/1032957357/675
自体わデータ予測をのぞけば，同意できるす。
http://pc.2ch.net/test/read.cgi/mac/1032957357/676
のPenitum 4のアーキテクチャの解釈にわ異論があるということすけど。

>>59
元スレの 689 の私の発言「米つきバッタ見たいに prefetch 命令を発効し続ける
必要があるから。」の意図は、プログラマにとってコーディングがしづらいということです。
ここでは、プリフェッチ命令を発効することでの性能低下自体を勘案しておりません。
それはなぜかというと。。。

その前提として、MAC オタさんにお聞きしたいのですが、
現行の PowerMac G4 の実装では、dst が連続した複数のキャッシュラインを
フェッチしてくる場合に、1回のメモリバストランザクションで転送していますか？
例えば、4 ライン分を持ってくるなら、4回に分けて読みにいってませんか？

# 私は 元スレの 689 を書いた時点では、ミドルレンジ以下の RISC 系のシステムに
# マルチラインのプリフェッチ命令があっても後者のような実装しかせんだろうという
# 読みがあったのですが、、、

ここはMac板なので
実際にMacで使われていない
または使えないハードウェアに関することは
ハードウェア板でやるように。

>>66
> それを言い出すとマルチスレッド／マルチプロセス自体がHPCでわ不要になるのでわ？
> CMPのPOWER4もHPC用のp690-HPCでわ片側のコアを殺していたりするす。
マルチスレッドというのは SMT のことだと思うのですが、
マルチプロセスというのはマルチプロセッサ(CMP)のことですか？
そうだとして話を進めると、

CMP に関しては、p690-HPC(1CPU/1PE で 16PE)は ノーマル p690 の 16PE (1CPU/2PE で 16PE)
よりは速いけど、フル実装の p690 (1CPU/2PE で 32PE) よりは遅いですよ。
あと、同一プロセッサ内の PE が同じ仕事をすることによって、共有するデータが
増えるので、L2 / L3 を共有した CMP はまるっきり無駄というわけではないです。

SMT に関しては、性能は上がるけど上がり幅は小さいです。性能が落ちる要因もあります。
そもそも SMT は遊んでいる機能ユニットを有効活用させるのが主眼ですが、
HPC の世界はコンパイラががんばって機能ユニットを遊ばせない世界ですから、、、
＃ だから、みんな FORTRAN を使う。

>Alpha については...
マイクロアーキテクチャの世界では、
DEC は偉大な存在でした(過去形)。
研究者肌のエンジニアが多かったので、特許より論文を書くことに夢中で滅びてしまいました。
IBM はまだ巨大な存在です。新しいアーキテクチャを考案して、プロセッサも製造します。
Intel は MPC を最初に作ったけど、以降はただの製造者に落ち着いています。

>>67
> だいたいお互いの言い回しなんかが理解できて来たところだと思われるすけど，
> 最初の話わ，
>　「NetBurstとHyperThreadingわメモリアクセスのレイテンシを隠ぺいできるか？」
> で良いすよね？
基本的に OKです。
最初は、HT まで話を広げるつもりはなく、NetBurst の部分だけをやるつもりでした。

> http://pc.2ch.net/test/read.cgi/mac/1032957357/675
> 自体わデータ予測をのぞけば，同意できるす。
う〜ん。
675 はアーキ全般の話の抽象的な話しかしていないので同意していただきたい所です。

あと議論点がいくつか残っていますが、
できるだけ現実の実装に沿って議論して行きましょう。

ここはMac板なので
実際にMacで使われていない
または使えないハードウェアに関することは
ハードウェア板でやるように。

http://otakiller.virtualave.net/
もしくはこっちでやれ、誰の迷惑にもならん。

http://tmp.2ch.net/test/read.cgi/mog2/1034585649/

>>68
ご推察の通り，MPC7450 User Manualによれば，dst命令わハードウェア的にわ複数のdcbt
(32byteキャッシュラインアクセス命令)に分解されるとあるす。
ただし，split transactionでback-to-backアクセスが可能なバスで，これがどのように
問題になるのかわ私にわ判らないすけど？

>>69
しかしSPEC2000を稼ぐためにも，IBMわ片側のコアを殺した上，同じMCM上の
プロセッサからキャッシュをかき集めていたりするす。
Intelの研究部門に関してわ，大学発のベンチャーとして研究開発わ大学を支援する
というのがIntelの流儀だったすから，それほど貶すようなものでもないと思うす。
もっともそれが災いして，特許関係で不味いことになっているすけど。。。

http://corn.2ch.net/test/read.cgi/nanmin/1034586378/
http://tmp.2ch.net/test/read.cgi/mog2/1034585649/

上記２つのどちらかでやって下さい。

>>71
それでわ，まずキャッシュラインについてすけど
　・小さなキャシュラインわヒット率わ上がるが，消費電力やレイテンシの問題がある
というのわOKとして，このレイテンシわコア内部の話だと思っているす。
メモリバス上でわ，
　・大きなラインサイズわ無駄アクセスが発生する
　・しかし帯域が大きければレイテンシのみが問題になるので，読み書きのサイズわ
　　気にならない
ということなんすか？私わ後者わ疑わしいと思うすけど。特に
　・ヒット率が落ちることでメモリアクセスも増える
ということで，メモリアクセスに関してわ悪影響だと思うす。

先に1点だけ。
>>77
> ・小さなキャシュラインわヒット率わ上がるが,
これは私の主張ではありません。

>>78
普遍的事実でわ？違うのならヒット率が下がるとか，上がらないとかの根拠が欲しいす。

>>79
元スレの689 でも触れましたが 、
http://pc.2ch.net/test/read.cgi/mac/1032957357/689

ラインサイズを大きくすることは、キャッシュミス率を上げる要因も 下げる要因もある。
＃ ここではプリフェッチ命令を挿まないような普通のアプリを想定しています。
＃ また、マルチプロセッサを考えていません。

1ワード=4バイトとして、64バイト(16ワード)の構造体へのアクセスを考えてみてください。
ラインサイズ16バイトのデータなら 4回キャッシュミスが起こって、キャッシュミス率 1/4。
ラインサイズ64バイトのデータならキャッシュミスは最初の 1回で、キャッシュミス率 1/16。
これが上がる根拠。

下がる根拠は、コンパイラがキャッシュラインに揃えてデータを整形するので、
ラインサイズ中に使えない部分があり容量性のキャッシュミスが起きる可能性が増える。

プログラムのデータ構造との兼ね合いによって決まる最適値がある。
しかし、私は Pentium3 までの16バイトというのはやや小さすぎで最適値ではないと考えます。

また、同一キャッシュ容量なら消費電力やレイテンシは、キャッシュラインサイズよりも連想度(associativity) に受けると考えれます。
＃ 消費電力はともかくレイテンシのはすぐには納得いかないと思いますが、
＃ 指摘があれば説明します。

p.s.

MACオタさんは、683で「L3 タグ管理がサボれる」、717 で「ラインサイズの
拡大でトランジスタ数と時間わ節約できる」と言われました。
http://pc.2ch.net/test/read.cgi/mac/1032957357/683
http://pc.2ch.net/test/read.cgi/mac/1032957357/717
これを読んだときから、ちょと変に感じていたのですが、どのような理由によってトランジスタ数と時間が節約できるとお考えですか？
なんらかの想定が必要でしたら 32KB の程度のキャッシュが 16バイト→64バイトをご仮定ください。

> また、同一キャッシュ容量なら消費電力やレイテンシは、キャッシュラインサイズよりも連想度(associativity)
> に受けると考えれます。

また同一容量のキャッシュなら消費電力は、キャッシュラインサイズよりも連想度(associativity)
の影響を多く受けます。
またレイテンシについて考えると、L1 → レジスタであればラインサイズ
の影響を受けません。また、要求された語を先送りする early start の
ような技法を備えた実装も多いそうです（パタヘネ 7.2章より)。

板違いスレッドです。これ以上書き込まないで下さい。
Solaris使いさんも開き直らないで謝罪しる！

ここはMac板なので
実際にMacで使われていない
または使えないハードウェアに関することは
ハードウェア板でやるように。

>>80
キャッシュ容量が同じ場合，トランジスタ数が節約できる理由わ明白す。実例を書けば
PowerPC 750のL2のラインサイズわタグメモリのサイズが固定であるため，L2の容量
とともに次のように変わるす。
　　256KB/512KB: 64 Byte
　　1024KB: 128 Byte
すなわり1MBあたりのタグメモリわ128 byte/lineだと半分になっているす。

確かにレイテンシと消費電力わセットの数の方が重要すね。

板違いでも別にいいじゃん、くだらねぇ書き込みよりよっぽどおもろいよ。
それに謝罪ってなんでそこまで要求するかな。

MACオタとSolaris使い

こいつら、なんだ？CPUでも造ってる気になってるのか？
激しくくだらない知識ばら撒いてんじゃねーぞ！！オラー！！　(ﾉ｀A")ﾉ　┫：・’．：：

私的なことで板違いのスレたてをするな！

正直言ってどうでも良い話題ではあるよな（藁
創造や生産、娯楽にすらMacを使いこなせないからこう言う方面に話がいってるのかもな。
オタを見てるとそう思う。
無力なことを思い知れよ・・・哀れ・・・。

当然，公開の掲示板すから飛び入り参加わ歓迎するす。

>>89
そうやって味方を増やしてどうにか板違いを正当化しようという魂胆みえみえす。

３． 固定ハンドル（２ｃｈ内）に関して

叩きについて
　最悪板以外では全て削除します。

スレッド
　固定ハンドルが題名に入っている・固定ハンドルが占用している
・閉鎖的な使用法を目的としている
・等は、自己紹介板・最悪板・夢・独り言板
・おいらロビー・なんでもあり板以外では、
　原則として全て削除または移動対象にします。
　ただし、固定ハンドル個人が一群または二類に属する時は
　他の削除規定に触れない限り様子見となります。

はぁー、どうしてDECなくなっちゃたんだろ。
あれほど技術力のもった企業ってあんまりないよなぁ。
やっぱりミニコンに執着しすぎたのかなぁ、Unixを取りこむのも遅すぎたし。
最期のほうでAlphaなんてすばらしいプロセッサ出してくれたけど、やっぱり遅すぎたよなぁ。

# そういやハード、ソフトともにDECの技術を継いでるものって結構あるよなぁ。

おい。MACオタとSolaris使い

MacのG4が現在IntelのCPUに勝てないからって、次世代に逃げて
オナニーしてるんじゃないだろうな。そうだとしたらお前らセガ
信者となんら変わりねーぞ。セガは悲惨だったな（藁
とりあえず、メガビのお前のスレを嘲笑しておいてやるよ。
いつまで経ってもMACオタは進歩しねーな（藁
MACオタはバカを晒して楽しいかもしれんが見てるこっちは気持ち
わりぃんだよ。どっかいけ！

＞当然，公開の掲示板すから飛び入り参加わ歓迎するす。
君の掲示板ではありません。
板違いの話題はルールに反してますが？

>>92
最初のAlphaの登場が1992年すから，10年かけてもモノにならなかったとも言えるす。
結局わソフトの問題なんじゃないすかね。

>>92
オタさんｼﾞｴﾝたのしいすか？

>>95
わかりやすいｼﾞｴﾝですね。

板違いだ！下記スレッドへ逝け！
http://pc3.2ch.net/test/read.cgi/hard/1034592680/l50

【隔離】P4アーキテクチャについて議論する
1 ：不明なデバイスさん ：02/10/14 19:51 ID:h1zNFJxu
ここは板違いの話題のために新Mac板を追い出された
MACオタがPower4アーキテクチャについて議論するスレです。

スレッド立てるのがけしからんと言いながら，既に３つも他板にスレッド立てたのわ，如何なもんかと思うす(笑)
　ttp://corn.2ch.net/test/read.cgi/nanmin/1034586378/
　ttp://tmp.2ch.net/test/read.cgi/mog2/1034585649/
　ttp://pc3.2ch.net/test/read.cgi/hard/1034592680/

スレを立てるのが悪いなんて言ってませんが何か？
重複スレを立てるなって言ってるんだろ。

厨房のやったことをネタに煽るのは如何なもんかと思うす(笑)

ま、いいだろ？移転先が見つかったんだから
http://pc3.2ch.net/test/read.cgi/hard/1034592680/

>>96
漏れはオタさんじゃないですよ(w

>>95
DECってソフトウェアに関しても優秀な技術者がそろってるイメージだけどなぁ。
(自前でRT-11,RSX-11MやVAX/VMSなんて出来のいいOS作れるし)

やっぱりカトラーを干したのがまずかったか(w。
やつがMSに移りゃなきゃMSもいまよりもうちょっとましな商売してただろうし(w

>>100
真面目に聞くすけど，>>99の三つわ，いわゆる「同一掲示板にないマルチポスト」
として，かなり悪質度が高いと判断されるとわ考えなかったすか？

>>100
回答がないようすけど，悪気が無かったのなら自分で削除依頼を出しておくことをおすすめするす。

しかもコテハン叩き目的と判断される可能性も大だし。

悪いがスレを立てたのは俺じゃないって言ってるんだが（笑）

まぁ、２つは同一内容だが
http://pc3.2ch.net/test/read.cgi/hard/1034592680/
はこのスレの受入先じゃないか？

こちらもまじめに聞くが重複スレを立てたことは
謝らないのか？

>>105
>>98や>>100の方とわIDが違うようすけど。。。
ID:sM1QmSRyわ17:30頃からいるということわ，自作自演の告白すか(笑)
http://pc.2ch.net/test/read.cgi/mac/1034551147/62

随分流れてしまっていますね。

>>56
> 並列度についてわPentium 4わ6命令/clock, POWER4わ8命令/clockで
> 実行ユニットにissueできるようになっているす。大きな差だと思うす。
Pentium4 の単純な命令なら 0.5 サイクルで処理できる Low-latency ALU も
1命令/clockとカウントされているのですが...

>>75
> しかしSPEC2000を稼ぐためにも，IBMわ片側のコアを殺した上，同じMCM上の
> プロセッサからキャッシュをかき集めていたりするす。

SPEC 値の方はレイテンシをみるベンチだからしょうがないです。
当然、IBM も分かっていてスループットを測る rate 値の方では 32CPU が顏を出します。

1x16CPU int2k_rate=131 fp2k_rate=145
2x16CPU int2k_rate=249 fp2k_rate=260

SPEC の rate 値ってどのぐらい信頼性があるのかは謎ですが。

>>84
MACオタさんの挙げている点だけでは、タグメモリの容量が減ってないから全体のトランジスタ数は減っていないです。
「メインメモリ 1MB あたりのタグメモリ」では性能のパラメータになってしまう。
本当はタグビットとエントリ数を維持したまま、ラインサイズを拡大すると、タグメモリと連想検索を行う比較器がどの小さくなるかを指摘して欲しかったのですが。。。

>>107
>>56
> > 並列度についてわPentium 4わ6命令/clock, POWER4わ8命令/clockで
> > 実行ユニットにissueできるようになっているす。大きな差だと思うす。
> Pentium4 の単純な命令なら 0.5 サイクルで処理できる Low-latency ALU も
> 1命令/clockとカウントされているのですが...
失礼。
Low-latency ALU も含めて 6命令/clock でした。

>>105
ID: sM1QmSRyは「MACオタ追放スレッド」立てたよね(w

>>107
コストを考えるとプロセッサの設計わ面積の取り合いすから，ラインサイズを大きくすると
同じセット数で面積が小さくできるというのわ意味があると思われるす。
単純に性能とコストのトレードオフとしてラインサイズが決定されているという要因わ
少なくないと思われるす。

ところで，ラインサイズの決定要因についてわこの文章が良くまとまっているすね。
多分Solaris使いさんの言いたいこともこれと同じだと思うすけど如何すか？
http://www.aceshardware.com/Spades/read.php?article_id=77
Why does the Athlon uses a 64 byte cache line? One of the reasons is spatial
locality. Caches work on the principle that some data is used over and over
again, but it is also true that it is very likely that if you access some
memory cells, you will need the data in a adjacent memory cell at some point
in the future. So, if you read in adjacent memory cells of a memory cell that
you need to have in the cache, you might get lucky in the future, as it is very
likely that you need one of those adjacent cells. In other words, spatial locality.
With a 64-byte line cache you can save the CPU quite a few trips to main memory.
Also, using a 64 byte cache lines instead of a 32 byte line decreases the total
number of cachelines by two. Less cachelines mean faster lookup speed.

>>109
結局，訳も無くスレ立てするのが好きなヒトだったすか(笑)
心の中に"棚"がたくさんあるすね。。。

>>59,68,74 に関連。

今、気づいたが P6(PentiumPro) のキャッシュラインサイズって 32 バイトだよ。
何故、16 バイトと勘違いしていたのだろう。プリフェッチのフェッチ幅も 32 バイト。
それ以上に、誰もツッコミを入れなかったのか不思議だ。

Pentium4 はキャッシュライン 64 バイト。
ただし、プリフェッチ命令は128バイト(キャッシュライン 2 つ分)のマルチラインプリフェチ。
ただし、幅は固定。

>>87

同意。

終了

>>98,>>100　←　←　　☆　移動先　☆
に同意。

放置願い

>>112
64bit幅のバスと現代のDRAMの組み合わせでわ8byte x 4beat burstで32byteのキャッシュラインが自然だという話だけすけど。

放置ですよ、皆さん!

ちょっと余談すけど，フォームから送る削除依頼わIPが出るのが嫌ならプロクシ
を介しても送れるす。上の「不定期」さんわあちこちで迷惑をかけている変なヒト
すから，レス削除依頼をだしてみるのも良いかもしれないすね。
http://qb.2ch.net/saku/index2.html

>>110
> ところで，ラインサイズの決定要因についてわこの文章が良くまとまっているすね。
> 多分Solaris使いさんの言いたいこともこれと同じだと思うすけど如何すか？
最後の 2文以外は、私の言いたいことと同じです。
ただ、このページで書かれていることはアーキテクチャの基本なので、教科書のたぐいであれば必ず書かれているはずです(x86に特化してはいませんが)。

特にアーキテクチャの教科書の代表の1つ David A. Patterson/John L.Hennessy の「Computer Organization and Design: The Hardware/Software Interface 2nd Edition」
(著者の名前を取ってパタヘネ本と呼ばれる)では、キャッシュに関しては PentiumPro と PowerPC 604 を比較も行っています。MAC オタさんにはぜひとも読んでみることをお勧めします。
http://www.amazon.co.jp/exec/obidos/ASIN/155860491X/

＃ 本当はもう1冊の方が有名。
＃ その名もずばり "Computer Architecture: A Quantitative Approach"
＃ 前の本と同じ著者が書いていて、名前順が違うのでヘネパタ本と呼ばれている。

> Also, using a 64 byte cache lines instead of a 32 byte line decreases the total
> number of cachelines by two. Less cachelines mean faster lookup speed.
これは少し怪しいと思われ。理由は下の方。

>>107
で書いたことはよく考えると嘘だ。
16KB の direct-mapped cache だとすると。

16KB で 32 バイト→ エントリ 512。インデックスビット 10ビット。タグビット16ビット。
16KB で 64 バイト→ エントリ 256。インデックスビット 9 ビット。タグビット16 ビット。
＃ タグビット幅はキャッシュの容量で決まり、エントリ数はラインサイズの逆数で決まる。

タグメモリ容量 = (タグビット + 1)×エントリ数。

1. メモリアドレスから direct-mapped なキャッシュを引く操作はインデックスビットが小さいほど高速(トランジスタ数も少ない)。
2. 比較器は構成はタグビットの長さによって決まるので変わらず。
3. マルチワードのキャッシュラインから任意のデータ取り出す処理はラインサイズが小さいほど高速(ここは実装方法の要素が大きい)。

とにかくラインサイズが大きいとタグわ大きくなるす。最近のL2わ大きいすから
トランジスタ面積もばかにならないようす。
メモリとのやり取りわL1よりL2のリプレースメントによると思うすから，L2のライン
サイズの影響はいろいろと問題になるんじゃないすかね？

あれ？
MACオタさんは 84 では正しいことを言っているのに、119 では逆のことを言っていますよ。

タグビット幅 = log2(キャッシュ対象メモリ空間サイズ/キャッシュ容量)
エントリ数 = キャッシュ容量 / ラインサイズ
タグ容量 = (タグビット幅+1) / エントリ数

ですね。

>>120
> タグ容量 = (タグビット幅+1) / エントリ数
タグ容量 = (タグビット幅+1) × エントリ数

いたちがい

>>120
　　---------------------
　　119 では逆のことを言っていますよ。
　　---------------------
失礼したす。

ｷﾀ━━━━（ﾟ∀ﾟ）━━━━!!!!!!

>>124
保守してくれるのも結構すけど，もうSolaris使いさんわ来ないんじゃないすか？

終わり(´-`).。oO

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆　　終わり　　◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
> > >>120
> > 　　---------------------
> > 　　119 では逆のことを言っていますよ。
> > 　　---------------------
> > 失礼したす。
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆　　終わり　　◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆