遊ぶな、キリキリ働け!(VLIWでのマルチスレッド)   

2004年10月19日



☆パソコン将棋とコラムのネタ選びの関係   
さて、予告通り本番のEfficeonネタをアップしてみよう。

仕事が忙しいせいか、最近はコンバットフライトシムや潜水艦シミュレーション などのゲームをプレイする暇が無いのが残念である。 プガチョフ・コブラ1)とか、もう操縦方法を 完全に忘れてしまっているし、 1プレイで何時間もかかる潜水艦シミュレーションなどさすがにやってられない。

代わりに短い時間でプレイできるゲームとして、気晴らしに将棋をやっている。 まあ、全然ヘボ将棋なんだけどね...

最近の将棋ソフトは侮れないレベルであり、最強モードの場合 実力はアマ3〜4段クラスだそうだ。 実際、最強モードだとてんで歯が立たない。 将棋ソフト購入当時は週末に意地になって最強モードで戦っていたら、 ついに累積40連敗を喫してしまった位だ。2)

うむむ... チェス世界チャンピオンを下したDeepBlueみたいなスーパーコンピュータに 負けるんなら納得もいく。 だが、たかが中古相場数百円の激安CPUに負けると 「自分の頭脳の価値は数百円以下か?」という気分になって非常に悔しい。 なんせ使っているCPUはCyrixIII-600MHzだったりする。

CyrixIII相手でこのていたらくでは... あぁ、ヘボなのね。俺って。_| ̄|○

これだけ負け続けると対戦レベルを落としてプレイすればいいんだけれど、 DeepBlueとかが相手ならばともかく、たかが自作パソコンごときに手心を 加えられるのは悔しすぎるんだなぁ。 「俺様は腐っても万物の霊長人間様だぞっ!」と思ってはいても、 実際石ころ相手に勝てないんだから仕方がない。

そんな性格は、このコラムのネタ選びにも出ているのだろう。

今日は久々に発表のあったEfficeonネタを考えてみよう。 Transmetaが久々に発表を行い、Efficeon-3の概要が判明した事がきっかけだ。 これで、Efficeonシリーズも久々の第四弾となる。

だが、このシリーズは的中率があまり良くなく、 たるさんにとってはある意味で鬼門である。 予想のよく当たるサイトを目指して 単に的中率アップを狙うなら、今までよく当ててきたマザー電源ネタや Hyper-Threadingネタ等を選ぶべきで、 わざわざ的中率の低いネタを選ぶ必要はない。

しかし、個人的興味で言えばEfficeonネタは背伸びしてでも扱ってみたいネタだ。 なぜならば、世間広しといえどこれだけ特徴のある プロセッサは世に二つと無いからだ。

実際、たるさんはCrusoeノートを指名買いしているし、 次のノートに買い換えるときはEfficeonノートに決めている。 実力でPentium-Mに勝とうが負けようがそんなこたぁ関係ない。 好奇心を刺激してくれるアイテムこそ、 ボーナスを注ぎ込むのにふさわしい。 (そう思えば、Crusoeのあの一瞬考え込む天然ボケ動作もご愛敬だ。)

珍品・Crusoeの生CPU
動作原理的には非常に独創的である。

最近の秋葉原は特徴のあるパーツが減って売れ筋ばかりになってしまった。 どこのショップも同じパーツばかりで特徴がなくなってしまっている。 これではわざわざ秋葉原まで高い交通費を出して出撃する意味はない。

CPUもまたしかりである。 intel製CPUは高クロックの力技だし、今のところ今後はマルチコア一辺倒。 AMD系も当分マルチコアで新型アーキテクチャは出なさそう。

しかし、アーキテクチャ的に異彩を放つTransmetaのプロセッサは 「CPUアーキテクチャの世界はまだまだおもしろいですよ。」 と問いかけているように思えてならないのである。 (まさにCMSをハードウエアで実装するようなアーキテクチャを持つNet-Burst系CPUを、 intelが開発するという報道(月刊ASCII-2004年11月号P182の後藤弘茂氏の記事) もあるし...)

