キャッシュのすべて


2次キャッシュの重要性は低下したのか?

 2次キャッシュが重要であるということは再三私が申し上げてきたが、残念ながら、Socket7などのマザーボード上の2次キャッシュは相対的に性能が低下してきている。そもそも2次キャッシュはメインメモリが大変遅いためにCPUを待たせないように作られたものである。もしそのメインメモリが十分に高速なら必要のないものである。高速なSDRAMが開発され、それがベース100MHzに同期している今日メインメモリとオンボード2次キャッシュの速度差そのものが縮まってきている。

 またOSもアプリケーションもますます肥大化し、常時数十MBのコードやデータが使われている状態では、十分なヒット率の確保も難しくなってきているという意見がある。大量のデータを使う3Dゲームなどでは、2次キャッシュの有り無しがあまりパフォーマンスに影響ないと言うのである。2次キャッシュのないConvington Celeronがもてはやされた理由の一つでもある。雑誌などでも、たった512kBの2次キャッシュデータRAMでは、数MBものアプリが当たり前の今、それらが到底入りきらないので、2次キャッシュはもはや重要でないといった記事を見かける。しかし本当にこんな2次キャッシュはもう重要ではないのだろうか。

 確かにオンボード2次キャッシュとメインメモリの速度差については一理ある。現在のSDRAMは100MHzで5-1-1-1-3-1-1-1といったアクセスタイミングになって、2次キャッシュの方は、3-1-1-1-2-1-1-1になっている。これを見る限りあまり差がないように思える。しかし実際テストをしてみると倍近いの差がある。この理由は私にもよくわからないのだが、DRAMであるSDRAMとSRAMである2次キャッシュにはリフレッシュ動作をするしないなどの差もあり、アクセスタイミングだけではなかなか比較できないものが存在しているのではないだろうか。

 しかしSocket7のオンボード2次キャッシュの場合、CPUと半同期した2次キャッシュをもつPentium-IIに比べて、速度的デメリットは小さいものとは言えない。やはりもっと高速な2次キャッシュが欲しいというのが本音であり、現在の2次キャッシュがとても速いものである訳ではないということは認めなければならない。

 私がノーと言いたいのはヒット率低下に対する雑誌などの見解である。彼らの根拠はこうだ。「昔のようにアプリのコードが数百KBなら、512kBのデータRAMに十分収まったが、今やアプリは数MBは当たり前であり、ワードなどは4MBもある。これでは簡単に512kBなどあふれてしまい、全く役に立たない」という訳だ。しかしこの話がいかにナンセンスであるか、賢明な読者ならすぐお分かりであろう。そもそもキャッシュアルゴリズムは、コードがデータRAMに収まればOK、溢れたらもうだめ、などという稚拙なアルゴリズムではない。

 ここの論理にはいくつかの大きな誤りがある。一つはプログラムコードを検証する時に、アプリケーション自身の実行プログラムサイズで議論していることであり、それと関連して、単純にプログラムコードとキャッシュデータRAM量を比較して、「前者が後者を超えるか超えないか」で議論していることだ。特に後者は全くキャッシュのアルゴリズムを理解していないとしか考えられないような馬鹿げた議論である。

 


キャッシュヒット率(1) プログラムサイズと実行コード

 アプリケーションは自分のコードだけで動いている訳ではない。それはMS-DOSでもUNIXでも同じである。システムが提供するDLL群に収められたAPI関数の助けなしには殆どの処理ができない。特にGUIを持ったWindowsアプリケーションはおびただしい数のシステムAPIに支えられており、たとえ数十kBのアプリケーションでもこれが稼動するには実際は数十MBのコードが動いていると言われている。

 もしあなたがVisual C++を触れる環境にあるなら、スケルトンを使って、画面に「こんにちわ」と表示する程度のアプリケーションなら簡単に作ることができる。いまここにそのスケルトンを使って、画面に私の名前「高安延匡」を表示するだけの最も簡単なプログラムを作ってみた。立ち上げると下図のような画面がでる。

