ハード／ソフトの垣根を越えた、ユーザセントリックなサーバ機の開発：特集：業務革新を支える最新サーバテクノロジを追う（2）（1/2 ページ）

　前回は富士通がSPARC M10で目指す、基幹業務系システムの集約と新たなエンタープライズでのビッグデータ活用の可能性を中心に紹介した。

　本稿では、富士通が情報系のシステムを統合し、リアルタイムで、かつ同一システム内で実現できるとしている、その技術的な裏付けに迫りたい。プロセッサ開発技術を持ち、次世代スーパーコンピュータプロジェクトをやり遂げた同社らしいアプローチである。

　SPARCはもともと、サン・マイクロシステムズ（当時）が作り出したアーキテクチャだ。富士通の研究開発拠点になっている川崎工場の技術者たちは、その初期からSPARCアーキテクチャのプロセッサ開発に関わってきた。

　本稿を執筆するにあたって取材に対応いただいた富士通 プラットフォーム技術本部 プロダクトソリューション技術統括部 部長 志賀真之氏も、開発に携わってきた生粋の技術者の1人だ。

富士通 プラットフォーム技術本部 プロダクトソリューション技術統括部 部長 志賀真之氏

「ハードウェア屋さん、よくやったな」

　「僕から見るとハードウェア屋さん、よくやったな、と思いますね」（志賀氏）

　これがSPARC64 XおよびSPARC M10を見たときの志賀氏の感想だ。

　これまでのCPUアーキテクチャは、処理性能の課題に対してハードウェア側で新しい命令セットを作るなどの対策をする例が多かった。

　OSなどのソフトウェア開発者側は、そうしたハードウェア側の要請に則した開発を迫られるが、例えば下位互換や既存資産の問題を前に、完全にハードウェア側の要請には応えられていないことも少なくない。ところが、SPARC M10を構成するハードウェアとソフトウェアの関係はそれとはまったく異なったものだ。

　「Software on Chipの面白いところは、ハードやファームといったサーバの技術者がソフトウェアベンダと一緒になって、ハードウェア性能をより生かすためにソフトウェア側をどう改良すればよいかを、本気で議論したことにあるんです」（志賀氏）

　ソフトウェアエンジニアにとってはあまり想像したことがないかもしれないが、プロセッサ開発者からすると、ある処理に対して何クロック位の負荷が掛かるかはおよそ見当が付くものだという。ソフトウェアを作る側からすると、ロジック通りにプログラムを組んだとしても、コンパイラやライブラリといった、ハードウェアとの間を隠蔽する層があるため、実際の物理的な処理の動きはまったく想像がつかないことだろう。

　「ソフトウェア開発に従事する方々は、抽象化されたハードウェアの挙動を意識せず、プログラムのロジックとして最も適当な順番で記述するのは当然のことです。けれども、CPUの特性によっては、ある命令の呼び出しの順序を変えるだけで処理が改善するようなケースが、実際にあるのです」（志賀氏）

　確かに、コンパイラの解釈によって処理速度が変わるといったことは理解できる。しかし、やはりプログラマにとっては、用意されたライブラリを使って、可読性を重視して実装することはあっても、あるライブラリを使って何かの処理をしたときに実際にはどんなシステムコールが走っているのか、どうレジスタを扱っているのかといったことまでは逐一意識をすることはないだろう。

　だけどね、と、志賀氏は話を続けてくれた。

　「富士通の中でプロセッサを作っているチームには、ソフトウェア側の挙動を理解してハードウェアを作れる技術者がいるんです。それって、実は「京^（1）」を開発したときに培ったノウハウなんですよ」（志賀氏）

　つまり、SPARC M10では、ソフトウェア側だけではなく、ハードウェア側の開発者がソフトウェア側に深く入り込んだ形で開発が進んだのだという。

　こうした開発チーム体制で製品化されたSPARC M10を見たときに、志賀氏が冒頭に語った「ハードウェア屋さん、よくやったな」という感想が生まれた。