☆お勧めの記事で間違いの指摘?   
さて、話はEfficeonネタについて情報を集めていた時のことに戻る。 あるPC情報誌系Webサイトにおもしろい記事が掲載されていた。

それは、 Efficeon大研究という米田聡氏のEfficeon解説記事だ。

この記事はEfficenに関する記事としてはなかなか高いレベルにある。 なんせ、ベンチマークがEfficeonのための特別自作バージョンなのである。 しかも、高級言語ではなくアセンブラレベルで動作内容を吟味している。 通常のベンチだけだったら、「あぁ、またか。」という印象なんだけど、 さすがにこれは凄い。大原氏とかもこの手を使うことがあるが、 プロかくあるべしである。

EfficeonやCrusoeのような動的コンパイラを使用するCPUでは、 初回動作が遅くなる傾向が出る。しかし、実際は普通のベンチでは 初回動作で速度が低下するという傾向はほとんど観察されない。 (これはCrusoeでは確認済み。)

そこでたるさんは、以前Super-piを使用して演算桁数を変えながらベンチ結果を調べ、 他のCPUとの桁数−計算時間の因果関係からCrusoeの性質を調べようとした事があった。 ご存じの通りCrusoeはSuper-piが大の苦手なのであるが、 桁数が多くなれば全演算に対するVLIW命令へのパックの時間が相対的に減って Crusoeが速度を挽回するのでは?と予想したのである。

で、どうなったか?

この記事をお読みの方々の期待通り、その計画は見事に失敗した。 各CPUとCrusoeでは特に際だった違いは見られなかったのである。 もちろんその内容のコラム化はできず、ボツネタになったのは言うまでもない。

このように、通常のベンチマークではCPUトータルの性能を把握することはできても、 その特徴であるCMS+VLIWという方式の本質を捉える事はできなかったわけだ。

しかし、この記事の自作ベンチは初回動作の遅さを ちゃんと反映した結果を導き出しているのである。 これは、さすがというほか無い。 というわけで、この記事、特に自作ベンチの部分は非常に興味深く 読ませて頂いた訳なのである。

ところで、この記事には別の意味でもう一点おもしろい記述があった。 それは、 Efficeonの鍵を握るCMS(2)「誤解されやすいポイントだが、CMSとx86命令(を変換した後のVLIWの命令)は 決して並列には実行されないことに注意しよう (VLIWはハードウェアによる命令のスケジューリングを行わない点がキモだ)。」 という記述である。

この表現は、ひょっとしてたるさんの過去のコラムの事を言っているのかな?  そういえば、記事の題名も「Efficeon研究」で、当サイトの 「Efficeon研究」に非常によく似ているし... (googleで検索をかけてみたが、CMSとx86命令の併行動作について考えているのは、 当サイト以外には無かったしね。)

まぁ、相手はプロのテクニカル・ライターだから、併行動作をしていないと言う 言質をTransmetaから得ているのかもしれないし、その辺りの事情はよく分からない。 しかし、併行動作不可能と考えると矛盾点も出てくるというのも事実で、 (矛盾点については後述する。)なぜ、たるさんがCMSとx86の併行動作が可能と 考えたのかを説明することは、これが正しいにせよ、間違っているにせよ、 思考の過程を明らかにするという意味で価値があると思われる。

☆CMS由来のatomとx86由来のatomの併行動作について再度考える。   
では、なぜ併行動作可能と考えたのか、その動作原理を説明してみよう。

まず、CrusoeやEfficeonはVLIW方式なので、 命令実行時にはatomはすでにVLIW命令中に パックされていなければならないというのは本当だ。 だから、一見するとCMS由来のatomとx86由来のatomは 併行動作不可能であるように見える。 パック完了済みの命令しか実行できないVLIW方式で、 実行動作しながら自分自身の並列性は抽出できないということだ。

しかし、よく考えて頂きたいのであるが、これは VLIWが一つの命令形式でパックされている場合のみに成立する主張である。

EfficeonやCrusoeが動作する場合、必ずしも一つのVLIW命令でパックされている わけではない。動作のギアにより、同じx86命令を実行していても VLIW命令の中身はギアによって全然別物なのである。