単純プログラム

 この後特別なことができる訳ではないが、一応この文字を印刷することはできる。後は「終了」ができるくらいである。このプログラムのコードは15kBである。しかし立派な画面を持っている。ちゃんとタイトルバーメニューステータスバーもあり、ツールバーにはボタンもある。メニューをクリックすればプルダウンメニューも出てくる(選択しても何も動作しないが)。これらの動作は15kBのコードで実現されている訳ではなく、沢山のシステムコードで実現されている。15kBの自分のコードにはこれらのシステムコードを呼び出すコードが書かれているくらいである。そうはっきり言って15kBでは何もできないのである。このプログラムが動作するだけでも、ゆうに数MBオーダーのプログラムコードが必要なはずなのである。

 特にアプリケーションの話をするまでもない、OSが起動するだけでも大量のプログラムが動いている。デスクトップの維持だけでもかなりのDLLが必要になる。ほぼ3年前に出たWindows95の初期バージョンでも、起動時に20MBほどのプログラムがロードされていたという。もし上記のようにキャッシュのアルゴリズムが、データRAM量までならOKで、これを超えたら急激にヒット率が低下し、数倍も超えたら使いものにならないなどという稚拙なものなら、512kBのデータRAM量では、この時点(Windows95発売時点)で、いやWindows3.1の時点で既にキャッシュシステムそのものが破綻していたはずである。

 現在60MBほどのデータやコードがメモリにロードされていても、2次キャッシュのデータRAM量が512kBの場合、ヒット率が70%から80%はあるという。どうして120倍ものキャッシュされうるデータを抱えながら、このような高いヒット率を実現できるのであろうか。

 まず一つ言えることはメモリにロードされているデータが全てが汲まなく使われる訳ではないということだ。メモリロードはファイル単位で行われるので、実際は使わないコードも当然ロードされる。このような無駄があまりないようにDLLなども作られているはずだが、多少のオーバーロードは免れまい。またアプリケーションなどでも多機能のものは、実際にユーザが使いこなしていない場合が多く、あまり使わないコード、ほとんど使わないコード、全く使わないコードが大量に存在するはずである。使用頻度の高いコードは全体の半分もあるまい。

 また時間的な問題も重要である。5分間に使われるコードは30MBあったとしても、数秒の間に使われるものは数MBに過ぎない場合があろう。現在プログラムの動きからすれば、あまり長い時間を考慮する必要はない。数秒で構わないはずである。それを考えると実際現実にキャッシュ対象としての問題視すべきなのは60MBのうち15MB程度ではないかと私は試算する。もっともそれでもまだ512kBのデータRAMにとって30倍ものデータを扱わねばならない。

 キャッシュのアルゴリズムについてちゃんと話をはじめたら分厚い本が一つくらいできてしまうくらい話題が多い。到底ここで全部紹介することはできない。ここでは最も基本的はことのみ留めるが、それでも実行されるプログラムコードとキャッシュメモリ量に開きがあっても、高いヒット率を維持できる理論の片鱗をうかがうことができるだろう。

 


キャッシュヒット率(2) 時間的参照局所性

 まず「命令」「データ」では分けて考える必要がある。ここに以下のような6個の命令コードがあったとしよう。

A,B,C,D,E,F

 これが上記の順序で実行されたら、ヒット率はになる。しかしもし、

A,A,B,B,C,C,D,D,E,E,F,F

というように同じ命令コードが2回ずつ実行されたら、これだけでヒット率が50%に跳ね上がるのがご理解頂けるだろいうか。2回目のコードは1回目のコード実行によってキャッシュされているはずだからである。さらにもし、

A,A,A,B,B,B,C,C,C,D,D,D,E,E,E,F,F,F

というように3回ずつ実行されたら、ヒット率が66%になるのも同じ理由で容易にご理解頂けよう。何も同じコードが連続する必要もない。

A,B,C,A,B,C,A,B,C,D,E,F,D,E,F,D,E,F

という場合でも、3個のコードがキャッシュに収まるなら同じである。そしてこれらの例ならばコード自体は何種類、何MB、何GBあろうとこのヒット率に何ら影響がないことがわかるだろうか。もう少し説明すると、「A,B,C」という繰り返しの1サイクルさえキャッシュに収まれば、「A,B,C」とか「D,E,F」といった繰り返し処理の種類数「G,H,I」「J,K,L」という風に更にどんどん増えても全くヒット率には関係ないのである。また上記の場合は3回ずつ繰り返しているが、これが4回になれば、ヒット率は75%になり、5回になれば80%になる。

 このように同じ場所が、何度も繰り返し参照されることを、参照局所性という。特に上記の例のようにある場所がある一定の時間の間に参照される場合を時間的参照局所性という。通常命令はこの時間的参照局所性が非常に高く90%が普通だという。

 


