アカウント名:
パスワード:
例えば、TransmetaのCrusoeは、VLIWチップ本来の命令セットである「ネイティブモード」で動かすと、 同じ事やらせてもコードモーフィングで変換して実行する時よりも性能が落ちるそうで。 VLIWは命令が大きくてFetchするのにも大きなバス帯域を喰いますから、それが結構重い負担になるようです。
その話をもう少し聞かせてください。というか、私が思っていたのとアーキテクチャが違うので戸惑っています。
私が思っていたのは、Crusoe には VLIW 命令セットしかなくて、VLIW 命令セットで実装されたインタプリタが動いている時間帯と VLIW 命令セットにコンパイルされたコードが動いている時間帯があるという動作でした。つまり、いつでも VLIW 命令を Fetch している動作だと思っていました。
VLIW 命令の中を埋められないのはそうだと聞きましたし、コードモーフィングは実行時情報を使って最適化(そもそも計算をしない、等)もできる可能性もあると聞きます。でも命令セットが2系統あるという話はちょっと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
IAとSPARCしか触ったことのない者の戯言 (スコア:2, すばらしい洞察)
本当にIAだけでいいのかと思うときがある。
どのアーキテクチャでも得手不得手はあるわけだから、
単一で賄おうとすることもあるまいに。
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:0)
実際組み込みでPPCとかMIPSコアのサードパーティの石の低レベル部分とかをハイエンドアプリ搭載の基板向けに弄っていましたが、クロック対処理能力比でいうとIA32ベースよりも数段上でした（って、基本となるチップの世代が１世代は違いますからね…）
まぁ、そういう事を考えると、SunがRISC（ですよね？）MPU開発事業を再開したというのは、ハイパフォーマンス市場に対応するために高クロック化しすぎて熱の面で厳しくなりつつあるけどIA系の次にユーザエンドでは使われているPPC系に対抗可能なニーズが確実にある。と読んだのでしょうね。
# でも、「OSもアプリもJavaで書け」とかなったりしたら(^_^;
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:1, すばらしい洞察)
いまどきこんな投稿をするひとが存在することにびっくりです。
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:1, おもしろおかしい)
A. CISCはRISC的間違いを犯し、RISCはCISC的間違いを犯すものなのです。
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:0)
現在のx86は、複数のRISC命令を1つのCISC命令に「圧縮して」主記憶においてる
ようなもんだから、インストラクションを演算コアに流し込む速度で、絶対的な
優位があると思います。
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:1)
クロック対処理能力比の問題もありますが、どちらかというとCISC命令からRISC命令にデコードしている関連で色々とややこしい処理なんかも行わなくてはいけなくなって、１コアあたりのトランジスタ数がRISCで性能ー消費電力の比率がよろしくない（CISCでも特にx86_64系のMPUなんかは最近は製造プロセスの微細化やロジックの最適化でかなり改善はされていますが…）あたりが主眼のつもりで書いたのですが…
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:0)
確かにx86のデコーダは複雑ですが、1クロック1,2命令のデコーダであれば最近(ここ十年の)プロセスでは他の命令セットと比べても微妙な差にしかならないはずです。
そして、デコーダを抜けてしまえば命令セットがRISC系でもCISC系でも大して変わらない処理になります。
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:0)
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:3, 興味深い)
基本思想は
・利用頻度の少ない高機能命令の実装をばっさりカット（これが縮小命令セットと言われる理由）
・命令が途中でつっかえたりしない効率的なパイプライン運用ができるハードを作る
・そのために必要なチューニング等の難しい部分はコンパイラーにおまかせ
で、
実際の実装は
・単純な命令しか用意しないかわりに、１マシンサイクルで必ず１命令を実行させ、限界までCPIを稼ぐ
・命令を処理しやすいように１命令１ワードに納まる固定長の命令セットにする（即値も命令コード内に含める）
・マイクロコードによる複雑な命令解析は諦め、直接ワイヤードロジックで制御回路を組んで高クロックで実行する
（もともとマイクロコードを入れていたはずのメモリ部分は巨大なレジスタセットとキャッシュメモリに充てる）
・演算操作はレジスタ間のみに限定、メインメモリは遅くてアクセスが間に合わないのでオペランドにしない
・メモリとレジスタ間のデータ転送はロード＆ストア命令だけに限定、アドレッシングモードは最小限にする
・必要なら、パイプラインをストールさせないために分岐予測や遅延分岐を用いる
という感じでしょうか。
現在ＲＩＳＣだと自称するプロセッサのほとんどが、このルールのどれかに違反していますが…。
PowerPCなんて、物凄く高機能な命令が「これでもか！」というほど用意されてますし。
組み込み向けRISCプロセッサも多くが16/32Bit可変長命令をサポートしていたりするわけで。
逆に、単純命令のワイヤードロジック制御による実行なんかは、i486あたりからx86系プロセッサも採用していて、
CISCプロセッサだとは言われますが、キャッシュにある単純命令を１サイクルで実行可能だったはず。
メーカーが自社のチップをRISCプロセッサであるとカタログに謳っていたとしても、ほとんどのケースが
「ＲＩＳＣ風味がたくさん入ったアーキテクチャです」という意味にすぎないと言えなくもない。
結局、「RISCプロセッサです」と書くと、カスタマにも「ワークステーション等に使われているような
高性能なCPU設計を取り入れた製品だ」と思ってもらえるからでしょうか。セールストークとしては効果的だよね。
RISCは１サイクルに１命令しかFetchできないって話がありましたが、VLIWなんかは多数の命令を１命令に
パックしたものなので、等価的に多数の命令を同時実行していると思います。ですが、この方式は
実行ユニットに命令を埋めていくのが大変らしいとかで。
例えば、TransmetaのCrusoeは、VLIWチップ本来の命令セットである「ネイティブモード」で動かすと、
同じ事やらせてもコードモーフィングで変換して実行する時よりも性能が落ちるそうで。
VLIWは命令が大きくてFetchするのにも大きなバス帯域を喰いますから、それが結構重い負担になるようです。
となると、CISC的な高機能命令セットでバスに負担をかけないコンパクトな命令列をCPUへ読み込み、
命令デコーダで複数の内部RISC命令に分割して実行ってのはバス帯域を圧迫しないという点で、
あながち間違ったやり方ではないのかもしれません。Pentium4なんか内部命令に変換したものを
そのままトレースキャッシュとしてまるごと保持して次からデコード抜きで実行したりしてますし。
Athlonみたいに演算ユニットが９つもあって、それをみんなVLIWで制御するとなると、VLIW方式を採用して、
全てに毎回命令を割り当てて完全な制御下に置くことを考えると、とんでもない長さの命令が必要になりますから、
結局、今のような実装でいいのかなという気もします。
オフトピ: Crusoe の話をもう少し聞かせて (スコア:2)
その話をもう少し聞かせてください。というか、私が思っていたのとアーキテクチャが違うので戸惑っています。
私が思っていたのは、Crusoe には VLIW 命令セットしかなくて、VLIW 命令セットで実装されたインタプリタが動いている時間帯と VLIW 命令セットにコンパイルされたコードが動いている時間帯があるという動作でした。つまり、いつでも VLIW 命令を Fetch している動作だと思っていました。
VLIW 命令の中を埋められないのはそうだと聞きましたし、コードモーフィングは実行時情報を使って最適化(そもそも計算をしない、等)もできる可能性もあると聞きます。でも命令セットが2系統あるという話はちょっと。
Re:オフトピ: Crusoe の話をもう少し聞かせて (スコア:1)
仕組み的にコードモーフィングでVLIMのFetchはキャッシュの効率がすごく良くなると思うので主記憶から全てを持ってくるのに比べたら、それなりの違いが出てもおかしくない。
命令セットが2系統あるというよりも、コードモーフィングの実行を前提にした特別な仕組み(特権命令とか割り込み)があるんじゃないでしょうか。
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:0)