Reconfigurable Processorを開発するIPFlex(12)

Q:そういえばこの前ちょっとお伺いしたのが、例えば今のDAPDNA2というかDNAそのものは基本的に、Integerの32bitというか、Integerも何もない、要するに32bitでFixed Pointの演算機なので、例えばFloatingが欲しければ二つのPEを使えば、片方で指数、片方で仮数という形になる。ところが、物理量だと最低でもやはりFloatingで。それも32bitだとやはり精度が荒いですから、できれば64bitのFloatingという話になるか、と。

A:あるいは(IEEE 754の)80bitですね。

Q:そうするとやはり現在のDAPDNA2でそのまま勝負してゆくのは辛いだろうな、と。

A:そうですね。少なくともそれを実現するためには、GHzオーダーで動いているデバイスがある以上は、単純計算で我々も動作周波数は300(MHz)とかもうちょっと上げる予定でいますけど。まあ、それにしても数百個同時に動かすような事が出来ないと、お客様から見たら、たいした事ないな、と。特に切り返し構造があって、メモリは中に抱いたままで、大量の演算したいと。

数百並列の下の方でもいいんですけど、これが出来れば逆に明らかに性能差は出せるので、そういった所は検討しています。今のInteger Unitと浮動小数点UnitのAND/ORを取る形で。浮動小数点だけを入れてしまうとそれ以上使えないので、そこはトレードオフになりますけども。ある所はまだ効率よく浮動小数点演算ができますと、それ以外はお客様が要求すれば、レイテンシーが許されるんであれば、浮動小数点向けの整数演算もできて、浮動小数点にも変われるような、一部のユニットを組み合わせするとかですね、そういうやり方はあるかなと思ってます。まぁ浮動小数点そのもの、最低ライン、何十並列とか持たせるというのは、そのままやった方が効率はいいんですけど、プラスアルファのお客様に関してはそこを共存でどっちにも使えると。ソフトマクロみたいな形でですね、そういう解はあるかもしれないですね。

Q:まだそこのところは方針としてはっきり決まってるわけではないと?

A:今、社内の実験データはあります。検討して、例えば90nmとか使った場合に、どの程度まで並列度を満たせられるかとか、ダイサイズはどの位になるかとか。浮動小数点をやる場合、どこまでサポートするかとか。浮動小数点並列演算機を持ってる皆さんが、どの程度の性能があるかとか、その辺は社内的にデータを当然採らないと勝負にならないので、あのプランとしてどこまでやるかっていう、その検討案みたいなものは持ってますけど。ここまでやればこういうことが起こるみたいな。あとはじゃあ、どこまでコスト掛けてどういう形でやるか、と。

Q:要望としてはどうなんですか? まだそんなに多くは無い?

A:いや、えーとですね、研究所が多いせいか、研究所とか大学で広い規模をやられている、なんというか、天文学的な数字をいじってる方っていらっしゃるんですよね、世の中には。

Q:気象とかのシミレーションとかもそうですよね。

A:そうですね。色々な物理現象追っかけている皆さんとか、あるいは人体とかですね、そういうの追っかけてる皆さんとかは、(扱うデータの)ダイナミックレンジが恐ろしく広いので、ものすごい計算やられてる訳です。ちょっとNGなんで、あまり言えないんですけど。そうすると、当然出ますよね。

Q:それはわかります。流体の計算やる時に、グリッドを一桁小さくすると計算量千倍になりますという話ですからね。

A:そういうことを考えると、私自身は(浮動小数点を必要とする)人数は多いかな、と。ただ、会社を創った時には人も少なかったですし、私が浮動小数点をやるんだって言ったんですけど、時代劇じゃ無いんですけど、「殿、ご乱心～!」とかいう話になって(爆笑)。

結局ですね、ウチのマーケッターとかに「そんなマーケットは今のところ無いですから安心して下さい」とか言われまして。今後の課題になってるんですけど、でもまあお客様からは色々聞いているので、次の次くらいでは、一応計画して出していきたい、と。

Q:DAPDNA 4の世代くらいになるわけですね。

A:DAPDNA 3とか4とか、あ、逆だったかもしれませんが。それを入れていきたいと思います。

Q:それだとProcess Nodeが45nm位?

A:うーん、少なくとも65nmとか、そういったオーダーですね。それは一つのチャレンジだと思っていますが、面白いところだとも思っています。むしろそういった所で、大量に入れた時に、「それしか使えない」という所が「それ以外にも使える」に変わるのが大きな強みになるんじゃないかという気はしてます。

Q(編):他社さんのチップですと、Dual VTとか、Critical Pathとかがあるわけですが、そのあたりはいかがでしょう?

A:今のところ我々が使っているのは、富士通さんのASICに使えるようなProcsserでIMACを使っています。で、将来的にどうするかという話は社内でも議論がありまして。特定のパターンで効率がいい所は、カスタマイズする必要があるので、違ったものとか色々検討したいと思ってます。ただProcessを大幅に変えるというよりは、そこのトランジスタのルールを変える。トランジスタと言いますか、プロセス側のルールというよりは、そこを作るデザインのルールですね。あるファンクションを実現するルールをカスタム化して起こすわけですね。メモリなんかもその対象化も知れませんし。というのは、我々から見ると富士通さんは、Standard Cellで当然クオリティってを上げるために、あるDesign RuleでWirelingをあるところまで飛ばせる事を保障したトランジスタというものを設計されてる訳ですね。近くの(範囲しか飛ばせない)ものも、もちろんありますけど。で、Design Toolが優秀なので、比較的効率は上がっているんです。ですが、固定した回路から見ると、明らかにこれ以上Wirelingする距離が伸びないという所もあるわけですね。