キャッシュヒット率(3) 空間的参照局所性

 一方データの場合、上記の時間的参照局所性はやや低いと言われている。そのかわり空間的参照局所性は高い。これは今参照されたデータの空間的(位置的)にそばにあるデータが参照される可能性が高いという考えかたである。メモリを読む場合、必要なデータのみ読むわけではない。せっかくメモリリードという時間のかかることをやるのであるから、ついでに隣接したデータも持ってくるのである。もし次のアクセスがそのついでに持ってきたデータであるなら、そのアクセスはヒットすることになる。この空間的参照局所性は実は命令もデータも比較的高い。ただし命令の場合は分岐という動作が頻繁に入るため、基本的にそのような動作が少ないデータに比べ空間的参照局所性は低い。

 ただしこの性能をよりあげるには当然ついでにもってくるデータ(ブロックサイズ)を増やす必要がある。これは当然メモリ転送に時間がかかることになり、もしヒットしなかった場合(ミスした場合)のアクセス時間(ミス・ペナルティ)が多くなることに繋がる。ミス・ペナルティをあまり増やさずに空間的参照局所性をあげるにはメモリバス幅を広げるという方法があるが、もちろんこれはいろいろは制約も多いし、コストもかかる。

 


キャッシュヒット率(4) マッピング方式

 ヒット率に関わる重要な要素にキャッシュデータをキャッシュメモリのどこに配置するかを決定するマップ方式がある。なぜこの方式がヒット率に重要なのかというと、キャッシャブルエリアがキャッシュメモリより遥かに多いのであるから、当然データのキャッシュへの格納に競合が起こる。ヒット率の裏側にミス率(ヒットしない率)があり、ミス原因にもいろいろあるわけだが、この競合による競合ミスもその主な要素である。競合ミス率の増減はその二律背反であるヒット率に直接関わってくる。

 現在このマップ方式はに、競合性に対する手当てが行われないダイレクトマップ方式と競合が理論的に起こらないフルアソシエイティブ方式がある。競合回避に関しては当然後者の方が断然優れており、結果ヒット率が高い。しかし逆にアクセス時間は後者の方がかなり長い。データを探す時間がかかるからである。また後者はハード的コストも余分にかかる。

 実は現在キャッシュにはフルアソシエイティブ方式は殆ど採用されない。キャッシュの場合、ブロック数が大変多くて、データを探す時間が非常にかかりアクセス時間の増大がばかにならず、ヒット率の向上を殆ど相殺してしまうのである。ハード的コストも考えるとメリットが全然ない。

 そこで両者の中間であるセットアソシエイティブ方式というものが考案されている。このセットアソシエイティブにもレベルがあり2ウェイ4ウェイなどがあり、ウェイ数の多い方が競合が少なく、ヒット率が高い。反面アクセス時間は長い。現在パソコンのキャッシュは4ウェイセットアソシエイティブ方式が主流のようだ。Pentium-IIは命令1次キャッシュ、データ1次キャッシュ、2次キャッシュともにこの方式が採られている。しかし競合は全く回避されないが、機構が単純でアクセス速度の速いダイレクトマップ方式も依然人気があり、Socket7の2次キャッシュにはこの方法が採用されている。

 このように最もヒット率の高いフルアソシエイティブ方式が実際には採用されないのは、キャッシュにとってヒット率のみが重要でないことを物語っているとともに、現状ではヒット率がそれほど致命的な問題になっている訳ではないことも示している。まあうんちくはこれくらいにして実際テストをしてみよう。

 PhotoShopなどのグラフィックソフトはかなりの大量のデータを取り扱う。しかし実際もっともストレスを感じるフィルターの処理などでは2次キャッシュの有無が差しっかりとでていることをお見せしよう。実際Pentium-II 337MHz機で、約4MB16MBビットマップファイルテクスチャーのクラッキングを行ってみた。

 
PhotoShop 5.0
フィルタ−テクスチャ−クラッキング
2次キャッシュ 4MB 16MB
ON 20秒 75秒
OFF 25秒 90秒

 決して大きな差ではないが4MBというキャッシュデータRAM量をはるかに超えるデータを扱っているにも関わらず、ちゃんと2次キャッシュの効果が出ている。これはキャッシュヒットしている証拠である。また16MBのデータでも、4MBに比べて大きく差が縮まらない(20%差から17%差に減少)。これを見ても扱うデータやコードが数十MBオーダーで増加したからと、即座に512kBのキャッシュデータRAMでは使い物にならないということになる訳ではないことがよく分かる。

 