Efficeonは4段階のギアを持ち、Crusoeでは2段階のギアを持っている。 同じx86命令から置換されたVLIW命令でも、1stギア・2ndギア・3rdギア・4thギア、 それぞれはすべて異なるatom配列でパックされた別種のVLIW命令である。 (これは当サイトの考え方の骨子となるので、よく覚えていただきたい。)

繰り返しになるが同じx86命令を実行していても、 1stギアと2ndギアでのVLIW命令の中身はまったく異なるものである 事には特に注意して欲しい。

わかりやすく説明するために模式図を書いてみたので下記を見て欲しい。

Crusoeの場合 Efficeonの場合(当サイトでの推定動作)
x86命令のatomへの単純置換とパック
(1stギアのためのCMS)
x86命令のatomへの単純置換と
プロファイリングのためのCMSのパック
1stギアでの逐次実行 1stギアでは並列性が低いため
余った部分にはNOPを詰める
1stギアでの逐次実行 余ったatomでプロファイリングを実施
(2ndギアのためのCMS動作)
並列性抽出とパック
(2ndギア動作のためのCMS)
並列性抽出とパック
(1stギア実行時に併走したプロファイリング情報を利用する事で短時間で処理を完了)
2ndギアでの並列実行
(実行されるのは高並列化されたVLIW命令)
2ndギアでの並列実行
(実行されるのは高並列化されたVLIW命令)
すばやく処理終了!


Crusoeではギアは2段しかない。だから、x86命令はどういう経路で 実行されるかというと図の通りだ。 CrusoeではCMSとx86由来のatomの実行はたしかに交互に行われている。

  1. x86命令を取り出してatomに置換し、逐次実行形式でVLIW命令にパックする。(すべてCMSの動作)
  2. 逐次実行形式のVLIW命令を実行する。(すべてx86由来のatomの動作)
  3. (繰り返し実行部分と判断されれば)逐次実行形式のatomから並列性を抽出し再パックし、新たな高並列化VLIW命令を作る。(すべてCMSの動作)
  4. 高並列化されたVLIW命令を実行する。(すべてx86由来のatomの動作)
ここで注意して欲しいのは同じx86命令をVLIW命令に変換して 実行しているとは言っても、 2.で実行されているVLIW命令と4.で実行されているVLIW命令の中身は 全然別物であるということだ。(2.は逐次実行、4.は高並列実行)

では、Efficeonの場合の推定図を見てみよう。 まず、Crusoeの1stギアでは単純に逐次実行形式でatomを詰め込むだけだったが、 この場合逐次実行形式では並列性が低いのでatomがたくさん余ってしまう。 実行可能な命令を多く持ちながら、多くのatomをNOPで埋めなければならないという ムダが生じるのである。特に8atomを並列化できるEfficeonではムダが拡大する。

では、この余ったatomにCMS動作をさせて併行動作させることは不可能なのであろうか?

VLIW命令は実行時にはすでに並列性を抽出済みでなければならないという 原則を思い出して欲しい。 つまり、この余ったCMSで実行させるatomが同じギアのVLIW命令に 関するものであるならば、確かに併走させる事はできない。 並列性を抽出し並列にパックするためのatomを、 並列性が分からない段階で並列にパックして走らせる事は たしかに自己矛盾を生じるからだ。

しかし、今までのたるさんの記事を思い起こして欲しい。 1stギアのパックのためのCMSを1stギアのx86由来のatomと 併走させると書いた記事は一行も無い。 (このような実行の仕方はVLIW方式では確かに不可能である。) 自分自身をパックしながら実行するとはいっても、 パックと実行が同じギアでなければ VLIWの動作原理とは矛盾しないと考えたのである。

たるさんの書いたコラムを注意深く読んで頂くと分かるのであるが、 1stギアのatomで併走するCMSは2ndギア用VLIW命令を パックするためのものである。 同様に2ndギアで併走させるとしたら、それは3rdギアのためのCMSである。 併走するのは常に1段階先のギアのためのCMSなのだ。 決して自分自身のギアのVLIW命令における 並列性を抽出しようとしている訳ではない事に注意して欲しい。

