>>545
>>499
>いまどきのCPUでは、プログラムの速度は、
>CPUの演算速度ではなく、キャッシュミス時のメモリアクセスのレイテンシで決まるしさ。
>JavaのVMのオーバーヘッドは、そこに隠れちゃうんですよ。

隠れねっての。nsecオーダーの事象とmsecやsecオーダーの事象を同列に扱うな。
突然「アルゴリズムを支配するのはキャッシュ」って・・・。脳みそあんのか？
おまいさんの話は「VMのオーバーヘッドがキャッシュミスヒットのペナルティレベルの速度の蓄積で隠れる」って、
事じゃなかったのか？アプリを巧く作らないと、キャッシュミスヒット乱発して、そのペナルティを考慮すると、
VMなんて誤差になるって思ってんだろ？

こっちは、そうではなく、アプリレベルの応答速度に求められるオーダーと、
VMに求められる速度のオーダーが「桁違い」なんで、一定以上の速度のプロセッサ
になったら、そんなもんは隠れるっていってんの。
「一定以上の速度のプロセッサ」がキャッシュヒットしようがミスヒットしようが、
期待値道理の性能だしてれば、そんなもんは誤差ってのがアプリレイヤ。応答期待値がmsecやsecの世界。
だから、VMのオーバーヘッド(μsecオーダーの処理)が隠れるっていってんの。
アプリが求める応答期待時間に対して、VM分の処理時間が1%以下とかの話になるから「隠れる」っていってんの。
処理全体に対するVMが閉める時間の比率の話でVMが隠れるっていってんの。

キャッシュのミスヒットの蓄積がアプリに影響を与えるレベルの応答速度の話だと、
そもそもVM自身も「キャッシュミスヒット」を起こす可能性があるんだから、同じ比率で
時間的損失を担ことになるっての。VMの有無を余計に浮きぼりさせるっ中年。

自分、どういう前提でアプリの消費時間考えてるん？一回、ナンチャッテ数値で考えてみたら？
各レイヤの時間オーダーだけあわせて。