2次キャッシュの重要性 結論

 2次キャッシュの話をまとめると、やはりSocket7の場合、速度の相対的低下は認めざるを得ない。しかしヒット率に関しては、512kBのデータRAM量で全然足りないということではないので、アプローチとして速度向上を目指すなら、まだまだその重要性が著しく低下したわけではないと考える。このことをよく示すいい例がある。

 IntelはMendocinoで、たった128kBの内部2次キャッシュを搭載してきた。しかしこれが非常に性能がいい。キャッシュ容量は少ないが、速度がCPUと同期しているからである。2次キャッシュの相対的性能低下の原因が、そのヒット率の低下でなく、速度の相対的低下であることをよく示している。もし512kBではヒット率が著しく低いなら、128kBなどはお話にならないはずである。128kBでもまだまだそれなりのヒット率を実現できており、それよりも相対的に下がった速度の方が問題だった訳である。

 またAMDもK6-3で、256kBの内部2次キャッシュを搭載しようとしている。これもAMDが2次キャッシュに対し上記のようなIntelと同じ認識であることを示している。

 とは言うものの、データや命令コードの肥大がヒット率を全く圧迫しない訳ではない。現在512kBのキャッシュデータRAMが今後も十分だと言っている訳ではない。これからはやはり1MBは欲しいところである。今Super7のマザーボードで1MBのデータRAM量を搭載したのもが増えている。そろそろ2MBのものが登場するという噂もある。さすがに2MBもあれば、ヒット率90%も十分に確保できそうである。

 先のK6-3も2次キャッシュデータRAM量を256kBにすることによるヒット率の低下を、その速度で補うと共に、MBオーダーの3次キャッシュを積むことでヒット率の方からも補完するアプローチを行っている。私が思うに、今考えられるもっとも理想的な形態であると思う。結局速度もあげて量も増やすという贅沢な方向へ進もうとしている訳である。今後もキャッシュの動向しは目が離せない。

 


キャッシャブルエリア

 2次キャッシュの話が出てきたところで、非常に重要な要素としてキャッシャブルエリアというものの話をする必要があるでしょう。これはその2次キャッシュに「キャッシュ可能なメモリの範囲」のことです。実際マザーボードがいくら大量のメモリの搭載を可能にしていても、その全てがキャッシュ可能な場合は極めて稀です。

 まずSocket7の場合、これはチップセットの仕様によって違います。最近の多くのチップセットではかなり広い範囲が設定されるようになっていますが、Intelの430TXなどは64MBになっています。もっともチップセットが広い範囲を仕様的にサポートしていたとしても、マザーボードがその仕様をどれくらいインプレメント(実装)するかにもよりますから、注意する必要があります。これはキャッシャブルエリアは、TagRAMのビット数データRAMの量といった「量的」な要素に依存するため、高度なインプレメントにはどうしても費用がかかってしまいます。マザーボードベンダーとしては、コストパフォーマンスを考慮して、実装度を検討する必要にせまられます。実際VIAのMVP3でも、仕様的には512MBまでのキャッシャブルアエリアがありますが、これはデータRAMに2MBを積んだ場合です。現在殆どのMVP3マザーのデータRAMは512kBから1MBなので、現状としてはキャッシャブルアリアは128MBから256MBになっています。

 一方Slot1のように、2次キャッシュがマザーボードに登載されないものは、当然マザーボード側のインプレメントということは問題になりません。この場合CPUの仕様の問題になります。現在デシューツコア以降のPentium-IIでは、4GBものキャッシャブルエリアがありますが、昔のクラマスコアのPentium-IIは512MBに過ぎません。

 