☆CMS由来のatomとx86由来のatomの併行動作は不可能か?   
Efficeonでの推定動作はこうだ。

  1. x86命令を取り出してatomに置換し逐次実行形式でVLIW命令にパックする。
    同時にプロファイリングや並列性抽出のためのatomも余った部分にパックする。(すべてCMSの動作)
  2. 逐次実行形式のVLIW命令を実行する。(x86由来のatomとプロファイリングのためのatomが併走)
  3. (繰り返し実行部分と判断されれば)逐次実行形式のatomから並列性を抽出し再パックし、新たな高並列化VLIW命令を作る。
    プロファイリング情報を利用するため、この部分の動作は非常に速くなる。
    また、もし高並列化してもまだatomが余っているならば3rdギア用のCMSatomをパックしても良い。 (すべてCMSの動作)
  4. 高並列化されたVLIW命令を実行する。
    (基本的にはx86由来atomのみだが、 それでもまだatomが余っていればCMSが3rdギア用の準備をしても良い。)
さて、このステップをよく見て頂きたい。 1stギアのためのVLIW命令作成と実行のステップは、

  1. x86命令を取り出してatomに置換し逐次実行形式でVLIW命令にパックする。
    同時にプロファイリングや並列性抽出のためのatomも余った部分にパックする。(すべてCMSの動作)
  2. 逐次実行形式のVLIW命令を実行する。(x86由来のatomとプロファイリングのためのatomが併走)
であり、VLIW実行の基本であるCMSによる命令のパック→実行という ステップをちゃんと守っている。

2ndギアのためのVLIW命令作成と実行のステップは、

  1. 逐次実行形式のVLIW命令を実行する。(x86由来のatomとプロファイリングのためのatomが併走)
  2. (繰り返し実行部分と判断されれば)逐次実行形式のatomから並列性を抽出し再パックし、新たな高並列化VLIW命令を作る。
    プロファイリング情報を利用するため、この部分の動作は非常に速くなる。
    また、もし高並列化してもまだatomが余っているならば3rdギア用のCMSatomをパックしても良い。 (すべてCMSの動作)
  3. 高並列化されたVLIW命令を実行する。
    (基本的にはx86由来atomのみだが、 それでもまだatomが余っていればCMSが3rdギア用の準備をしても良い。)
となり、やはりVLIW実行の基本であるCMSによる命令のパック→実行という ステップをちゃんと守っている。

最初の段階で1stギアのx86命令由来のatomが併走しているが、 これは1stギアのatomなので決して自分自身(2ndギア用のatom配列) の並列性抽出をVLIW命令時に 実行しているわけではない事に注意して欲しい。 1stギア、2ndギアそれぞれに分けて考えればCMSによるパック→実行という ステップはちゃんと守られているのである。

わかりやすく説明するため、もっと簡単な模式図にしてみよう。

VLIW+CMS本来の動作 原理上不可能な動作
x86命令のatomへの置換とパック
1stギアでの実行 1stギアのためのCMS
パックされたVLIW命令の実行 処理終了?(これは不可能!)


この図の不可能な例の場合を考えてみよう。1stギア用VLIW命令を実行する際に 「VLIW命令は実行時にはパック済みでなければならない。」という原理原則に 反するため、このようなオンフライトでのCMS実行は確かにできない。

VLIW+CMS方式では図の左の通り「CMSによるVLIW命令のパック→実行」という 筋道を通らなければならないのである。

では、次に併行動作可能と考えている場合を見てみよう。

実行可能な併行動作
1stギアのためのCMS+併行動作用CMSのパック
1stギア分の実行 2ndギアのためのCMS
2ndギアのVLIW命令の実行


キーポイントは、同じ内容のx86命令から作られるとは言っても 1stギアのVLIW命令と2ndギアのVLIW命令は別物であるということ、及び 実行されるタイミングもそれぞれ1段階ずれているということだ。

第2段階では1stギア分の実行と2ndギア分のCMSが併走している。 しかし、青で書いた1stギア動作とピンクで書いた2ndギア動作をそれぞれ見て頂くと 「CMSでパック→実行」というVLIWの動作手順が正しく守られている事に お気づきいただけるだろう。

