それに対して、Jz4725B は、160nm プロセスルール。 データシートではやはり 360Mhz になっている。メモリは、SDRAM 16bit アクセスしかできない。
前に書いた内容の焼き直しだが、同じクロックの場合、どれぐらい性能的に不利なのか考察してみよう。
- CL=2 の場合、READ -2/WRITE -1 にできる。(同じ ROW なら READ -1/WRITE 0)。 166MHz 品の SDRAM を使っている場合、133MHz CL=2 が可能(な場合が多い)。
ここは、133MHz CL=2 を前提にする。 - 32bit アクセスは 14 クロック、16bit アクセスは、25 クロック。
Jz47xx の場合、キャッシュラインのサイズは Iキャッシュ/Dキャッシュ共に 32 バイトなので、通常 32バイト単位での READ/WRITE になる。
- Linux で CONFIG_MIPS_L1_CACHE_SHIFT=5 という風に設定しているし、32 バイトなのは間違いない。
そして、Programmers Manual に CPU がどのようなアクセスをするかの記載がある。
SDRAM は、1,2,4,8-beat の burst アクセスができる。32bit アクセスなら 1 回のアクセスで済むわけだ。16 bit アクセスの場合 たぶん 2 回の 8-beat アクセスをする。ただし、2 回目は 同じ ROW なので少し速い。
CL=3 だとして、32bit アクセスの場合 32 byte の READ/WRITE は 16/15 クロック。16 bit だと 16 クロック+11/12 クロック。
そうすると 32 bit アクセスの Jz4740 に対して Jz4725B は最大 25/14 = 1.79 -- 1.79倍 遅いことになる。ただし、まったくキャッシュにヒットしない場合の性能差。
帯域に変換してみよう。133MHz のクロックで ずっと 2バイト読み込めるとすれば、254MB/sec 。32 bit アクセスの場合 254 * 16/14 = 290MB/sec 。16 ビットなら 254 * 16/25 = 163 MB/sec 。
では、実際はどれぐらい違うのか？
仮に ｎ% ヒットするとする。
100 命令実行し キャッシュがヒットした場合 1 クロックで実行できているとする。(100 - n) 個の命令は、メモリアクセスの分待たされるとする。そして、メモリアクセスは、追い出して読み込む動作とする。さらに、SDRAM のクロックは、CPU クロックの 1/3 に設定されているとする(CPU 400MHz に対して SDRAM 133MHz)。
100% なら 100 クロックで終わるところが...
32 bit アクセスの場合は、14 * 2 * 3 * (100 - n) クロック 余分に時間がかかる。 16 bit なら 25 * 2 * 3 * (100 - n) クロック。
n が 99 なら 184:250 。99.9 なら 108.4:115.0。
n が 90 しかないとすると 940:1600 。
動画の再生のヒット率は、かなり高いとは思うが、よくは分からない。仮に 90% だとすると Jz4725B は、1.36 倍 遅いことになる。99% なら 1.06倍 。
さて、最大のクロックは プロセスルールに比例するとする。
Jz4740 の 180nm に対し Jz4725B は 160nm だから Jz4740 が 400MHz なら Jz4725B は 450 MHz 。1.13 倍 速い。
速く動かしたいソフトのヒット率が 99% ぐらいなら相殺できそうな感じ。-- でもそううまいこと行くかどうか。
いろいろ眉唾ものの仮定を入れているので、結論も眉唾だが、必要なデータが揃えば大分分かってくるとは思う。-- ただ、そのときは結果が分かっているはず。上記の考察は結果を分析するとき役にたつ程度だろう。
他の見方をしてみよう。90% しかヒット率がなければ、32 bit アクセスでも 940 クロックかかる。これが 99% にできると 184 クロックで済む。実に 5.1 倍も速くなるのだ。
32bit アクセスでも メモリアクセス 1 回が 84 CPU クロック。チューニングに於いては、まずメモリアクセスを減らすのが重要だ。
さらに言うと十分チューニングされた(動画とかエミュレータ)ソフトなら 90% しかヒット率がないということはないはず。もし、90% だったら オーバクロックに期待するより真っ当にチューニングしたほうが良い。
ただし、ブラウザとか巨大ソフトは例外。遅くともチューニングしきれないし.. そもそも動かそうとするのが間違っていると考えることにしよう。
ちょっと動画について考察
IPU を使うとして、動画のためにどれぐらいのメモリ帯域を使うのだろう？
640x360 のデータを YCbCr(4:1:1) として 30fps で出力するとする。640x360x30x (4+1+1)/4 = 10MB/sec これは read-write になるから 帯域としては x2 の 20MB/sec 必要。入力は1/10 に圧縮されているとすれば、1MB/sec 。
で、前のフレームを参照するとすれば、10MB/sec でも読み込む。(こちらはダーティにしないので 帯域も 10MB/sec)
残りが全部キャッシュに載るはずはないのだが .. ここまでで 31MB/sec 。ちなみに IPU を使って 400x240 R5G6B5 に展開しているとすれば、読み込み 10MB/sec , 書き出し 5.8MB の帯域を脇で使っていることになる。さらに、フレームバッファも 5.8MB/sec で読み込んで 外部に出力している。入力データ 1MB/sec も どこかから読んで DMA で WRITE しているはずなので 足しておこう。
そうすると CPU の邪魔をしている要因として 22.6 MB/sec の帯域が使われている計算になる。
TECH I Vol.39 MIPSプロセッサ入門 - 補足説 - キャッシュ操作の詳細 というのを発見。
キャッシュは 強制的に 無効にできるし、(当然かも知れないが)ダーティでないキャッシュは write-back されないようだ。
ここまでで、使っているメモリ帯域は、53.6 MB/sec 。全部で 163 MB/sec しかないのだから結構な割合だ。
キャッシュには Iキャッシュもある。16KB しかないから当然足りないのだが、処理ブロック毎にループしているはずで、1 ループで載り切らないことがない限り問題にしなくとも良い。
あとは、データ。ワークとして使う領域がある。16KB しかないキャッシュに載るとは思えないが、あまり メモリとの出し入れが多いと メモリ帯域を食いつぶしてしまう。さらに カーネルやら サウンド処理やら動いているわけで、余ったメモリ帯域で 動いてくれないといけない。
ざっと見て相当に厳しそうだ。Jz4755 などは、32bit アクセスで 768p が再生できるとしているので メモリ帯域が足りなくなる とはあまり思わないのだが ... 相当にチューニングしないと Jz4725B で 360p の再生は難しいのではないかと思えてきた。
もちろん CPU として、能力が足りているかどうか という問題もあるのだが、キャッシュにデータが載らなければ CPU は動けない。メモリのほうも重要なのだ。
