株式会社ヘキサドライブ | HEXADRIVE

桜が咲いたと思ったら急に暖かくなって気分も急上昇ですね
社内の室温も急上昇してきて、タンクトップに手を出しつつある「オクダ」です。
あ！、王子のほうじゃないです。
今回は以前お話ししたキャッシュの話をもう少し掘り下げていきます。
まずは前回の話をもう一度読んで復習してください。
前回の話だと机の上に本を広げるために図書館に本を借りに行き、自宅の本棚に移動、本棚から机の上といった例えでした。
この例えだと、実際に必要な書籍やノート、計算用のメモなどを必要に応じて手近な所に移動し、不要になったら元の場所に戻すようなイメージです。
しかし、実際我々プログラマが扱っているコンピュータの世界でおこなわれている事は、この例とは少し違います。
もう少し具体的に話を掘り下げていきましょう。
コンピュータの世界では、メディアorネットワーク、ハードディスク、メモリ、メモリキャッシュ、レジスタの順にキャッシュすると前回お話ししました。
実際ここでおこなわれているのは、「データを移動」するのではなく「データをコピー」しています。
元のデータはそのままで、コピーしたものを手元に持ってきます。
コピーしてきたものを変更した場合はどうでしょう？
元のデータにも変更を反映させないとダメですね。
逆に変更していなくて当面必要なくなったデータはどうでしょう？
そのまま捨ててしまっても元のデータがあるので大丈夫ですね。
コピーした後で誰かが元のデータを変更したらどうなるでしょう？
もう一度コピーしなおす必要がありますね。
自分がデータを変更していたらどうなるでしょう？
誰のデータを信じればいいのか、、、
ハードディスクからメモリの場合、リードオンリーでファイルを開いたり、ファイルをロックして他の人が変更できなくしたり、ＯＳがうまい事やってくれます。
メモリキャッシュからレジスタの場合、コンパイラがいい感じで動作するようにしてくれますし、スレッド切り替えなどで不都合が起こらないようにＯＳがうまい事やってくれます。
しかし、メモリからメモリキャッシュの場合プログラマが上手にケアしてあげないといけなかったりします。
（ちょっと難しいので読み飛ばしても大丈夫です）
一般的にキャッシュされていない場合、キャッシュ動作そのものが終了するのを待つ必要があります。
必要な事が分かっている部分をあらかじめキャッシュするように準備をしつつ別の処理を行い、必要になった時点でキャッシュ動作が完了しているのが理想的です。
キャッシュ動作待ちを回避できるからです。
当然書き戻しにも時間がかかります。
ＣＰＵによる個体差はありますが、キャッシュしたものは必ず書き戻す設計になっている場合もあります。
変更していない場合、書き戻しを行わないＣＰＵもあります。
一般的に書き戻しはいつの間にか行われていますが、キャッシュが無くなった場合書き戻してキャッシュの容量を確保しないと次のキャッシュが出来ません。
新たにキャッシュをする時に書き戻しが発生する可能性は非常に高いです。
書き換えていなくて不要になったものはキャッシュから捨ててしまえば、書き戻し動作をしないで済みます。

ＤＭＡやビデオメモリとのやり取りなどを行う場合、ほぼ間違いなくメモリとメモリキャッシュとの間に不整合が起こります。
これを整理してあげるのもプログラマの仕事です。
スレッド切り替えにミューテックスやセマフォ、クリティカルセクションを駆使して不具合を起こさないようにするのと似てますね。

これらの事は普通のプログラムをする上で気にする必要はまずありません。
よかったですね。
しかし、描画やコリジョンといった速度を要求される部分や、ハードウェアを直接操作する必要がある場合、不可欠な知識です。
また、キャッシュによる不具合があった場合、知識がないとデバッグできません。
今すぐ必要ないかもしれないし一生無縁かもしれませんが、少しでも興味が沸いたら一度本腰を入れて勉強してみてください。
きっとワンランク上のプログラマになれるでしょう