1stギア用VLIW命令を作成するCMSと同じギアでのx86由来atomを併走させることは VLIW命令の性質上確かに不可能である。 しかし、2ndギア用VLIW命令を作成するCMSと1stギアのx86由来atomを 併走させることは技術上十分可能なのではないだろうか?

☆もし、たるさんがCMSプログラマだったら...と妄想してみる。   
今度は視点を変えて見よう。 もし、たるさんがCMSプログラマだったら...と妄想してみると...

例えば、1stギアのCMSによるx86命令置換作業で x86命令にLOAD命令が見つかったとしよう。 LOAD命令は、もしメインメモリから読み出さなければならないとすると、 最悪数百クロックも待たされる可能性がある命令である。 LOAD命令は分岐命令と並んでパイプラインストールの最大要因である。

1stギアでは並列性抽出作業をしないので、「LOAD命令と他の命令の手順を 入れ替えて、LOAD命令で待たされている間、依存性のない別の命令を パックしたVLIW命令を走らせて時を稼ぐ。」 (つまり、LOAD命令を事実上のプリフェッチ命令にする。)とか 「レジスタに以前の同じ内容が残っていれば LOAD命令をMOVE命令に置き換える。」 (こうするとメモリ→レジスタのデータ転送がレジスタ→レジスタの転送になるので 非常に高速化する。)といった2ndギア以降で使われている回避手法は使えない。

また、何回もループが走っていればLOADされるべき内容もキャッシュに 残っているだろうが、1stギア動作ということは初回動作または 繰り返し動作はしない部分ということを意味するので、 データがキャッシュに残っている可能性も非常に低い。 (これはLOADの内容がデータ扱いだからである。命令ならばCMSのx86-atom置換作業で 最低一度は読み出されているので、アドレスが同じリージョン内ならばキャッシュ にある可能性は高い。もっとも、Efficoenは48atom分の命令キューを持っているので、 わざわざキャッシュから読み出す必要はないんだけど。)

もしここで、CMSのatomとx86由来のatomが併行動作不可能だとしたら、 Efficoenはデータが届くまで数百サイクルを、 ただぼぉ〜っと待っているだけになる。 これでは5.X命令/サイクルはとても実現できないだろう。

ここで、もしたるさんがCMSプログラマだったら... こんな暇な状態を放ってはおかない。 「遊ぶな、キリキリ働け!」とばかり、次のようにパックするだろう。 例えば、こんな具合にである。

  1. 「LOAD命令」+ 「制御レジスタから並列性を抽出すべき命令リージョンの開始アドレスを読み込む。」+「LOAD命令が完了しなくても、かまわず命令を進めるようにフロー制御をCMS用コントロール命令で変える。」
  2. 「命令の相互依存関係の探索。」
  3. 「命令の相互依存関係探索結果のシャドウレジスタへの保存。」
  4. 以下探索・保存の繰り返し
  5. (メモリからデータがLOADされると推定されるサイクルの少し前まで達したら) 「制御レジスタへ次から並列性を探索すべき命令のアドレスを書き戻す。」+「フロー制御をCMS用コントロール命令で元に戻す。」
  6. LOAD命令以降のx86命令を置換したatomをVLIW命令にパック
このパックのキモは、LOAD命令が見つかった時点でこれらのCMS動作用atomを 無条件で追加できるということだ。 なぜならば、命令間の相互依存関係の探索というCMS動作は、その原理からして 他のatomの動作とまったく相互依存性が無いからだ。 (他の命令と異なり、無条件でパック可能である。)

これを、他の依存性のないx86命令(厳密にいうとそれを置換したatom)を 実行させることで代用させようとしても、相互依存性抽出作業が まだ終わっていない1stギアの段階ではそれは不可能である。

また、Efficoenは48atom分の命令キューを持っているので、LOADと異なり 同じリージョンの命令なら必ずすぐ取り出せる状態にある事も重要である。 探索命令が探索する命令群はLOAD命令が取り込むデータと異なり、 1stギアでも必ずすぐに取り出せる場所にある。

