アカウント名:
パスワード:
インテルでも昔Core i7-5775Cに128MB載せたりしてたよね
インテル® Core™ i7-5775C プロセッサー [intel.com]を見ると、cacheは6MBで、128MBはグラフィク用のナニカのようですよ。
i7 5775C(Broadwell)のEmbedded DRAMはVRAM兼L4Cacheとして動作します。 こちらの記事でもCPUZで「L4 Cache 128MB」で認識してるのが見れますね。
これのおかげで前世代のi7(Haswell)よりも低クロックでほぼ同等性能を確保していました。が、高クロック品が採れないBroadwellであるが故の苦肉の策とみられています。
eDRAMをL4として利用できるのはBroadwellだけでしたっけ確かそれより後のモデルは純粋にGPU用で動いてたようなそうじゃないような
へーへーへー(AA 知らなかった。自分はcacheは大型化するとキャッシュミス時のペナルティも大型化するので、でかけりゃいいってもんじゃないと考えてます。AMDのcacheは大型化しても実行時ペナルティが表面化しているように見えないのでうまいこと制御してるんでしょうね。
キャッシュミス時のペナルティが増大するんじゃなくて、リードレイテンシが増大するんだけどね。
キャッシュするデータ間違えたらメモリアクセスするからキャッシュサイズは関係ないよね。
IME使うような日本語環境では頻繁にキャッシュが流されて英語環境で取るベンチのような性能は出ないとか昔見ましたけど今は多コア化してるし特に対策考えなくても問題なかったりするんですかねこの辺
近頃はMB単位で積んでるから昔みたいには影響ないんじゃね
IME専用に1コア割り当てたり、IME専用マイクロアーキテクチャが登場したりする時代が来る!
CJK環境で負担が増えるのは、データ量でも計算量でもIMEよりフォントのレンダリングの方が圧倒的に大きいと思う。
キャッシュっていくらかのブロック単位で管理してるんじゃないのかなって思うんですがペナルティやレイテンシに影響ありますかね?
どこにどのアドレスのキャッシュがあるのか。DBでいうインデックスがあるわけですよ。容量増えた時にどうなるのか、想像してみれば状況がわかりませんか?
そういうのってCPUがほぼダイレクトアクセスな探索してくれるんじゃって思うんですけどどうなんでしょう流石に線形で負荷が増えることはないでしょうし
教科書にちゃんと書いてありますが、なぜバカは読まずに議論ができると思うのでしょうか。
調べましたけど単純なインデックスじゃなく、マスクアドレスでタグ付けしてダイレクトアクセスするので線形じゃ増えないっぽいですね。way数がインデックスにあたりそうですがこれも線形探索かどうか、どこまで効率化されてるか不明ですし、容量が増えればway数増えるという単純なものでもなさそうです。
一定のレイテンシを維持して容量を増やそうとすると、容量Nに対して配線数がN^2のオーダーで増えちゃうんですよ。配線数が増えないように共有すると、配線あたりの負荷容量が増えて速度が出なくなる。だから、低容量高速なL1から大容量低速なL3まで階層構造にしてあるわけです。
従来は100MBなんて実装しようとしたら、L3よりレイテンシ大きいL4にせざるを得なかった。特にeDRAMなんてSRAMより遅くて消費電力大きいので、メリットが薄い。今回は3次元実装で配線容量減らしたうえでSRAM使うことで、L3として動作実現できたのが違う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
大容量L3キャッシュ (スコア:0)
インテルでも昔Core i7-5775Cに128MB載せたりしてたよね
Re: (スコア:0)
インテル® Core™ i7-5775C プロセッサー [intel.com]を見ると、cacheは6MBで、128MBはグラフィク用のナニカのようですよ。
Re: (スコア:0)
i7 5775C(Broadwell)のEmbedded DRAMはVRAM兼L4Cacheとして動作します。 こちらの記事でもCPUZで「L4 Cache 128MB」で認識してるのが見れますね。
これのおかげで前世代のi7(Haswell)よりも低クロックでほぼ同等性能を確保していました。が、高クロック品が採れないBroadwellであるが故の苦肉の策とみられています。
Re: (スコア:0)
eDRAMをL4として利用できるのはBroadwellだけでしたっけ確か
それより後のモデルは純粋にGPU用で動いてたようなそうじゃないような
Re: (スコア:0)
へーへーへー(AA 知らなかった。
自分はcacheは大型化するとキャッシュミス時のペナルティも大型化するので、でかけりゃいいってもんじゃないと考えてます。
AMDのcacheは大型化しても実行時ペナルティが表面化しているように見えないのでうまいこと制御してるんでしょうね。
Re: (スコア:0)
キャッシュミス時のペナルティが増大するんじゃなくて、
リードレイテンシが増大するんだけどね。
Re: (スコア:0)
キャッシュするデータ間違えたらメモリアクセスするからキャッシュサイズは関係ないよね。
Re: (スコア:0)
IME使うような日本語環境では頻繁にキャッシュが流されて英語環境で取るベンチのような性能は出ない
とか昔見ましたけど今は多コア化してるし特に対策考えなくても問題なかったりするんですかねこの辺
Re: (スコア:0)
近頃はMB単位で積んでるから昔みたいには影響ないんじゃね
Re: (スコア:0)
IME専用に1コア割り当てたり、IME専用マイクロアーキテクチャが登場したりする時代が来る!
Re: (スコア:0)
CJK環境で負担が増えるのは、データ量でも計算量でもIMEよりフォントのレンダリングの方が圧倒的に大きいと思う。
Re: (スコア:0)
キャッシュっていくらかのブロック単位で管理してるんじゃないのかなって思うんですが
ペナルティやレイテンシに影響ありますかね?
Re: (スコア:0)
どこにどのアドレスのキャッシュがあるのか。
DBでいうインデックスがあるわけですよ。
容量増えた時にどうなるのか、想像してみれば状況がわかりませんか?
Re: (スコア:0)
そういうのってCPUがほぼダイレクトアクセスな探索してくれるんじゃって思うんですけどどうなんでしょう
流石に線形で負荷が増えることはないでしょうし
Re: (スコア:0)
教科書にちゃんと書いてありますが、なぜバカは読まずに議論ができると思うのでしょうか。
Re: (スコア:0)
調べましたけど単純なインデックスじゃなく、マスクアドレスでタグ付けしてダイレクトアクセスするので線形じゃ増えないっぽいですね。
way数がインデックスにあたりそうですがこれも線形探索かどうか、どこまで効率化されてるか不明ですし、
容量が増えればway数増えるという単純なものでもなさそうです。
Re: (スコア:0)
一定のレイテンシを維持して容量を増やそうとすると、容量Nに対して配線数がN^2のオーダーで増えちゃうんですよ。
配線数が増えないように共有すると、配線あたりの負荷容量が増えて速度が出なくなる。
だから、低容量高速なL1から大容量低速なL3まで階層構造にしてあるわけです。
従来は100MBなんて実装しようとしたら、L3よりレイテンシ大きいL4にせざるを得なかった。
特にeDRAMなんてSRAMより遅くて消費電力大きいので、メリットが薄い。
今回は3次元実装で配線容量減らしたうえでSRAM使うことで、L3として動作実現できたのが違う。