loadとaddの依存関係を解析してpipelineがとまらないようにする話は、耳にタコができるほど聞いたが、addでoperandにaddressをとれるというのは、依存関係の解析の手間が省けるから中の人は楽なのかもしれない。load addって命令が連続しているのを調べて、loadをaddより十分先行させないとaddがメモリ読み出し待ちになってしまうからな。load addが依存しているのをloadさきのregisterとadd元のregisterが同じということからみつけるのと、そもそも1つの演算である場合では後者のほうがはるかに楽だし。
とにかく直交性の高い素片に分解してしまえという考え方は、最終的な演算の直前なら正しいのかもしれないが、プログラムがコンパイルされた時点にすることとして正しいかどうかは疑わしい。実行codeから依存関係を知るコストが高いので。
さらに命令セットの寿命とプロセッサ設計の寿命は前者が圧倒的に長い一方で、直交性をあげることでのゲインの具合とその箇所はプロセッサ設計の寿命に依存していて、商業的には損な選択なのかもしれない。
μOPはよく考えられているのか運がいいのか。命令セットを変えられないのは64bit化のときにIntelがポカをやったことからあまりにもclearだ。しかしまあ、LLしてておもうのは
source code -> byte code -> VM -> x86 instruction -> CPU -> μOP
というたくさんのステップを経て実行されているんだよね~。byte codeと機械語の差って大きいねぇ。VM上でμOPにJITできたら幸せかもしれないが、仕様が公開されることは無いだろうしなぁ。
とまあ、まったくまとまりなくだらだらしてみました。
0 件のコメント:
コメントを投稿