![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
途中からだと意味がわからんので。
前章では並列アプリケーションが生成する通信量に注目した。
この章ではなんでそのような通信量が発生するのか深く見る。
どのアプリケーションも無限のキャッシュ（4〜8 バイトの小さなラインサイズ）があるとして、走ってる。 どれだけのプロセッサがラインを共有していて、書き込みによってどれだけ無効化されたかがわかる。
各書き込みに対応する無効化の回数は、書き込まれたアドレスにいる高レベルのデータオブジェクトに戻されてますよっと。
分散処理を無効化してしまう多くのアプリケーションは、小さな無効化が主な原因である。一般的には、移動するデータ、つまりデータオブジェクトが一つのキャッシュから次へ移るような、単一の無効化が原因である。
大きな無効化は頻繁に読み出されるデータオブジェクトに起因する。
これらのオブジェクトが書き込まれるのは比較的まれである。 普通は、広く共有されないか、あるいは頻繁に書かれないと思う。
これはキャッシュ無効式のコヒーレントプロトコルや、ディレクトリ式のコヒーレントプロトコルの強い支え（endorsement）だ。
同期オブジェクトはデータオブジェクトと著しく違う振る舞いをする。
あまり競合（contention）のない同期オブジェクトだと、少しの無効化しか引き起こさない。なぜなら同期オブジェクトを待っている待機者（waiter）はゼロ、あるいは少数だからである。
かなり競合している（high contention）オブジェクトだと、大規模な無効化を起こす。そしてオブジェクトには比較的頻繁にアクセスがある。
この場合、これらのオブジェクトを対象としたハードウェアのサポートが望ましい。
残りのセクション（↓二個）はアプリケーション中に見られる無効化がどんなものか、見よう。パラメータや、プロセッサや問題サイズ、キャッシュラインサイズを変えて。
比較的遅いシミュレーションによる物だったから、比較的小さいデータでやっていた。
キャッシュの無効化に問題サイズが及ぼす影響を勉強するには、同じ環境（同じプロセッサ数、同じ条件）でサイズだけを色々変えて問題を解いてみる必要がある。 ここでは三つの条件、今まで使ってきた物、今までの倍、今までの半分、で実験する。
問題サイズが増加したとき、分散が無効化される一般的な傾向である。原因としては、無効化を伴う書き込み毎に、同じあるいは少ない無効化をもつため。
問題サイズが増加すると、少ない共有オブジェクトが、そして共有されたデータオブジェクトがより狭い範囲で共有される傾向がある。
唯一の例外は LocusRoute である。回路のサイズより、回路の密度が無効化の主な原因となる。
次に重要な傾向としては、問題サイズが増加すると無効化を伴う書き込みの頻度が一定あるいは減少することである。
この傾向は、問題サイズが大きいと通信と計算の比がより有利になることが原因である。
問題サイズが大きくなったとき、多くの仕事は、それまでと同じかあるいはよりよい通信と計算の比を導く。
書こうとしたら、塚田君とかぶってたぜ！
