アカウント名:
パスワード:
コードの最適化をシリコン上でon the flyでやってしまうことがプロセッサの大きな進化です。CISC命令をRISCライク命令に変換、レジスタリネーミング、アウトオブオーダー、データプリフェッチなどなど、最適化の塊です。デコードステージがやたら長く、実行ステージがわずかなのはその証明ですね。
そうして、コンパイラはあまり最適化など考えないでよい方向になってしまいました。それはそれでインストラクションアーキテクチャの意味がより大きくなって良いことではあります。
こってこてのコンパイルをやるというのなら回路図から最適な最適化方法を推定するというのもありかもしれませんが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
回路図の使い途 (スコア:3, 興味深い)
それこそ秘孔を突くような、パイプラインの段数とかも考慮に入れたようなのを吐き出してくれるやつ。
あとは、アセンブラ直書きのライブラリとか。
#某国産RISCチップの機械語を読んで、Cのコードを書きかえて速度アップをさせた経験あり。
#そんなに大きなコードではありませんでしたが。
Re:回路図の使い途 (スコア:2, 参考になる)
速くなると言って、片っ端から再コンパイルしてた記憶があります。
昔では386と486でも高速に動かすにはコードの最適化が必要でだったはずです。
たとえば386ではJumpはDword境界で行ったほうが効率がいいので、
境界整合のためNOPを入れたりしたようですが、486では意識せずによくなったとか、
命令ごとのクロックサイクルを意識することもなくなったとかいうのも
プロセッサの設計からくる最適化ネタですかね。
Re:回路図の使い途 (スコア:1, 参考になる)
コードの最適化をシリコン上でon the flyでやってしまうことがプロセッサの大きな進化です。CISC命令をRISCライク命令に変換、レジスタリネーミング、アウトオブオーダー、データプリフェッチなどなど、最適化の塊です。デコードステージがやたら長く、実行ステージがわずかなのはその証明ですね。
そうして、コンパイラはあまり最適化など考えないでよい方向になってしまいました。それはそれでインストラクションアーキテクチャの意味がより大きくなって良いことではあります。
こってこてのコンパイルをやるというのなら回路図から最適な最適化方法を推定するというのもありかもしれませんが。
Re:回路図の使い途 (スコア:1)
> うことがプロセッサの大きな進化です。CISC命令をRISC
> ライク命令に変換、レジスタリネーミング、アウトオブ
> オーダー、データプリフェッチなどなど、最適化の塊で
> す。デコードステージがやたら長く、実行ステージがわ
> ずかなのはその証明ですね。
そのはずなんですけどね~。コンパイラが最適化を考え
なくていいどころか、プログラマーがCのソースコード上
で、ループアンロールまでやらないといけないのが現実
だったりして。
Pentium4 + IntelC++コンパイラですけど、本当のレジ
スタなんか見えないはずなのに、Cのソース上でループ
アンロールをはじめとする、姑息な最適化が結構効果が
あったりしました。