この場合、1stギアでのLOADというx86由来のatomの実行と、 相互依存性探索というCMSの作業が 併行して実行されているわけだ。しかし、 この並列性抽出作業は2ndギア動作のための下準備であって、この動作が 1stギア動作を自己矛盾に追い込む事はないと考えたわけである。

また、通常の場合と異なり、この場合では途中で条件分岐が起こって CMSの実行順がメチャメチャにされる心配もないしね。

CMSは本来ROMに固定されて焼き込まれ、動作時にメインメモリにロードされるため、 CMSのためのVLIW命令も単独でしか動作できないと考えられがちなのは よく分かる。しかし、CMSがパックの段階で自分自身の分身を VLIW命令中に埋め込むことは技術的に決して不可能な話ではないと思う。 特に、プロファイリングのためのCMS命令が埋め込まれているといったライトな マルチスレッド動作ならば、導入されている確率は かなり確率が高いと思うのだが...

たぶん、1stギアでのCMSはLOAD命令の様な無駄の多い命令を置換するときは、 CMS命令をあたかもLOAD命令を置換したatomの一部のように扱って LOAD(x86)→LOAD(atom)+CMS(atom)+・・・+CMS(atom)といった形で、 キャッシュミス分を見越してまとめて置換しているのではないのだろうか?

この考え方は、MontecitoのCoarse-Grain Multithreadingと考え方は同じだ。 ただし、どこでスレッドを切り替えるかが事前にわかっているため、 Montecitoの様にスレッド切り替えに際して実行中の内容を待避させるまで 次スレッド投入動作を待つといった必要性がない。(戻すときも同様だ。) 予定調和で動作を進めることができるからだ。 (つまり、切り替えのための専用ハードがずっと少なくてすむ。)

余談だが、2ndギア以降でのループ処理でも同様だろう。 Efficeonではループ回数を推定値固定とし、 間違った場合はロールバックする機能がCMSに 組み込まれていることが明らかにされている。 この場合は、最内側ループに条件分岐が無ければという前提付きではあるが、 併行動作のCMSを余ったatomに組み込める。ループ回数固定なので CMSの動作回数も予定調和であり、予定動作が途中で乱される事がないからだ。

ただし、これは二つの動作がリアルに併行するという意味では Fine-Grain Multithreadingに近いけどね。

まぁ、これはあくまで推測(妄想?)で事実かどうかは全く証拠はない。 しかし、こういったことを考えれば、 少なくとも「原理上はCMSとの併行動作が決して不可能ではない。」 と予想した根拠がおわかりいただければそれでよい。 (もしこのような機能が組み込まれていないとしたら、 それは原理上不可能なためではなく、複雑なCMS処理が却って総合性能を落とす といった技術上の問題であろうと思われる。)

最悪でも専用ハードウエアを装備すればVLIWでもマルチスレッドが可能なことは Montecitoで実証されている訳だし、EfficeonではCMSが一部のハードウエアの役割を ソフトで置換している訳だしね。

☆シングルスレッドで5.Xatom並列は可能か?   
さて、Transometa社によればEfficoenのIPCは5.X命令/サイクルだそうである。 (ただし、それ位の値だということで 詳細値については非常に歯切れが悪いんだけど...)

もう一つのTransmeta社の公開情報に下記の情報がある。 「1st Gearも4th Gearも、全てのケースで 8命令の同時発行を行うようになっている。 ただ異なるのは1st Gearの場合、1クロックで1個のx86命令を処理するよう になっていることだ。」 ( 【MPF 2003 レポート】Efficeon、その全貌に迫る(2) - I/Oも高速化されたCMSより引用) これは、たるさんがそう主張している訳ではなく、Transmeta社が そう言っているわけであるから、 (彼らがウソをついているのでなければ)間違いなく「事実」である。

ここで、もしCMSがx86を置換したatomと併走不可能だとしたらどうなるだろう?

1stギアのCMS動作が8atom並列であるとしても問題は少ないだろう。 CMS自体はTransmeta社が練りに練った高並列高効率動作になっているハズだから、 近似的には8atomとしてもおかしくはない。

