データセンターなど電力効率が重要な環境でのサーバ用途に向けた64ビットARMプロセッサの開発競争が激化しています。

AppliedMicro、Broadcom、Cavium、MediaTek、Freescale、そしてAMDなどがこのレースに加わっています。つい先日Qualcommからも参入の発表がありました。この動きの中、今年の8月、AMDは最新のプロセッサ技術が発表されるHotChipsで彼らの最初の64ビットARMプロセッサ、Seattleを発表しました。

しかし、その発表ではプロセッサ間相互接続（インターコネクト）インタフェイスとして組み込まれるとアナウンスされてきたFreedom Fabricについて何も触れらていません[1]⁠。インターコネクトはサーバ向けARMプロセッサには不可欠の要素です。今後出てくる各社の製品を比較するにはコア数やクロックなどだけでなく、インターコネクトに関する理解が必須です。

筆者は、2014年の3月にFreedom Fabric技術の生みの親であるGary Lauterbach氏（現AMD、Corporate VP & DCSS CTO。以後単にGaryと表記）に取材する機会を得ました。本稿では取材で得られた情報を軸に、Seattleプロセッサの現状や今後の展開について展望を試みます。

SeaMicro のクラスタサーバ

64ビットARMプロセッサの強みはその電力効率にあります。単体処理能力はIntel x86に劣るが、多数のプロセッサを並べて並列分散処理をさせると総処理能力と電力消費の比では64ビットARMに勝ち目がある、というわけです。

つまりARMサーバは必ずクラスタと呼ばれるような多数プロセッサ構成、それもボード上に32個、64個といった高密度実装に向かいます。結果、すべてのプロセッサはI/Oとプロセッサ間通信のために何らかの通信システムで接続することになりますが、これを一般にインターコネクトと呼んでいます。

さて、AMDが Seattleプロセッサに入れるとアナウンスしていたインターコネクト技術Freedom Fabricですが、これはAMD自身が開発したものではありません。

Freedom Fabricはクラスタサーバ専業のベンチャー企業SeaMicro社が開発したもので、AMDはこのSeaMicro社を2012年の春に3.3億ドルを投じて買収しました[2]⁠。そして取材したGaryこそ2007年にSeaMicro社を起業し、Freedom Fabricを開発したその人、というわけです。

SeaMicroの最初の製品SM10000は、Freedom Fabricを使って512個のAtomプロセッサ（ARMではありません）を集積したクラスタサーバです。当時、MozillaがデータセンターにSM10000を導入したニュース[3]を覚えている人も多いでしょう。

AMDは当初からSeattleにFreedom Fabricを組み込むとアナウンスしていたのですが、HotChipsではそのインターコネクトについて言及せず、足まわりとしては2本の10G EthernetとSATA、PCIeだけが紹介されました。インターコネクトの重要性、また買収金額から見ても、このまま何もなしで済ませるとは考えられません。必ず近いうちに Freedom Fabric を含めた製品を出してくるでしょう。

トーラス・ネットワーク

ところでスーパーコンピュータのほとんどはクラスタシステムです。

そこで用いられるインターコネクトの構成に、図1のような2次元メッシュ構成、つまり隣接するノード[4]を直接接続し、離れたノードへは中間のノードに中継してもらう方法があります。

中継に際しては遅延を押さえるために、通常のパケットよりさらにデータを細かく切って送るワームホールルーティングと呼ばれる手法が用いられます。単純なメッシュでは両端のプロセッサで通信を行うと中継段数が増えて遅くなるため、両端（左端と右端、上端と下端）のノードをそれぞれ直接結びつけるトーラス（図2）構成が考案されました。

より多数のノードを短距離で接続するために次元数を増やすことも行われます。京スパコンのインターコネクト、Tofuは6次元のメッシュ/トーラス混成構造です。Tofuの構造は複雑なので単純な例として図3に3次元トーラスの構造図を示します。

Seattleに搭載されるであろうFreedom Fabricはまさにこの3次元トーラス構成＋ワームホールルーティングによるインターコネクトの実例です。SM10000は、8×8×8の3次元トーラス構造で512個のAtomプロセッサを接続しています。

ハードよりソフトのほうが時間が掛かる

さて前置きはこのくらいにして、本題に入りましょう。Freedom Fabricが今回出てこなかった理由、その背景などについて取材を通して筆者なりの解釈を試みます。

筆者はまずFreedom FabricがSeattleにどのような形で統合されて出てくるのか質問しました。

Garyは出荷される製品がどうなるかはわからないとしながら[5]⁠、最初のシリコンでは、Freedom Fabricは動作した[6]が機能しない状態（Unable）だったと答えてくれました。

筆者（以後 Y）：Fabricはとても重要だと思うのですが、どうしてですか。

Gary（以後 G⁠）⁠：ユーザによる。Fabricはエンベッデッド（組み込み分野）では重要ではない。

Seatlleはマーケットのレンジを広げるんだよ。データセンター向けWebサーバ、つまりSeaMicroがやっていたような分野から、エンベッデッドのユーザまでだ。

たとえばコールドストレージサーバのコントローラや、ネットワークパケット処理といった分野ではおそらくFabricはそれほど有用ではない。

そして最初のアプリケーション（適用分野）はエンベッデッドだ。

Y：サーバでなくエンベッデッドなのはなぜですか？

G：ソフトウェアだね。データセンターユーザ（サーバアプリケーションの開発者を指す）はx86のソフトェアスタックを抱えていて、その移植には時間がかかる。エンベッデッドではその製品ごとに独立していて、サードパーティやオープンソースによる部分が多くない。つまり顧客はより速く移植ができる。

