アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
ふと。 (スコア:0)
Re: (スコア:2, 参考になる)
x86命令をRISC命令にソフトウェアで変換して内部の256bitSIMD演算器で効率のよい計算をさせるという、
なかなか発想の転換が利いたCPUでしたね。
私も東芝LibrettoのCruesor搭載機に飛びついた口です。
ただ、性能は…微妙でしたが。
やっぱり市場から淘汰されたところをみると
(intelとの競争上負けただけでもっと順当に進化していけば伸びたかもしれませんが…)
演算器を256bitに高めても意味が無かったということでしょうか。
(正確には割り込みの遅さやx86命令のソフトウェア変換のネ
Re: (スコア:1)
256bitのSIMD演算機を持ったRISCプロセッサではありません。
それぞれの命令長は、Crusoeは32bit命令4並列で128bit、
Efficeonは32bit命令8並列で256bitです。
Transmetaのプロセッサは、IntelやAMDのプロセッサのx86命令デコーダ部分と
内部命令のスケジューラ部分をソフトウェアに置き換えたようなものです。
プロセッサがシンプルになるので消費電力が削減でき、将来の性能向上も
しやすくなる。ソフトウェアでx86命令をVLIW命令に変換することで
VLIWの問題である命令の互換性も確保できる。
…と、いいこと尽くめに見えたんですけどねぇ
# VLIWプロセッサとしては、他にIntelのItaniumやTIのDSPなどがありますね。
Re: (スコア:0)
といっても別にそのチップ自体が将来速くなるという話じゃなく、
Crusoe「系」のCPUが将来速いのが生まれるという話ですよね。
同じ土俵で戦うなら、そりゃソフトよりハードコーディング(?)な本家のほうが高速処理になる(なりやすい)のは当然じゃないっすかね？
あと本家は大手なので、製品の開発改良サイクルは「Transmetaが想定してたよりも」速かったのかも知れない。
同じ土俵でも戦うけど、違う土俵も用意する、という二足のわらじ状態でいくべきだったと思えてなりません。
あるいは最低でも「86えみゅコードのバージョンアップの頻繁さ」を売りにすれば良かったんじゃないかな。頻繁にサービスパックみたいなものを出して、それを導入すれば性能がバンバン(?)上がるのだとすれば、ユーザにとって凄く美味しい話だったはず。
それすら出来てなかったとすれば、単に「ハードよりもハードな(更新が遅い)ソフト」という有りがたくなり呼び方をされる存在でしかないわけで。
Re:ふと。 (スコア:1)
その部分をソフトウェアにしてしまっても、シンプルなVLIW
アーキテクチャで高速なLSIを作ればIntel/AMDのCPUに勝てると
見込んでいたみたい。
最初のうちは低消費電力で名前を売っておいて、将来Intel/AMDの性能向上が
鈍ってくるのをよそ目に性能向上を続けて勝つつもりだったんじゃないかなぁ。