しかし、これらのCMSが置換したx86を動作させる逐次実行段階ではどうだろうか?

上記の例の1stギアの場合では、1個のx86命令が常に8個のatomに分解され、 しかも並列性抽出前のもっとも低並列性である1stギアであるにもかかわらず、 それらのatomがすべて同じVLIW命令にパックされている事になる。 そうでなければ「1st Gearも4th Gearも、 全てのケースで 8命令の同時発行を行うようになっている。」 とは言えないハズである。

しかし、これはあまりにも不自然なパックである。

x86命令が単純なMOVE命令の場合は、 atomに置換した後でも間違いなく1atomのハズである。 複雑なx86命令で8個以上のatomに分解される場合もあるだろうが レアケースだし、そもそもその場合でもそれらがすべて並列実行できるわけではない。

例えば、メモリ−レジスタ間の加算命令はそのままatomに分解すれば LOAD命令とレジスタ−レジスタ間加算命令になる。しかし、 これはそのままでは同じVLIW命令中には組み込めない。 LOAD命令とレジスタ−レジスタ間加算命令に依存性があるため、 LOAD命令の組み込まれたVLIW命令の次のVLIW命令に レジスタ−レジスタ間加算命令は組み込まれなければならないのである。

まあ、Efficeonの場合はよく使われる加算命令については LOAD命令ユニット自体も加算演算できる仕掛けが組み込まれていて、 メモリ−レジスタ間の加算命令を1atomで実行できる場合があるそうだ。 しかし、その場合はVLIW中に存在するatomは1個だけとなる。

EXECユニットの支援を受けて1サイクルで実行できる機能を 働かせた場合も同様である。 EXECユニットは整数用・浮動小数点用が各1個なので 最大のパック数は2atom止まりである。

つまり、Transmetaの主張通りだとしたら、x86由来のatom以外に「別の何か」が 併走していると考えないとつじつまが合わないのである。

ちなみに、CMS負荷が実行負荷に対して非常に大きいと仮定すると、 高並列なCMS動作の比率が増える。 これによりCMSと併行動作していなくても矛盾がなくなるという考え方がある。

しかし、思い出して欲しい。 Transmetaは「CMS負荷はそれほど大きくない。」と主張している。 「CMS負荷が高いために低atom動作の比率が薄まっている。」と考えるならば、 今度はこの主張との間に矛盾が生じてしまうのである。

☆原理的不可能と技術的不可能   
さて、実際のEfficeonでの動作は今のところ非公開であり不明だ。 腕のいいライターが「決して並列には実行されない。」と言うならば、 もちろんTransmeta社との取材で裏を取っている訳であり、 絶対の自信のあったHyper-Threadingネタ3) と違って今回はライターの間違いと言い切るつもりは毛頭ない。

しかし、「VLIW方式では原理的に二つのスレッドの併行動作は不可能。」 という意味であるならば、上記の通りそれは間違いであると考えている。 (原理的不可能と技術的不可能は別物である。)

当サイトの予想のように踏み込んだレベルで実装されているかどうかは 推測にすぎないことだが、 Transmeta社は1stギア段階でリージョン内のプロファイリングを行うと発表しており、 少なくとも動的プロファイリング情報収集のためのCMS命令埋め込み程度ならば 間違いなく行われていると考える方が常識的だろう。 特にCrusoeやEfficeonのCMSは一種の動的コンパイラであるため、 高いギアでの最適化には1stギア実行中の動的プロファイリング情報が 必要不可欠である。 (この情報なしには、itanium系CPUの様な静的コンパイラと 変わらないレベルの最適化しかできないハズ。)

そして、プロファイリングは本来のx86命令とは無関係なCMSのための 専用処理であるから、プロファイリングがx86由来のatomと同時実行されていれば これも立派なマルチスレッド(というか、CMSは動作するメモリ領域が ソフト的に分離されているから、正確に言えばマルチプロセス?)である。