繰り返し構造が多いので、そこをどうするのかというのは今後の議論だと思います。で、富士通さんから結構言われたのは、ワイヤリングは多すぎるので、配線自由度が大きくならない、と。そこのコストを結構効率よく上げないと、競争力という意味で結構辛いですと。それはやっぱり両面、アーキテクチャという視点とプロセスをうまく使い切って、競争力高めるという両面からいろいろ検討したいと思ってます。勿論以前からやってるのですけれど、もう少し効率上げて行きたいと思ってます。

将来的には、回路などを生成しては消すといった話ですと、正直言ってその目的の組み方とかある訳です。今のStandard Cellでやる必要が無くなってくるので、その先のことに関しては出来ればそういったことも(考えてゆきたい)、と。ただ、メーカーさんに拠りますけど、それをやるには生産量が1000万個だって話になって来るんですよね。(笑)

我々の会社の知名度がもうちょっと上がって、確かにIMSが100万個とか一千万個というのが本当だろうと。お客さんがそう言ってるんだから間違いないだろうという所まで持っていければ、そうしたチャレンジが出来るだろう、と。まあ(Processが)90nmから65nmとかに変わってきますので、あのチャレンジする仕掛けとしては良いタイミングだと思います。それでやっぱり競争力が上がって来るんだろうということですね。

Q(編):Latencyを遮蔽するようなProcessorというのはどういう形で行うのでしょう? Multi-Threadとか、Out-of-Orderとか。これもConfigurationの際に設計して遮蔽できるという形でやるのでしょうか? それともハードウェア的に何かあるのでしょうか?

A:レイテンシーの消し方の問題ですか? アプリケーションじゃなくて? processer自身という意味では、我々パイプライン段数はそんなに深くないので、レイテンシーに対してのペナルティは、ブランチの時のペナルティ以外は殆ど無い様な。厳密に言うと、どんなprocesserでも、レジスタ間接とかそういった特殊なアクセスを行う場合のAddressing Modeでは、いずれにしてもペナルティは原理的に発生する構造になるんですよね。中で特殊な、分岐予測とかが持ってる場合に関しては、ある程度制限したりとかはできますけど。

おっしゃってる意味がもし、分岐があった場合に違う性質の処理を中で同時にやって、結果的に演算がわかってない限りどっちを取るとかという話だとすれば、それは仕掛けを2つ入れておく必要があります。いわゆる予測しない次解に対してもバックアップして走らせておいて、ユーザーさんがある結果が出た段階でどっちの結果を使うか選ぶと。それは構成上にそういったものを最初から入れておいていただければ、対応は可能です。だから並列時の分岐のペナルティを消すことは一応出来ます。

ただ問題は、トランジスタが有限なので、そこの分岐して可能性の分岐が増えれば増えるほど、1/n個の面積が使える格好になるので、同時にやったとしてもその並列度の単位としては1/n個分のそのトランジスタなり並列機を実行するだけなんです。それでもprocesserより勝てるケース、例えば動作周波数で1桁違ってたりしても、PEが10個位あれば十分ペイするなんて場合、10個分の塊を同時に複数個走らせて、最後生き残ったとかやれば、見かけ上分岐のペナルティが無いような形でレイテンシ0と等価の現象を起こせますから。

今後回路規模が増えてくると、それはむしろ我々の方にちょっと有利だと言えます。これは色々面白い結果がありまして、もう少し後にはもう少し言えるんですが、今のプログラムカウンターがベースの回路の場合、トランジスタというのは基本的に今まで動作周波数上げる方にほとんど使われて来ました、と。動作周波数が飽和してきたので、効率という意味で並列度が性能を稼ぐ所にトランジスタがどれ位貢献しているかというと、むしろトランジスタの貢献度は悪くなってるんですよね。悪くなっていると言うのは、トランジスタの数自体は増えてますけど、それは動作周波数を引き上げるためにパイプラインを30段とかに増やしているので、スループットはそんなに上がっていないんですね。性能のゲインが少ないので、使ったトランジスタの割には、1個当たりの貢献度はどんどん低くなって来て、いわゆるSaturationが発生してます。それから見ると我々の方は、トランジスタを使えるチャンスが増えている分だけ並列度を上げられてますから、性能に対するトランジスタ1個当たりの貢献度というのは、我々の方がはるかにリニアに上がってるんですね。完全なリニアでは無いのですけれど、リニアと言って過言では無いくらいのラインには乗っている。それが今後もどんどんやれます、と。そういった意味では、(パイプライン)段数を増やせば、分岐予測とかをやったとしても、ペナルティが発生するケースもあるので、むしろ(パイプライン段数が)深くなれば深くなって行くほどコストが掛かりますが、我々の方はむしろコストをそんなに掛けずに、高い並列度を維持しながらいろんな場合に対して対応できるような事ができるようになりました。