アカウント名:
パスワード:
例えば、TransmetaのCrusoeは、VLIWチップ本来の命令セットである「ネイティブモード」で動かすと、 同じ事やらせてもコードモーフィングで変換して実行する時よりも性能が落ちるそうで。 VLIWは命令が大きくてFetchするのにも大きなバス帯域を喰いますから、それが結構重い負担になるようです。
その話をもう少し聞かせてください。というか、私が思っていたのとアーキテクチャが違うので戸惑っています。
私が思っていたのは、Crusoe には VLIW 命令セットしかなくて、VLIW 命令セットで実装されたインタプリタが動いている時間帯と VLIW 命令セットにコンパイルされたコードが動いている時間帯があるという動作でした。つまり、いつでも VLIW 命令を Fetch している動作だと思っていました。
VLIW 命令の中を埋められないのはそうだと聞きましたし、コードモーフィングは実行時情報を使って最適化(そもそも計算をしない、等)もできる可能性もあると聞きます。でも命令セットが2系統あるという話はちょっと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
IAとSPARCしか触ったことのない者の戯言 (スコア:2, すばらしい洞察)
本当にIAだけでいいのかと思うときがある。
どのアーキテクチャでも得手不得手はあるわけだから、
単一で賄おうとすることもあるまいに。
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:0)
実際組み込みでPPCとかMIPSコアのサードパーティの石の低レベル部分とかをハイエンドアプリ搭載の基板向けに弄っていましたが、クロック対処理能力比でいうとIA32ベースよりも数段上でした（って、基本となるチップの世代が１世代は違いますからね…）
まぁ、そういう事を考えると、SunがRISC（ですよね？）MPU開発事業を再開したというのは、ハイパフォーマンス市場に対応するために高クロック化しすぎて熱の面で厳しくなりつつあるけどIA系の次にユーザエンドでは使われているPPC系に対抗可能なニーズが確実にある。と読んだのでしょうね。
# でも、「OSもアプリもJavaで書け」とかなったりしたら(^_^;
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:0)
現在のx86は、複数のRISC命令を1つのCISC命令に「圧縮して」主記憶においてる
ようなもんだから、インストラクションを演算コアに流し込む速度で、絶対的な
優位があると思います。
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:0)
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:3, 興味深い)
基本思想は
・利用頻度の少ない高機能命令の実装をばっさりカット（これが縮小命令セットと言われる理由）
・命令が途中でつっかえたりしない効率的なパイプライン運用ができるハードを作る
・そのために必要なチューニング等の難しい部分はコンパイラーにおまかせ
で、
実際の実装は
・単純な命令しか用意しないかわりに、１マシンサイクルで必ず１命令を実行させ、限界までCPIを稼ぐ
・命令を処理しやすいように１命令１ワードに納まる固定長の命令セットにする（即値も命令コード内に含める）
・マイクロコードによる複雑な命令
オフトピ: Crusoe の話をもう少し聞かせて (スコア:2)
その話をもう少し聞かせてください。というか、私が思っていたのとアーキテクチャが違うので戸惑っています。
私が思っていたのは、Crusoe には VLIW 命令セットしかなくて、VLIW 命令セットで実装されたインタプリタが動いている時間帯と VLIW 命令セットにコンパイルされたコードが動いている時間帯があるという動作でした。つまり、いつでも VLIW 命令を Fetch している動作だと思っていました。
VLIW 命令の中を埋められないのはそうだと聞きましたし、コードモーフィングは実行時情報を使って最適化(そもそも計算をしない、等)もできる可能性もあると聞きます。でも命令セットが2系統あるという話はちょっと。
Re:オフトピ: Crusoe の話をもう少し聞かせて (スコア:1)
仕組み的にコードモーフィングでVLIMのFetchはキャッシュの効率がすごく良くなると思うので主記憶から全てを持ってくるのに比べたら、それなりの違いが出てもおかしくない。
命令セットが2系統あるというよりも、コードモーフィングの実行を前提にした特別な仕組み(特権命令とか割り込み)があるんじゃないでしょうか。