Y：うーん、面白いですね。ハードウェアは動いていて準備ができているのにソフトウェアはまだだ、と。

G：（ははは）実際のところSeaMicroでそれを学んだ。適切なソフトウェアエンジニアを雇って、デバッグなどをさせるのはハード開発より時間がかかる。UltraSPARC III 開発[7]の経験でも変な話があった。

（それを積んだワークステーションを）73ヵ国にその国ローカルなキーボードの認定を受けて出荷するのにチップ設計より長い時間がかかった。

Y：（笑いながら）なぜです？

G：認定プロセスが長くかかるんだろうなあ。3年もかかった。本当に驚いたよ。

時々ものごとは直感とは違うように進む。ソフトウェアが前に進むのには私の予想より長い時間を必要とする。ハードウェア開発よりもね。

ARMアーキテクチャへの移行

Y：SeaMicroではホストプロセッサがx86アーキテクチャのAtomでした。SeattleはこれをARMに変えているわけですが、それは大変でしたか？

G：SeaMicroでもまだ出荷していないがARMアーキテクチャの製品はロードマップにあった。ARMへの変更はハードウェアサイドはとても簡単だ。我々のFreedom Fabricアーキテクチャはプロセッサの命令セットには依存していない。

しかし、顧客のソフトウェアはそこに引っ掛かっている。まあ顧客によるがね。ソフトウェアスタックをとてもタイトにコントロールしているところは難しく、早期には動けない。

サードパーティあるいはオープンソースのものも、それらのエコシステム（生態系）ができあがるには時間がかかる。

顧客に（ARMへの移行に関する）強いモチベーションがあるのは確かだが、それでも時間が掛かるのだ。

Y：そのようなソフトウェアの移植を前進させるために最も大きなインセンティブは何だと思いますか。

G：バリューだ。コストパフォーマンス、利益。ARMに移るビジネス上の価値に気がつけば、彼らはやる。

32ビットという障害

ARMへのソフトウェア移行となるとどうしても CALXEDA のことを考えてしまいます。

CALXEDA はクラスタサーバ向けのパワフルなARMプロセッサを開発し、それを使った製品も出つつありました[8]⁠。

一時期は市場で最有力なARMサーバプロセッサベンダーと目されていましたが、おそらくは資金調達の不調によって 2013年末に事業停止となりました[9]⁠。

Y：CALXEDA はなぜ成功しなかったのでしょう。

G：思うに彼らは少しサーバマーケットに対して早すぎたんだ。32ビットアーキテクチャはサーバには適さない。じきに（ソフトの）エコシステムは32ビットのものを開発しなくなるだろう。逆に言えば今は良いタイミングだと言える。AMCC（Applied Micro⁠）⁠、AMDなどがそうで、Seattleは最初の 64ビットサーバクラスARMの1つだと思う。Linuxの移植もあり、エコシステムもそれを開発している。

CALXEDAは市場に対して（ARMだった点で）ほんの少しだけ早すぎたか、あるいは（32ビットだった点で）逆に少しだけ遅すぎたんだ。

Garyはまたサーバ市場における 32ビットアーキテクチャの問題についてSeaMicroでの経験を引いて説明してくれました。

つまりSeaMicroはもともと32ビットのAtomプロセッサを512個搭載したクラスタサーバとして出発しました。

Garyは「いくらかの顧客が使ってみたが、しかし32ビットというのはじつに厳しい制限だった」と振り返ります。

つまりそれがx86互換だったとしても、ユーザは64ビットのコードを32ビットに戻さなければならず、多くのユーザを引き込むのはとても難しかったのだと[10]⁠。

最後にGaryは「つまり64ビットx86から32ビットARMというのはとても大きなジャンプだと思うね」とコメントしました。

インターコネクト抜きのアプローチ

ざっとGaryとの対話を振り返りながらインターコネクトを含めないアプローチについてまとめてみましょう。

つまりサーバシステムの分野ではそのソフトウェア群の変更には時間がかかり、64ビットARMサーバシステムが使われるようになるのもまた遅い。だからSeattleの最初の適用分野はネットワークサーバではなく（ネットワークアプライアンスのコントローラを含めた）エンベッデッドだ、というロジックです。

そしてその用途ではマルチプロセッサは必要がなく（そもそもSeattleは8コアを抱えた、単体でも相当に強力なチップです⁠）⁠、インターコネクトを必要とするような多数プロセッサでのクラスタサーバの出番はその次だ、というわけです。

そう考えれば最初の段階でSeattleにFreedom Fabricが含まれなかったのはわからなくもありません（もちろんFreedom Fabric部分の（周辺ソフト部分も含めた）開発が遅れている、といったこともあるのでしょうが⁠）⁠。

インターネット、オープンソースソフトウェアまわりの人たちは動き始めたら一気に来ます。つまりある日、64ビットARMサーバはその沸点を超えて爆発するのです。近いうちに。必ず。そのため今はシングルプロセッサで良いのでSeattleの載ったボードをできるだけ多く出す。来たるべきその日に必要なソフトウェアが出揃って、インターコネクトのチューニングを含めたツールセットが分厚く用意されていることを目指すのです。

筆者もその日を楽しみに、Freedom Fabricが出てくるのを待ちたいと思います。

後編ではFreedom Fabricに流れるスパコン技術の血と、SeaMicro社の起業にまつわるエピソードなどを紹介します。こちらも楽しみにお待ちください。