アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
参考資料 (スコア:3, 参考になる)
動作周波数をひたすら向上する→物理的な限界に突き当たる。
平均IPCをひたすら向上する→手は尽くしているが、これからの劇的な向上は困難。
といったところで、各社とも正攻法は手詰まりの感がある、といったあたりでしょうか。
命令の並列性をハードウェアにて抽出するSuperScalar型アーキテクチャでは、IPC向上にも
限度がある、といわれています。
並列性抽出をコンパイラに移したVLIW型アーキテクチャは高IPCを実現できますが、その方向
であればIntelもItaniumでやってはいますね。
Re:参考資料 (スコア:1)
バスが64Bitの60/66MHz動作になって一般に普及していた486の32bit/33MHzバスに比べ
足まわりは速くなったが、大きな特徴である2命令同時実行を活かすには、
それなりの最適化コンパイラが必要になった。
両方のパイプラインを動かすため、同時実行できる単純命令をペアにして命令デコーダに
投入できるようコーディングする必要があったわけで。今度はマルチコアで性能を引き出す
最適化コンパイラが要求されているだけなのでは。
ベクトル型スーパーコンピュータだと、ハードウェアの特徴を活かすために専用の
ベクトル化コンパイラなんてものが付属してました。今回もスレッド分割を自動でやってくれる
賢いコンパイラが出てきたらそれでOKのような気がしないでもないです。
Re:参考資料 (スコア:1)
スレッド化する場合、処理の相関関係、データの相関関係を意識する必要があるので
コンパイラというので有れば不可能です
プログラムソースだけでは情報が足りなすぎます。
自動化と言うのであれば、仕様からプログラム自体を自動生成する必要が出てくるでしょう
Re:参考資料 (スコア:0)
仕様レベルの記述ができる、より高級な言語を使えってことになるわけだ。
Re:参考資料 (スコア:0)
シングルスレッドでガチガチにチューニングするより、言語レベルでマルチスレッドがサポートされていて細かい動作が可能なJavaなどでマルチスレッド動作させたほうが開発効率も実行性能も上と。
Re:参考資料 (スコア:0)
それを最適なスレッド/マルチプロセス構成で自動生成してくれるプログラムがいるねって事っしょ
JAVAはまだスレッドを意識した書き方をしないとマルチスレッドにはならないのでは?
Re:参考資料 (スコア:0)
>今回もスレッド分割を自動でやってくれる賢いコンパイラが
>出てきたらそれでOKのような気がしないでもないです。
それに一部類似した自動スレッド生成の研究も行われています [impress.co.jp]。
さすがに処理部分を自動的に別スレッドに分割する、という便利なものではありません。
スレッドのデータロードに関連した命令を拾い出し、サブのスレッドとして前もって
実行することで、「ほぼ確実なプリフェッチを行う」というものです。
当時は将来のHyper-Threadingで採用するという話でしたが、最近はとんと聞きません。
(次世代のNehalemアーキテクチャではHyper-Threadingに似たSMT技術を採用するそう
ですが、そこにまで踏み込むかはまだ不明です)