というわけで、当サイトの予想は的中しているのか? それとも単なる妄想なのか?... 謎のCPU「Efficeon」の謎が解明される日が待ち遠しい。 (おっ、肝心のEfficeon-3について一言も触れられなかったな。 長くなってしまったので、またの機会と言うことで...)



1)
旧ソビエトで開発された戦闘機Su27(後継機のSu35/37を含む)が得意とする 驚異の空中機動のこと。

機首を90°以上引き上げて急減速した後、失速も上昇もせずにそのまま機首下げして 通常飛行に戻ることができる。 ドッグファイトで後ろについた機体がいたとしても、 これをやられると急減速についていけず追い越してしまうことになる。 (ドッグファイトでは後ろについた方が圧倒的優位なので、前後が入れ替わることは 攻守の大逆転を意味する。)

ほかにもフックとかクルビットといった高機動性デモンストレーションがあり、 他の機体では未だにマネできないとされている。

2)
もっとも、プロ棋士は最強の将棋ソフトに対し飛車角落ち(もちろんプロ側が飛車・角を 落とす。)で互角というから恐ろしい。 将棋ソフトの開発者は2010年までに森内三冠や羽生二冠に勝てるソフトにする と言っているが、このレベルの差を考えるとさすがに難しい気もする。

将棋は取った駒の打ち込みがルールで許されているだけに、読まねばならない手の 組み合わせ爆発がチェスより早く発生する。このため、 ハードウエアにものを言わせた力技の読みがチェスより効きにくい。その意味で スーパーコンピュータもプロ棋士の頭脳に比べればまだまだ赤ん坊なのであろう。

その昔、故芹沢九段が「プロとアマの実力差とは何か?」とインタビューされたとき、 「私と一局将棋を指して、玉が死にたい場所を事前に指定してください。 その場所で詰ませます。」と事も無げに語ったと言う実話がある。 (もっとも、最近はアマの実力が上がって、 プロに勝つアマがぽつぽつ出てはいるが...) コンピュータ将棋は、縁台将棋レベルのたるさんには通用しても、 まだまだプロのレベルには到達していないようだ。

余談だが囲碁はもっと凄くて、本因坊に勝てるソフトになるのは何年後かというと、 「目処すらつかない状況。」だそうだ。囲碁恐るべしである。

3)
マニア心理とはおもしろいもので、Efficeonネタの様に 「このコラムは自信度があまり高くない。」と書くと、 なぜか間違いのご指摘は来ない。 逆に、Hyper-Threadingネタの様に「絶対の自信がある。」と書くと、なぜか 「演算ユニットの有効利用がHyper-Threadingの本質である。 あなたの言うキャッシュミスペナルティーの解消は間違い。」というご指摘を頂く。

自ら間違いの可能性を指摘しつつ書くとご指摘メールは無しで、 自信があって強く書くとなぜか反論が来るのである。 これは本当に不思議な現象であるが、実際そうなのだ。 マニア心理というものは「人の心の不思議な何か」に左右されているようだ。

余談だが、「Hyper-Threadingがキャッシュミスペナルティーを解消する。」 という当サイトの主張は全く訂正する必要が無かった。 なぜならば、後日intelのトップがはっきりと認めたからだ。

「最大の課題は、メモリレイテンシの制約を超えてIPC (instruction per cycle:1サイクルで実行できる命令数)を高め続けることだ。 そして、Hyper-Threadingだと、高メモリレイテンシでも許容できるようになる。 例えば、10スレッドを並列に実行できるなら、1スレッドがキャッシュミスで 待っている間に、ほかの9スレッドを実行し続けることができる。 つまり、事実上、メモリレイテンシを隠蔽できる」 以上はintelのゲルシンガーCTOの言葉を下記より一言一句 そのまま引用させて頂いたものだ。 (引用元文献: Intelがひたすらメモリ帯域の拡大にこだわる理由 )

intelアーキテクトの元締めであるゲルシンガーCTO自身がこう言っている以上、 もはや論争の余地はないのである。

ちなみに、今回のネタの信頼度はHyper-Threadingネタの時ほど高くないので、 間違っていた場合は単なる負け惜しみと思って、 広い心で笑って許してやってくださいまし。(^^;)