キャッシャブルエリア超のメモリ登載

 ところでこのキャッシャブルエリアというのは何が重要なのでしょうか? それを検証しましょう。

 たとえばキャッシャブルエリアが128MBだった場合、192MBとかいったその範囲を超えるメモリの登載は何か問題があるのでしょうか? まず超過登載された場合、どの部分がキャッシャブルエリアになるかみましょう。結論から言えばこれは下位メインメモリ側になります。「下位」とはアドレスが若いものです。アドレスの若い下位にマッピングされたデータに関してはキャッシングの対象となります。上記の例の場合、下位128MB部分にマップされたデータはキャッシュ(2次キャッシュデータRAMに格納され、再び参照された場合、2次キャッシュから読みこまれる)され、所謂キャッシュシステムの恩恵を受けることになりますが、メモリ上位64MB部分にマップされたデータは、キャッシング時のタグの比較で一致する格納部屋がないため、決してキャッシュされることがないのです。

 このこと自体それほど問題がないように思えます。ただ単に128MBまではキャッシュされ、それ以上の部分はキャッシュの恩恵を受けないだけだと。たとえキャッシュの恩恵は受けれないとしても、スワップが発生してハードディスクにアクセスすることを考えれば、遥かにいいのではないかと。ところがOSによってはこれが大問題になります。たとえばWindowsの場合、メインメモリはなんと上位から使用されます。つまり上位アドレスからデータがマッピングされていくため、ご丁寧にもまずキャッシュの恩恵を受けない部分から真っ先に使用されてしまいます。

 通常OS(システム)の重要な部分は早い時期にロードされるばずです。Windowsの起動と同時にシステムに関わる、Windowsが動いている間、常に参照され使用される極めて重要なkernel32.dllやshell32.dllなどDLLなどが次々にロードされます。このようにシステムの根幹たる極めて重要な、極めてよく参照されるであろうプログラム部分がよりによって、キャッシュ対象でない部分にロードされしまうことになる訳です。

 実際私が128MBがキャッシャブルエリアのマシンで、192MBのメモリを登載した場合、どれほどパフォーマンスが落ちるのかをこちらで実験しました。この場合も非キャッシャブルとなるのは64MBですが、まあ今のWindows98でもシステムだけなら余裕で収まってしまう量です。そのため実験結果でもわかる通り、2次キャッシュ切ってしまった時と殆ど変わらないほどのパフォーマンス低下を招いています。

 現在のキャッシュのアルゴリズムでは上位からキャシングしていくことはできません。またWindowsがなぜ上位アドレスからマッピングするようになっているのはわかりませんが、少なくともユーザが変更できるたぐいのものではありません。また他のOSで上位からメモリを使うようになっているものがあるのか、無いのかは私には分かりません。Linuxなども同じだと聞いたことはありますが、確認した訳ではありません。

 いずれにしてもユーザとしてこの問題を回避するには、Windowsのように上位からメモリマップを行わないOSを使うか、キャッシャブルエリア超のメモリを登載しないようにするか、登載したいメモリが全域キャッシャブルになるようなシステム構成にするしかない訳です。実際OSを変更するということは大変な作業になりますから、現実的には後の2つしかないのでしょう。従ってWindowsを使ってメモリを沢山登載したいと思っている人は、自分のシステムが、またこれから購入しようとしているシステムが、どれくらいのキャッシャブルエリアを持っているか、ちゃんと調べておく必要があります。

 


CPUとメインメモリの格差

 CPUは現在ムーアの法則にほぼ従って高速化しています。このムーアの法則とは、「プロセッサーの速度は18ヶ月で倍になる」というIntelのムーアさんが言った言葉です。最近ではPentium-II 300MHzが一昨年の9月にでて、Pentium-III 600MHzが今年の7月と、倍になるのに約22ヶ月かかっていますが、まあだいたい法則通りということでしょう。一方メインメモリはどうでしょう。66MHzで動くSDRAMの登場は3年前の暮れになりますから、現在の133MHzになるまで、2年半かかっています。倍になるのに2年半と2年弱くらいの差がCPUとメインメモリにはある訳ですね。

 どうしてこのような差がでるのでしょう。それは半導体の世界だけで済むCPUと、それだけでは済まないメインメモリの構造上の問題でしょう。メモリの場合、チップ内のデータをマザーボード上の配線を通してチップセットやCPUに運ばねばなりません。今ボトルネックになるのは実はこのメモリバス部分な訳です。

 ですからこのメモリバスにてこを入れようというのが、RDRAMの試みな訳ですよね。バス幅を縮小してでも周波数を上げられるようにした方が結局速くなるし、その後の高速化もしやすいのではというのが、このアーキテクチャの売りです。それでもやはりCPUのような訳にはなかなかいきません。

 そして、どうしても避けられないCPUとメインメモリの速度の格差を埋めるために、キャッシュが考案されている訳です。

 


