【隔離】P4アーキテクチャについて議論する【スレ】
78 ：Solaris使い＞MACオタさん：02/10/14 18:23 ID:bPNHvqGX
79 ：MACオタ＞Solaris使い さん：02/10/14 18:26 ID:Cop5M7s/
>>78
普遍的事実でわ？違うのならヒット率が下がるとか，上がらないとかの根拠が欲しいす。
普遍的事実でわ？違うのならヒット率が下がるとか，上がらないとかの根拠が欲しいす。
80 ：Solaris使い＞MACオタさん：02/10/14 18:51 ID:bPNHvqGX
>>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バイトをご仮定ください。
元スレの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バイトをご仮定ください。
81 ：Solaris使い＠訂正：02/10/14 19:00 ID:bPNHvqGX
> また、同一キャッシュ容量なら消費電力やレイテンシは、キャッシュラインサイズよりも連想度(associativity)
> に受けると考えれます。
また同一容量のキャッシュなら消費電力は、キャッシュラインサイズよりも連想度(associativity)
の影響を多く受けます。
またレイテンシについて考えると、L1 → レジスタであればラインサイズ
の影響を受けません。また、要求された語を先送りする early start の
ような技法を備えた実装も多いそうです（パタヘネ 7.2章より)。
> に受けると考えれます。
また同一容量のキャッシュなら消費電力は、キャッシュラインサイズよりも連想度(associativity)
の影響を多く受けます。
またレイテンシについて考えると、L1 → レジスタであればラインサイズ
の影響を受けません。また、要求された語を先送りする early start の
ような技法を備えた実装も多いそうです（パタヘネ 7.2章より)。
82 ：名称未設定：02/10/14 19:05 ID:5bwxwuyf
板違いスレッドです。これ以上書き込まないで下さい。
Solaris使いさんも開き直らないで謝罪しる！
Solaris使いさんも開き直らないで謝罪しる！
ここはMac板なので
実際にMacで使われていない
または使えないハードウェアに関することは
ハードウェア板でやるように。
実際にMacで使われていない
または使えないハードウェアに関することは
ハードウェア板でやるように。
84 ：MACオタ＞Solaris使い さん：02/10/14 19:08 ID:Cop5M7s/
>>80
キャッシュ容量が同じ場合，トランジスタ数が節約できる理由わ明白す。実例を書けば
PowerPC 750のL2のラインサイズわタグメモリのサイズが固定であるため，L2の容量
とともに次のように変わるす。
256KB/512KB: 64 Byte
1024KB: 128 Byte
すなわり1MBあたりのタグメモリわ128 byte/lineだと半分になっているす。
確かにレイテンシと消費電力わセットの数の方が重要すね。
キャッシュ容量が同じ場合，トランジスタ数が節約できる理由わ明白す。実例を書けば
PowerPC 750のL2のラインサイズわタグメモリのサイズが固定であるため，L2の容量
とともに次のように変わるす。
256KB/512KB: 64 Byte
1024KB: 128 Byte
すなわり1MBあたりのタグメモリわ128 byte/lineだと半分になっているす。
確かにレイテンシと消費電力わセットの数の方が重要すね。
85 ：名称未設定：02/10/14 19:10 ID:dS1UerAG
板違いでも別にいいじゃん、くだらねぇ書き込みよりよっぽどおもろいよ。
それに謝罪ってなんでそこまで要求するかな。
それに謝罪ってなんでそこまで要求するかな。
MACオタとSolaris使い
こいつら、なんだ？CPUでも造ってる気になってるのか？
激しくくだらない知識ばら撒いてんじゃねーぞ！！オラー！！ (ﾉ｀A")ﾉ ┫：・’．：：
こいつら、なんだ？CPUでも造ってる気になってるのか？
激しくくだらない知識ばら撒いてんじゃねーぞ！！オラー！！ (ﾉ｀A")ﾉ ┫：・’．：：
87 ：名称未設定：02/10/14 19:11 ID:5bwxwuyf
私的なことで板違いのスレたてをするな！
正直言ってどうでも良い話題ではあるよな（藁
創造や生産、娯楽にすらMacを使いこなせないからこう言う方面に話がいってるのかもな。
オタを見てるとそう思う。
無力なことを思い知れよ・・・哀れ・・・。
創造や生産、娯楽にすらMacを使いこなせないからこう言う方面に話がいってるのかもな。
オタを見てるとそう思う。
無力なことを思い知れよ・・・哀れ・・・。
当然，公開の掲示板すから飛び入り参加わ歓迎するす。
90 ：名称未設定：02/10/14 19:25 ID:a0hQa18o
>>89
そうやって味方を増やしてどうにか板違いを正当化しようという魂胆みえみえす。
そうやって味方を増やしてどうにか板違いを正当化しようという魂胆みえみえす。
３． 固定ハンドル（２ｃｈ内）に関して
叩きについて
最悪板以外では全て削除します。
スレッド
固定ハンドルが題名に入っている・固定ハンドルが占用している
・閉鎖的な使用法を目的としている
・等は、自己紹介板・最悪板・夢・独り言板
・おいらロビー・なんでもあり板以外では、
原則として全て削除または移動対象にします。
ただし、固定ハンドル個人が一群または二類に属する時は
他の削除規定に触れない限り様子見となります。
叩きについて
最悪板以外では全て削除します。
スレッド
固定ハンドルが題名に入っている・固定ハンドルが占用している
・閉鎖的な使用法を目的としている
・等は、自己紹介板・最悪板・夢・独り言板
・おいらロビー・なんでもあり板以外では、
原則として全て削除または移動対象にします。
ただし、固定ハンドル個人が一群または二類に属する時は
他の削除規定に触れない限り様子見となります。
はぁー、どうしてDECなくなっちゃたんだろ。
あれほど技術力のもった企業ってあんまりないよなぁ。
やっぱりミニコンに執着しすぎたのかなぁ、Unixを取りこむのも遅すぎたし。
最期のほうでAlphaなんてすばらしいプロセッサ出してくれたけど、やっぱり遅すぎたよなぁ。
# そういやハード、ソフトともにDECの技術を継いでるものって結構あるよなぁ。
あれほど技術力のもった企業ってあんまりないよなぁ。
やっぱりミニコンに執着しすぎたのかなぁ、Unixを取りこむのも遅すぎたし。
最期のほうでAlphaなんてすばらしいプロセッサ出してくれたけど、やっぱり遅すぎたよなぁ。
# そういやハード、ソフトともにDECの技術を継いでるものって結構あるよなぁ。
おい。MACオタとSolaris使い
MacのG4が現在IntelのCPUに勝てないからって、次世代に逃げて
オナニーしてるんじゃないだろうな。そうだとしたらお前らセガ
信者となんら変わりねーぞ。セガは悲惨だったな（藁
とりあえず、メガビのお前のスレを嘲笑しておいてやるよ。
いつまで経ってもMACオタは進歩しねーな（藁
MACオタはバカを晒して楽しいかもしれんが見てるこっちは気持ち
わりぃんだよ。どっかいけ！
MacのG4が現在IntelのCPUに勝てないからって、次世代に逃げて
オナニーしてるんじゃないだろうな。そうだとしたらお前らセガ
信者となんら変わりねーぞ。セガは悲惨だったな（藁
とりあえず、メガビのお前のスレを嘲笑しておいてやるよ。
いつまで経ってもMACオタは進歩しねーな（藁
MACオタはバカを晒して楽しいかもしれんが見てるこっちは気持ち
わりぃんだよ。どっかいけ！
94 ：名称未設定：02/10/14 19:45 ID:lUD8Akdw
＞当然，公開の掲示板すから飛び入り参加わ歓迎するす。
君の掲示板ではありません。
板違いの話題はルールに反してますが？
君の掲示板ではありません。
板違いの話題はルールに反してますが？
95 ：MACオタ＞92 さん：02/10/14 19:46 ID:Cop5M7s/
>>92
オタさんｼﾞｴﾝたのしいすか？
オタさんｼﾞｴﾝたのしいすか？
>>95
わかりやすいｼﾞｴﾝですね。
わかりやすいｼﾞｴﾝですね。
98 ：名称未設定：02/10/14 19:53 ID:lUD8Akdw
板違いだ！下記スレッドへ逝け！
http://pc3.2ch.net/test/read.cgi/hard/1034592680/l50
【隔離】P4アーキテクチャについて議論する
1 ：不明なデバイスさん ：02/10/14 19:51 ID:h1zNFJxu
ここは板違いの話題のために新Mac板を追い出された
MACオタがPower4アーキテクチャについて議論するスレです。
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/
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/
100 ：名称未設定：02/10/14 20:00 ID:lUD8Akdw
スレを立てるのが悪いなんて言ってませんが何か？
重複スレを立てるなって言ってるんだろ。
厨房のやったことをネタに煽るのは如何なもんかと思うす(笑)
ま、いいだろ？移転先が見つかったんだから
http://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
漏れはオタさんじゃないですよ(w
>>95
DECってソフトウェアに関しても優秀な技術者がそろってるイメージだけどなぁ。
(自前でRT-11,RSX-11MやVAX/VMSなんて出来のいいOS作れるし)
やっぱりカトラーを干したのがまずかったか(w。
やつがMSに移りゃなきゃMSもいまよりもうちょっとましな商売してただろうし(w
102 ：MACオタ＞100 さん：02/10/14 20:04 ID:Cop5M7s/
103 ：MACオタ＞100 さん：02/10/14 20:13 ID:Cop5M7s/
>>100
回答がないようすけど，悪気が無かったのなら自分で削除依頼を出しておくことをおすすめするす。
回答がないようすけど，悪気が無かったのなら自分で削除依頼を出しておくことをおすすめするす。
しかもコテハン叩き目的と判断される可能性も大だし。
105 ：100：02/10/14 20:37 ID:sM1QmSRy
悪いがスレを立てたのは俺じゃないって言ってるんだが（笑）
まぁ、２つは同一内容だが
http://pc3.2ch.net/test/read.cgi/hard/1034592680/
はこのスレの受入先じゃないか？
こちらもまじめに聞くが重複スレを立てたことは
謝らないのか？
まぁ、２つは同一内容だが
http://pc3.2ch.net/test/read.cgi/hard/1034592680/
はこのスレの受入先じゃないか？
こちらもまじめに聞くが重複スレを立てたことは
謝らないのか？
106 ：MACオタ＞105 さん：02/10/14 20:46 ID:Cop5M7s/
>>105
>>98や>>100の方とわIDが違うようすけど。。。
ID:sM1QmSRyわ17:30頃からいるということわ，自作自演の告白すか(笑)
http://pc.2ch.net/test/read.cgi/mac/1034551147/62
>>98や>>100の方とわIDが違うようすけど。。。
ID:sM1QmSRyわ17:30頃からいるということわ，自作自演の告白すか(笑)
http://pc.2ch.net/test/read.cgi/mac/1034551147/62
107 ：Solaris使い＞MACオタさん：02/10/14 21:57 ID:bPNHvqGX
随分流れてしまっていますね。
>>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 あたりのタグメモリ」では性能のパラメータになってしまう。
本当はタグビットとエントリ数を維持したまま、ラインサイズを拡大すると、タグメモリと連想検索を行う比較器がどの小さくなるかを指摘して欲しかったのですが。。。
>>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 あたりのタグメモリ」では性能のパラメータになってしまう。
本当はタグビットとエントリ数を維持したまま、ラインサイズを拡大すると、タグメモリと連想検索を行う比較器がどの小さくなるかを指摘して欲しかったのですが。。。
108 ：Solaris使い＠訂正：02/10/14 22:07 ID:bPNHvqGX
>>107
>>56
> > 並列度についてわPentium 4わ6命令/clock, POWER4わ8命令/clockで
> > 実行ユニットにissueできるようになっているす。大きな差だと思うす。
> Pentium4 の単純な命令なら 0.5 サイクルで処理できる Low-latency ALU も
> 1命令/clockとカウントされているのですが...
失礼。
Low-latency ALU も含めて 6命令/clock でした。
>>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
ID: sM1QmSRyは「MACオタ追放スレッド」立てたよね(w
110 ：MACオタ＞Solaris使い さん：02/10/14 22:23 ID:Cop5M7s/
>>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.
コストを考えるとプロセッサの設計わ面積の取り合いすから，ラインサイズを大きくすると
同じセット数で面積が小さくできるというのわ意味があると思われるす。
単純に性能とコストのトレードオフとしてラインサイズが決定されているという要因わ
少なくないと思われるす。
ところで，ラインサイズの決定要因についてわこの文章が良くまとまっているすね。
多分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.
111 ：MACオタ＞109 さん：02/10/14 22:26 ID:Cop5M7s/
>>59,68,74 に関連。
今、気づいたが P6(PentiumPro) のキャッシュラインサイズって 32 バイトだよ。
何故、16 バイトと勘違いしていたのだろう。プリフェッチのフェッチ幅も 32 バイト。
それ以上に、誰もツッコミを入れなかったのか不思議だ。
Pentium4 はキャッシュライン 64 バイト。
ただし、プリフェッチ命令は128バイト(キャッシュライン 2 つ分)のマルチラインプリフェチ。
ただし、幅は固定。
今、気づいたが P6(PentiumPro) のキャッシュラインサイズって 32 バイトだよ。
何故、16 バイトと勘違いしていたのだろう。プリフェッチのフェッチ幅も 32 バイト。
それ以上に、誰もツッコミを入れなかったのか不思議だ。
Pentium4 はキャッシュライン 64 バイト。
ただし、プリフェッチ命令は128バイト(キャッシュライン 2 つ分)のマルチラインプリフェチ。
ただし、幅は固定。
115 ：MACオタ＞Solaris使い さん：02/10/14 23:17 ID:Cop5M7s/
>>112
64bit幅のバスと現代のDRAMの組み合わせでわ8byte x 4beat burstで32byteのキャッシュラインが自然だという話だけすけど。
64bit幅のバスと現代のDRAMの組み合わせでわ8byte x 4beat burstで32byteのキャッシュラインが自然だという話だけすけど。
放置ですよ、皆さん!
117 ：MACオタ＞Solaris使い さん：02/10/15 00:06 ID:01d2nBRw
ちょっと余談すけど，フォームから送る削除依頼わIPが出るのが嫌ならプロクシ
を介しても送れるす。上の「不定期」さんわあちこちで迷惑をかけている変なヒト
すから，レス削除依頼をだしてみるのも良いかもしれないすね。
http://qb.2ch.net/saku/index2.html
を介しても送れるす。上の「不定期」さんわあちこちで迷惑をかけている変なヒト
すから，レス削除依頼をだしてみるのも良いかもしれないすね。
http://qb.2ch.net/saku/index2.html
118 ：Solaris使い＞MACオタさん：02/10/15 00:07 ID:nqNc6rxM
>>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. マルチワードのキャッシュラインから任意のデータ取り出す処理はラインサイズが小さいほど高速(ここは実装方法の要素が大きい)。
> ところで，ラインサイズの決定要因についてわこの文章が良くまとまっているすね。
> 多分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. マルチワードのキャッシュラインから任意のデータ取り出す処理はラインサイズが小さいほど高速(ここは実装方法の要素が大きい)。
119 ：MACオタ＞Solaris さん：02/10/15 00:16 ID:01d2nBRw
とにかくラインサイズが大きいとタグわ大きくなるす。最近のL2わ大きいすから
トランジスタ面積もばかにならないようす。
メモリとのやり取りわL1よりL2のリプレースメントによると思うすから，L2のライン
サイズの影響はいろいろと問題になるんじゃないすかね？
トランジスタ面積もばかにならないようす。
メモリとのやり取りわL1よりL2のリプレースメントによると思うすから，L2のライン
サイズの影響はいろいろと問題になるんじゃないすかね？
120 ：Solaris使い＞MACオタさん：02/10/15 00:34 ID:nqNc6rxM
あれ？
MACオタさんは 84 では正しいことを言っているのに、119 では逆のことを言っていますよ。
タグビット幅 = log2(キャッシュ対象メモリ空間サイズ/キャッシュ容量)
エントリ数 = キャッシュ容量 / ラインサイズ
タグ容量 = (タグビット幅+1) / エントリ数
ですね。
MACオタさんは 84 では正しいことを言っているのに、119 では逆のことを言っていますよ。
タグビット幅 = log2(キャッシュ対象メモリ空間サイズ/キャッシュ容量)
エントリ数 = キャッシュ容量 / ラインサイズ
タグ容量 = (タグビット幅+1) / エントリ数
ですね。
121 ：Solaris使い＠訂正：02/10/15 00:36 ID:nqNc6rxM
122 ：名称未設定：02/10/15 00:44 ID:iUpQFB5q
いたちがい
123 ：MACオタ＞Solaris使い さん：02/10/15 01:15 ID:HxyO8J+R
124 ：名称未設定：02/10/19 11:37 ID:tB+a0GxE
ｷﾀ━━━━（ﾟ∀ﾟ）━━━━!!!!!!
125 ：MACオタ＞124 さん：02/10/19 11:47 ID:zQb4C5jV
>>124
保守してくれるのも結構すけど，もうSolaris使いさんわ来ないんじゃないすか？
保守してくれるのも結構すけど，もうSolaris使いさんわ来ないんじゃないすか？
126 ：名称末設定：02/10/19 12:36 ID:hg5LXAjr
終わり(´-`).。oO
127 ：名称未設定：
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆ 終わり ◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
> > >>120
> > ---------------------
> > 119 では逆のことを言っていますよ。
> > ---------------------
> > 失礼したす。
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆ 終わり ◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
> > >>120
> > ---------------------
> > 119 では逆のことを言っていますよ。
> > ---------------------
> > 失礼したす。
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆ 終わり ◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