「WineでWin64のプログラム実行に成功」記事へのコメント

ふと。

[Anonymous Coward]

ふと思ったのですが、 32bitCPUから64bitCPUにするより技術的に可能で今ならそんなに難易度の高くない256bitCPU（128bitCPUなら前にあったようですが）などを作ったりしないのはナゼなんでしょう。

Re:ふと。

[Anonymous Coward]

TransmetaのCruesorやEfficeonは256bitでしたよ。
x86命令をRISC命令にソフトウェアで変換して内部の256bitSIMD演算器で効率のよい計算をさせるという、
なかなか発想の転換が利いたCPUでしたね。
私も東芝LibrettoのCruesor搭載機に飛びついた口です。
ただ、性能は…微妙でしたが。

やっぱり市場から淘汰されたところをみると
(intelとの競争上負けただけでもっと順当に進化していけば伸びたかもしれませんが…)
演算器を256bitに高めても意味が無かったということでしょうか。
(正確には割り込みの遅さやx86命令のソフトウェア変換のネックなどが原因ですが…)

やはり、メモリやバスやGPUがトータルで広帯域になっていかないとバランスを欠きますし、
今intelのCPUが総256bit化しても誰もメリットがない状況になるでしょうね。
その分消費電力やコストだけ増えてしまいかねませんし、やはり半導体のプロセスの進化も待たないと。

つまり、作っても売れないものは誰も作らないということではないでしょうか(笑)

Re:ふと。

[okky (2487)]

あれは native code を公開しなかったのが失敗だったのではないかと…
安く手に入る初の VLIW CPU だと思って、「native code を実行する方法」が公開され次第、手に入れようとてぐすね引いていたのに… orz

--
fjの教祖様

Re:ふと。

[naruenosekai (13637)]

Crusoe用ネイティブコードが入ってたWinDVDは速かったです｡
それ以外は対応アプリを見なかったなぁ｡

Re:

[Anonymous Coward]

安く手に入る初の VLIW CPU

あまりに恣意的な限定でびっくりｗ

Re:ふと。

[okky (2487)]

うん。

CISC: VAX11/750, z80, 6502, 6809, 68000, 68020, 8088, 8086, 80386, 486, Pentium...
RISC: MIPS, Power Architecture (PowerPC 含む)

とアセンブラを組んだ経験がある私も、VLIW はまだなかったんだ。IA64 はその当時も今も高くて手が出なかったしね。だから Crusoe に関しては、情報公開を本当にわくわくして待っていたんだよ。

# そして、VLIW CPUは IA64 と Crusoe しか、いまだに手に入る範囲には存在しない。

アセンブラでコーディングするのは非常に面白くて。やはりCPUごとにある癖が前面に押し出てくる。抽象化された高級言語とか、Cのように「抽象化されたCPU」に対してコーディングしているような中級言語とかが持っている
「共通部分をくくりだしました」
的なお上品さでは味わえない…んー、なんていうか…香辛料がバリバリ効いた、中華とかだと蛇料理とか蛙料理みたいな部分があって、これはこれで楽しい。
# 仕事でやるには効率が悪い、という側面があるが。

で、この辺のパンチの利かせ方はいろいろな要因で変化するのだけれど、CISC/RISC の差というのはものすごくあって…だからVLIWの「味付け」と言うものも、是非味わってみたかったのだよ。

--
fjの教祖様

Re:ふと。

[hi-kin (11760)]

CrusoeとEfficeonはVLIWプロセッサであって、
256bitのSIMD演算機を持ったRISCプロセッサではありません。
それぞれの命令長は、Crusoeは32bit命令4並列で128bit、
Efficeonは32bit命令8並列で256bitです。

Transmetaのプロセッサは、IntelやAMDのプロセッサのx86命令デコーダ部分と
内部命令のスケジューラ部分をソフトウェアに置き換えたようなものです。
プロセッサがシンプルになるので消費電力が削減でき、将来の性能向上も
しやすくなる。ソフトウェアでx86命令をVLIW命令に変換することで
VLIWの問題である命令の互換性も確保できる。
…と、いいこと尽くめに見えたんですけどねぇ

# VLIWプロセッサとしては、他にIntelのItaniumやTIのDSPなどがありますね。

Re:ふと。

[naruenosekai (13637)]

あれ、SSEや3DNowの命令とかが128bit命令だったハズですけど

また、インテルは将来、AVXやLarrabeeNIで256/512bit命令追加するようですよ｡
Intelヒルズボロが開発するCPUアーキテクチャの方向性 [impress.co.jp]

Re:ふと。

[yosuke2 (30603)]

＞あれ、SSEや3DNowの命令とかが128bit命令だったハズですけど
＞また、インテルは将来、AVXやLarrabeeNIで256/512bit命令追加するようですよ｡

誰かも言ってるようにそれらも128bitとか256bitの精度で計算するわけでは無い。
ただ教授がスパコンには四倍精度が必要だって言ってたなぁ。

Re:

[Anonymous Coward]

最初のころは、64bitレジスタ2個使って128bitなんじゃなかったでしたっけ？＞SSEとか
(最近のは128bitの専用レジスタだったような気も)

Re:

[Anonymous Coward]

>将来の性能向上もしやすくなる。

といっても別にそのチップ自体が将来速くなるという話じゃなく、
Crusoe「系」のCPUが将来速いのが生まれるという話ですよね。

同じ土俵で戦うなら、そりゃソフトよりハードコーディング(?)な本家のほうが高速処理になる(なりやすい)のは当然じゃないっすかね？

あと本家は大手なので、製品の開発改良サイクルは「Transmetaが想定してたよりも」速かったのかも知れない。

同じ土俵でも戦うけど、違う土俵も用意する、という二足のわらじ状態でいくべきだったと思えてなりません。

あるいは最低でも「86えみゅコードのバージョンアップの頻繁さ」を売りにすれば良かったんじゃないかな。頻繁にサービスパックみたいなものを出して、それを導入すれば性能がバンバン(?)上がるのだとすれば、ユーザにとって凄く美味しい話だったはず。

それすら出来てなかったとすれば、単に「ハードよりもハードな(更新が遅い)ソフト」という有りがたくなり呼び方をされる存在でしかないわけで。

Re:ふと。

[hi-kin (11760)]

x86の命令デコーダは複雑でLSIの性能向上の足かせになっているから、
その部分をソフトウェアにしてしまっても、シンプルなVLIW
アーキテクチャで高速なLSIを作ればIntel/AMDのCPUに勝てると
見込んでいたみたい。

最初のうちは低消費電力で名前を売っておいて、将来Intel/AMDの性能向上が
鈍ってくるのをよそ目に性能向上を続けて勝つつもりだったんじゃないかなぁ。