マルチレベルキャッシュ

 しかしそのキャッシュももはや1レベルでは追いつきません。現在でも普通2レベルでキャッシュしています。1次キャッシュ、2次キャッシュと呼ばれるものがそれです。

 現在1次キャッシュは全てCPUに内蔵されており、CPU内のレジスタとそれほど変わらない速度でアクセスすることができます。容量は32kB(Pentium-II、III、Celeron)から64kB(K6、2、III)程度が主流ですが、Athlonは128kBを積んでいます。最近はよく2次キャッシュのことが話題になりますが、システムにとっては遥かに1次キャッシュの方が重要です。もしあたなのパソコンがBIOSで1次キャッシュを切る設定をサポートしているなら、1度切ってみて下さい。2次キャッシュを切った時はそれほど苦痛ということはないと思いますが、1次キャッシュを切ると、殆ど使いものにならないでしょう。

 まあ実際CPUのメモリアクセスとは、かなり細かい単位で行われているので、1次キャッシュへのヒット率は意外にも高く、しかも大変高速なのでパフォーマンスへの影響は甚大です。データの這いずり回る面積の広さからして、どうしてもCPUとメインメモリでは、速度向上に差がつく訳で、今後もその傾向は変わりはないでしょう。


オンダイと容量

 さて2次キャッシュも最近はCPU内蔵、つまりダイ上に乗せる、所謂オンダイがはやりです。それはやはりCPUと同じクロック(フルスピード)で動作させられるし、近くにあるので、非常に早くアクセスできるからです。しかし当然オンダイにする場合、その容量を犠牲にする必要があります。同じウェハで作る関係上、現状ではメガ単位でオンダイ2次キャッシュを搭載するのは無理でしょう。現在民生用のCPUでオンダイ2次キャッシュを搭載しているのは、Celeron、Pentium-III、K6-IIIです。CeleronとPentium-IIIに関しては全てのシリーズがそうという訳ではなく、それぞれMendocino、Coppermineというコード名のシリーズです(もっともCeleronのMendocino以外であるConvingtonはとうに市場から消えてますが)。

 容量はCeleronが128kBで、他の2つが256kBです。最近プロセスルールが0.18ミクロンになってきたので、もっと乗せることが理論的に可能になってきましたが、現在では256kBが上限です。ただやはりメガ単位の量を乗せるのは難しいでしょう。ダイ上に乗せるのと容量はトレードオフということになります。

 


バックサイドバス・キャッシュ

 では、どうしてもオンダイにする必要があるのだろうか。実はそうではない。そのことをAthlonが証明している。Athlonは今2次キャッシャをダイ上に乗せていない。ダイの外にある。そのため容量は512kBを積んでいる。そのため速度もCPUクロックの半分であり、KatmaiまでのPentium-IIIやPentium-IIと同じである。しかし多くの人の検証によって明らかにされているが、Athlonは素晴らしいパフォーマンスを発揮している。

 実は2次キャッシュで重要なのは、現状ではオンダイであることよりも、バックサイドバスに2次キャッシュが置いてあることなのである。IntelでいうとMMX Pentium、AMDではK6-2までは、2次キャッシュはフロントサイドバスに置いてあった。このことはメモリと2次キャッシュの同時アクセスができないために、クロック差以上に不利であった。Pentium-IIが初めてバックサイドバスに2次キャッシュを置き、当時クロック差以上に高パフォーマンスを発揮したのが記憶に新しい。

 バックサイドバスキャッシュのもう一つの利点は、CPUクロックに連動できることである。フロントサイドバスキャッシュの場合、ベースクロックのみに連動していて、CPU倍率とは連動しなかった。だからCPUが高速化するにつれてどんどんその差を広げられてしまった訳である。オンダイの場合、フルスピードで連動しているが、別にフルスピードで連動する必要はない。ハーフスピードでもたとえ3分の1でもいいから、兎に角CPUに連動することが肝要である。

 今後も2次キャッシュがフロントサイドに戻ることは決してないだろう。むしろ次の3次キャッシュもバックサイドバスに置くべきだと私は思っている。オンダイでフルスピードの2次キャッシュは256kBでも、バックサイドバスに1/3スピードの2MBほどの3次キャッシュがあれば、なかなかのパフォーマンスになるのではないだろうか。

 今後キャッシュがどのような方向に進むか注目しよう。更なるマルチレベル化、容量の増大などなど。

 


ホームページへ

















inserted by FC2 system