(*゚Д゚)<MacとWinをアーキテクチャで比較スレ

このエントリーをはてなブックマークに追加
170名無しチェケラッチョ♪:02/05/11 18:43
>>168
続きを是非ともキボン
171マ狂:02/05/11 18:45
>>167
アプリケーションにある"実行コード"で、
データが"処理"されるから
間違える事はないと思う
172名無しチェケラッチョ♪:02/05/11 18:47
>>171

リクに応えてくれて有難う
173MACオタ>マ狂 さん:02/05/11 19:54
>>171
そんなに話が簡単ならシステムエラーわ起きないす。
174マ狂:02/05/11 20:00
>>173
それはバグのせいでは?
175:02/05/11 21:48
>>171

んではアプリケーションにある"データ"は?オペランドね。

一連の話は簡単にいうと3次(外部)キャッシュにプリフェッチはキクか?
効いたとして有効なのか?てな話だと思う。漏れは疑問視するスタンス。
176犬球@▼´ェ`▼:02/05/11 23:02
プリフェッチってコードつまみぐいのソムリエみたいなもんかな‥‥。
だとすれば2MBのL3キャッシュでもかなーり有効な気が。

でも実際効いてるんかと言われればヤパーリ疑問視。

http://www.atmarkit.co.jp/fwin2k/special/winxp_over/winxp_over_19.html
177:02/05/12 15:15
犬球さんて、ふぇっちのアイコンに似てるね。。
178:02/05/12 17:05
フロッピーくわえてるやつだっけ?ふぇっちのアイコン
179●~*:02/05/12 17:35
180犬球@▼´ェ`▼:02/05/12 21:09
じゃあTransmit使うのやめてふぇっちにしよかな。
まだお金払ってなかったし。
181:02/05/12 23:03
コレクションにふぇっちのフリーのバージョン見つけたよ。
182犬球@▼´ェ`▼:02/05/13 03:05
あれっ、昔の英語バージョンはフリーだったんだっけ。
Xなのでまずはカーボソ版を使ってみるよ。
183:02/05/13 12:13
>>168
>キャッシュは、使わないコードの破棄を繰り返して、体感的に早く見せる
>んだと思う。ようはコードのつまみ食いだね。一気食いはしないw

コード実行の際のCPUのパイプラインはそのためにあるんじゃないかと。

パイプラインはコードの最適化プリコンパイルみたいなものをCPUが自分で
Wiredに行う機構だ〜ね。いわばCPUは自分で「使わないコード」を知っている、
というか、そう結線されてる。

だが高速メモリそのものであるCPUキャッシュは、どれが「使わないコード」
であるかわからない。区別するにはCPUの判断が必要になる。CPUは一旦
キャッシュに読まれたコード、データを、それはとっておいてとか、それは
捨ててとか指示する(キャッシュ制御)。あるいはそれだけは優先的に上位の
キャッシュに送って、と指示するのかもしれないがよくわからない(ぷりふぇっち)。
どっちにしろキャッシュには最低限一回はコード、データがロードされる必要が
ある。キャッシュだけで器用なつまみ食いはできない。また、ぷりふぇっち
するならCPUによる下位キャッシュまでの監視制御機構が不可欠になる。
(つづく)
184:02/05/13 12:15
(つづき)

読み込まれるコード、データがキャッシュの容量を超えたらどうなるか?
「使わないコードの破棄を繰り返し」、そして再読み込みが激しく発生する。
キャッシュは当然効かなくなり、2度手間、3度手間が多発する。
効率は落ちることはあってもあがることはない。

で、だ。現在OSだけで常時「生きている」コードが数十MBに達する。
アプリケーション、スクリーン上のフォントの展開だけでもおそらく
数MBにはなるだろう。(もっともこれはOSXではQuatrz、特に次の
Quatrz ExtremeではCPUではなくビデオカードにやらせてるかもしれないが。)

というわけで、
>>155-156
>3次キャッシュは2Mバイトもあるので,起動しているアプリケーションコードや
>データの大部分を格納できる。
だっからさ、これマジすか?今どき2Mでたりるのかと。
>>149ほんとに3次キャッシュって意味あるのか?ということになる。

まぁ、高速バスにはそれなりの意味はあるだろうし、
サイズがキャッシュに納まるフォトショベンチやπベンチには、
かな〜り有効かもしれない。得意なベンチマーク対策かなぁなどと邪推したり(w

185梨華:02/05/13 17:00
>>184
その理屈でいくと、いまどきの3次キャッシュは256MB必要だって事か?w

「生きている」の再定義をよろしく頼む。
漏れはMP3の曲で言うなら、ファイル全体では無くて、
今再生している部分こそが「生きている」データだと思ってたし、

厳密にはメインメモリのデータを読み込んで処理する、
プレイヤーの再生部分の命令だけがキャッシュされるのがL3だと思ってたんだけど。
186マ狂:02/05/13 18:56
初期のG3(750)ってプロセッサ自体の評価は
604e(Mach)より同等かそれ以下なんです。
で、604e(Mach)より遥かに高い能力を発揮できたのは、
バックサイドキャッシュのおかげだったそうです。

2次キャッシュがオンダイになってから今の3次キャッシュの効果って、
バックサイドキャッシュの補助効果に近いのではないでしょうか?
187Lucifer:02/05/13 20:36
>>155
Response 遅すぎで申し訳ありません.

それで,リンク先を見てみたところ,僕の発言とはかけ離れている感じ.
僕が言っているのは, HDD の一部として組み込まれている ' Buffer ' のこと.

もし,仮に DRAM だとすると,
System での DiskCache との二度手間になって,
かえって,パフォーマンス低下の原因になると思うのです.
だいいち, 512kB とか 2MB 程度のものなら,
SRAM でも,さほどコストが問題にならないでしょ.
(もっとも,これは希望的推測に過ぎず,なんの根拠もありません.)
188イヒ:02/05/13 20:40
>>187
Writeキャッシュという考えはないのかのぉ? >HDD
たいていはそのはずだが。
189●~*:02/05/13 20:40
>>187
Luciferタン、その文体(・∀・)イイ!
幼児言葉風文体の時よりも好感度激しくUP!
190イヒ:02/05/13 20:54
>>184
そのキャッシングじゃバッファでしかないぞ。
キャッシングの最大の目的は遅い要素へのアクセスを最小限にすることなのだから
高精度な予測との組み合わせで効果が出る。

MP3の場合はファイルの方はそのデバイス以上の速度では読めないのだから
キャッシュの意味はない。意味があるのは実行コードの方だ。
191Lucifer:02/05/13 20:58
>>164-165
Harbard Architecture って,ご存じ?
(スペル間違っているかもしれません. 辞書でヒットしなかったので.)

>>188
くわしくは,知りません.

>>189
いつ,退行化するか,自分でも予想がつきません.
192イヒ:02/05/13 22:21
>>188
書き込み時にシークの間に待たされたくはなかろう。
193イヒ:02/05/13 22:27
しもた(汗
s/188/191/

>>191
ついでだ。
カナのほうが素直に見つかる。 >Harvard architecture
194Lucifer:02/05/13 22:49
>>183-184
長い文章 ...
テーマとしてはおもしろいし,
3 次 Cache については,疑問が残るのは確かです.
(On-Die で,十分な Capacicy を確保できるほうが良いに決まってます)
でも,反論は簡単.

>>186 が言うように, 604 と 750 を比べると,
' Core ' としては,604 の方が高性能でした.
それにもかかわらず, 明らかに 750 の方が,速かったでしょ ?
その原因となったのが, たった(?) 562kB の BackSide Cache .
この事実をどう説明しますか?
195●~*:02/05/14 09:44
×562kbB
○512KB

アルファベットの大小にも意味があるので注意。
196●~*:02/05/14 10:28
197●~*:02/05/14 11:10
ストリーミング(MP3)や巨大データ等のcacheが有効に働きそうにない条件だけ考慮して、
「大容量L3Cacheは無意味だ!」と言うのは意味がないと思われ。
198:02/05/14 11:42
いや、自分の理解も定かじゃないからさ、半分は憶測なのだよ。
せっかくsageで書いてたのに(w。んでは、順番に
>>185
>「生きている」の再定義をよろしく頼む。
メインメモリ(あるいはヴァーチャルメモリ)に展開されたコードすべてとしよう。
コードは、OSであれば、キーボードをスキャンしデバイスを監視し、ネットワークと
コネクションし、その他もろもろのOSのサービスを提供しているすべてのコードだ。
マルチタスクでアプリケーションを起動しているのであれば、当然オンメモリのそれら
のコードも含む。全部でメモリ上にどのくらいのコードがあるか?Mp3プレーヤと
メッセとワープロなり画像処理ソフトなりを同時起動すれば、それがいかに膨大で
あるかは想像しやすい。

>厳密にはメインメモリのデータを読み込んで処理する、
>プレイヤーの再生部分の命令だけがキャッシュされるのがL3だと思ってたんだけど。
君のMacにはメインメモリに接続されたMP3再生デバイスでも搭載されているのかな?
(例えばAGP経由で描画命令を専門に実行するビデオカードのような。漏れのMacには
ついないようだ。)MP3が再生されるためにはMP2layer3データがCPUのレジスタに
送られてデコードされる必要があり、その際に(結局データがキャッシュされず破棄される
にしても)、一旦「キャッシュを通過し容量を消費する」と思うのだが。
ファイル丸ごといくのか、ある程度のサイズで分割されデータブロックが連続処理
されるかは知らないが、大きな違いはないと思う。もし、気になるのであれば
MP3データのようなデータブロックは無視してもかまわない。確かにキャッシュを
通さずスルーしている可能性もある。しかし、ならばそのときCPUは遅いメインメモリを
待って足踏みしているか、そのデータブロックを利用すべきコードを破棄して
データが届くまで、別のコードを発行しているはずだ。
199:02/05/14 11:42
>>190
>高精度な予測との組み合わせで効果が出る。
だからどうやって高精度に予測するのかと聞いているのだが?
キャッシュは高速メモリでしかない、キャッシュが独自で予測などできんよ。

>>186,194
半分同意。

>' Core ' としては,604 の方が高性能でした.
>それにもかかわらず, 明らかに 750 の方が,速かったでしょ ?
>その原因となったのが, たった(?) 562kB の BackSide Cache .
これのソースキボン。おそらく解はここにある。
200●~*:02/05/14 11:49
>>199
>だからどうやって高精度に予測するのかと聞いているのだが?

そんなコアなことはメーカー的には教えてあげないよプンプンだとおもわれ
201イヒ:02/05/14 12:41
>>200
実装はともかく理論そのものは山程宣伝されとるようだが(w

>>199
まず、過去の参照頻度が得られますな。
次いでマシンコードの体系と分岐からくる参照範囲というのは当然割り出せる。

キャッシュが高速メモリに過ぎなければ御説通りに一杯になった時点で効果が落ちてしまうよ。
ましてや1次2次3次などと多層化する意味はなく単に1次を大容量化したほうが
良くなってしまう。でもそのように作っていないよな?

ソフトウェアの経験則である「頻度の高いコードは全体のごく僅か」というのがあって
そこを改善すると全体の効率が上がるのだな。
CPUから見れば今処理しているコードが何に関係するか知る由もないが、使用頻度と
マシンコードの依存関係はわかる。よってそれに基づいてコード処理の時間の最適化を
はかる手法のひとつがキャッシュなんであって、大容量化はそのキャッシュ管理手法による
オーバーヘッドとのバランスの問題になってくる。

キャッシュを大容量化しても効率が上がりにくくなる限界というはあるから、その見込みを
もとに容量を決めているだけのことよ。
202:02/05/14 18:11
>>201
うむ、おおむね同意だよ。

>キャッシュが高速メモリに過ぎなければ御説通りに一杯になった時点で効果が落ちてしまうよ。
>ましてや1次2次3次などと多層化する意味はなく単に1次を大容量化したほうが
>良くなってしまう。でもそのように作っていないよな?

で、ここだな。例えばPen4のオンダイキャッシュはプリフェッチ機構が
実装されている。はたしてG4の3次キャッシュは?というところだと思う。

漏れがこれほどまでに3次キャッシュの有効性に疑問をもつのには実は理由があって
アポには前科があるのだ。MacがPowerPC(603)化された頃の話、一部の機種には
256KBのL2キャッシュなるオプションパーツが用意されており、アポによれば
それを取り付ければ10〜30%の速度向上が見込めるといううたい文句であった。
たしか\20000弱はしたと思う。阿呆な漏れは購入したさ。が、効果はほとんど
なかった。ハードディスクを交換した方がよほど効果があった。

「3次キャッシュ搭載」、これは実効より非搭載機種との差別化、新機種の価格帯の
維持など、販売上の心理的影響のほうがでかいのではないか?なにしろ、消費者には
「3次キャッシュなるよくわからないがスゴイものが搭載されているので、速いに違いない」
という思い込みが存在する。現に、販売促進的意味をもつ前出の下記の記事には
http://www.zdnet.co.jp/macwire/0203/27/r_dualj.html
>3次キャッシュは2Mバイトもあるので,起動しているアプリケーションコードやデータの大部分を格納できる。
なんて記述もみられたりするわけだ。とにかくよくわからんがスゲースゲーのである。
203マ狂:02/05/14 19:06
>>202
そのL2キャッシュってフロントサイドに接続されてるから、効果が薄かったんだよ。
つまり
    メインメモリ
     |
CPU−フロントサイド−その他の装置
     |
     L2キャッシュ

じゃデータの転送速度が最高50MHzだったり、他の装置と競合したりして、実力が出せなかった。そして現在は

              メインメモリ
               |
L2キャッシュ−バックサイド−CPU−フロントサイド−その他の装置

と言う形になり、他と競合せず高速な(CPUの半分の速度)バスを使うようになり、実力を発揮できるようになったんですよ。
アーキテクチャ的にはこういう感じ。
204マ狂:02/05/14 20:08
なんちゃって(藁
205マ狂:02/05/14 20:20
>>204
ダマーリやめんしゃいw
206マ狂:02/05/14 21:26
>>205
うるちゃいw
207マ住:02/05/14 21:31
訂正。

古いの

CPU
 |
L2キャッシュ
 |
FSB-その他の装置
 |
メモリ

新しいの

CPU-L2キャッシュ
 |
FSB-その他の装置
 |
メモリ

訂正おながいします。
208マ狂:02/05/14 22:08
>>206
ゴホンゴホン、チキショー!
209:02/05/14 22:21
>>203
まぁよくは知らんよ。まぁ、前半分は当時のMacはCPUがVRAM描画までしていたから
しょうがないとも言えるし。だがキャッシュが飽和したら接続がどうでも結局キャッシュは無意味だよね。
将来「そのL3キャッシュって、効果が薄かったんだよ。得意になっている人は多かったけど」
って言われなきゃいいなぁと思うのさ。

アポ曰く

●PowerPC マイクロプロセッサ(※L2 キャッシュ の解説)
>L2 キャッシュを追加すると性能が向上する理由は、PowerPC マイクロプロセッサがその
>パイプライン処理をフルに活用できるためで、これによってより速く効率的な処理が
>可能になります。マイクロプロセッサは、まず内部キャッシュに命令があるかどうかを調べ、
>次に L2 キャッシュ、そして最後にメインメモリ(DRAM)を調べます。キャッシュメモリは
>DRAM より高速であるために高速なアクセスが可能となり、このためパイプライン処理が
>フルに活用されます。 これはまた、性能の向上が決まっていないことの説明にもなります。
>頻繁に利用されるコードはプロセッサの近くにとどまり、より高速に実行されます。ほかの
>コードではできません。一般に、L2 キャッシュを利用するコードでは、10 〜 15 % の性能の
>向上が期待できます。

だそうで、当時漏れを含めてこれを信じてマンセーしとる人もいたのさ。そして今、

●高いパフォーマンスを生む新アーキテクチャ(※L3 キャッシュ の解説)
>新しいPowerBook G4の内側にあるVelocity Engine搭載のPower PC G4プロセッサは最速の
>667MHzまたは800MHzで動作。そして、新たに1MBのDDR SRAM三次キャッシュも追加され
>ました。三次キャッシュはきわめて短時間で動作する高速メモリで、プロセッサがデータや
>命令にすばやくアクセスするのを助けて、システムの処理性能を向上させます。このアーキ
>テクチャによるパフォーマンスの向上は、言葉で語り尽くせないほど。

だそうで、今も昔も言うことは大差ない。そしてやっぱり懲りずにマンセーしとる人がいる。
アポが言う通り、どうやら語り尽くせないらしい(w。
210マ狂:02/05/14 22:27
ぶっちゃけて、10%じゃ体感できないっす。
CPUのクロックアップの経験しかないけど。
20%なら体感できるっす
211イヒ:02/05/15 00:41
まぁ、モトローラの方を信ずるなら、今の3次キャッシュの役割はハード的な互換性と、メインメモリとCPUの動作クロックの
ギャップを埋める役割といっていいんだろうな。
あった方がいいが、その効果は「やたらにメモリを読み書きするアプリケーション」でないとあらわれにくいだろうと
予想されるな。
212●~*:02/05/15 03:47
アーキテクチャ全然わからんけど、HDDの読み書きとか3Dゲームでも
BackSide L2の効果は絶大だった。今のL3もそれと似たようなものと
考えていいのだろうか。

# 256KBとか512KBとか1024KBとか変えて試した。上記の局面では
512KBじゃ足りなくて1MBあれば大体十分、という結果だった。2MB
積んでも大差ないだろうな、という感触。あくまで感触だけど。
213:02/05/15 09:54
>>212
それはキャッシュの効果より>>203のいう接続形式の変更が大きいかも。
BackSide用の(キャッシュではなく)バスがあれば、HDDーメモリの転送や
メモリービデオの転送の際に、他のタスクでCPUーメモリアクセスのためにシステムバスが
干渉を受ける必要がなくなるから。3DゲームはAGP(のビデオカード)の
搭載のほうがかなり効いているかと。
BackSide L2が1Mで十分ならL3は必要なのだろうか?

今思ったのだがデュアルCPUマルチタスクならひょっとして効果が
あるのかもしれないねぇ。それぞれのCPUが少量でも専用のメモリを持っている
ようなものだから。


214マ狂:02/05/16 18:45
Macのキャッシュアーキテクチャの歴史

スタンダードアーキテクチャ(68kMac〜NuBusPPCまで?)
    メインメモリ
     |
CPU−フロントサイド−その他の装置(NuBusなど)
     |
  プロセッサーダイレクトスロット(キャッシュスロットとしても利用可能)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−


L2キャッシュアーキテクチャ(Performa5400(?)〜PowerMac9600/233まで)
    メインメモリ
     |
CPU−フロントサイド−その他の装置()
     |
    L2キャッシュ
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−


インラインキャッシュアーキテクチャ(ラディウス社製(?)キャッシュダブラー〜PowerMac9600/350(Kansas)まで)
             メインメモリ
              |
CPU−インライン−L2キャッシュ−フロントサイド−その他の装置
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−


バックサイドキャッシュアーキテクチャ(PowerMacG3〜PowerMacG4/500Dual(?)まで)
              メインメモリ
               |
L2キャッシュ−バックサイド−CPU−フロントサイド−その他の装置
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−


オンダイキャッシュアーキテクチャ(PowerMacG4/466〜)
                       メインメモリ
                        |
L3キャッシュ−バックサイド−CPU(L2キャッシュ内蔵)−フロントサイド−その他の装置
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

多分あってると思う。
215マ狂:02/05/16 18:53
ああ、押し間違えた……
216:02/05/16 21:51
>ラディウス社製(?)キャッシュダブラー

だからさ、こういうのがパチっぽいつーかいかがわしいつーか、
全般的に神秘がただようMacアーキテクチャの世界なり。

※アイコンパレードでお祈りをかかしてはいけない。あなたの祈りが
 天に届いた時Macのキャッシュは未曾有の性能を発揮するのだ。
 さぁ、祈りなさい。

217マ狂:02/05/16 23:45
祈ろう……

アーメン
218 :02/06/11 03:22
あげ
219●~*
このスレ、密かに旧板で一番好きだ。