Simplicityについて

IBM丸山さんのブログより

やはり社内の議論で、複雑になりすぎたソフトウェアをどうしたら簡単化できるか、と言う議論がありました。複雑さを扱う戦略のもう一つの方法は、抽象化です。でも、今のソフトウェアは、OSやミドルウェアの抽象化のレイヤーを重ねすぎて、かえって複雑になっているようです。アブストラクション・リーケージ（抽象化の漏洩）という言葉があって、せっかく抽象化のレイヤーを作って実装の詳細は隠したのに、性能やセキュリティやその他のいろいろな非機能要件を追い求めていくと、結局実装が透けて見えてきてしまう、というものです。

私も同じことを感じています。IBMが推進しているJ2EEにしろ、Microsoftの.NETの世界にしろOS、コンテナ、フレームワーク、アプリケーションコードとスタックが複雑化しすぎています。レイヤーごとに抽象化することによって、プログラムコードの開発者に見える部分が単純化したりポーティングを容易にする効果があるのですが、トラブルの際に低いレイヤー（コアダンプの解析、ネットワークのトレースなど）から高いレイヤーまで見ないと行けないような場合にはこの複雑化した環境に本当に苦しめられます。

以前JavaのVM自体をOSにしてしまおうという動きがありました、Javaの上でコードを書くことを前提にするのであれば、下で動くOSをJVMと一体化したほうが最適化出来てシンプルで良いのでは無いかという考え方です。残念ながらこの試みは普及するには至りませんでした。

最近ではクライアントサイドはWeb、言い換えるとブラウザ自体がプラットフォーム化しようとしてきています。プラットフォームの主戦場はミドルウェアの世界からブラウザ上で実行されるコードの世界に移行してきているように思えます。HTML 5で提案されている機能はブラウザ単体でのリッチな機能の実装を目指しており、OSのレイヤをバイパスしようとする意図が見え隠れします。Java OSが目指したようにブラウザ自体がOSであるという考え方になるのかもしれません。

サーバー側はクラウド、クライアント側はHTML 5対応のブラウザという世界になった場合、開発者の労力は下がりますが、私のような裏方の世界を支えるエンジニアはどうなるでしょうか？現在と同じように裏側のスタックが単純化されていないと苦労は変わらないと思います。ただ、あまりにもバリエーションがありすぎる現在の企業システムがある程度テンプレート化したクラウドに移行することによってサポートしなければいけないテクノロジーパターンが減ることは期待出来ると思います。

仕事で触ったスーパーコンピューター 3 RS/6000 SP2

IBMが作った並列UNIXサーバー。SP2というものがあるからにはSP1というモデルも存在した。SP1はPower1チップをCPUに使っていて、SP2はPower2を使っていた。SP1というモデルは殆ど日本に入っていなかった記憶がある。SP2の後、どちらかというと科学技術ではなく商用のパラレルデータベース用などに使うPower PC版のノードも登場して一時期はかなりバリエーションがあった。IBMがチェスの世界チャンピオンをスーパーコンピューターで負かしたことを記憶されてい方もいるかもしれない。あの時使われたがDeep BlueというRS/6000 SP2をベースにチェス用のVLSIを組み込んだシステムであった。

ご覧のような外観なので口が悪い人は墓石と呼んでいた。この当時既に標準規格のラックマウントサーバーがあった(IBMのRS/6000シリーズでもラックマウントのモデルがあった）のだが、なぜこのシリーズだけ独自のラック（ドロワーと呼ぶ）に入っていたのかは不明だ。確か前面と後面がメッシュのドアになっていて開くことが出来たように記憶している。側面はメッシュではなく、板状になっていた。

ネイビーに見える台座の部分にはハイパフォーマンススイッチ(HPS)という高速なネットワーク装置が入っている。これはLANではなく、それぞれのノードを対等につなぐことが出来るアーキテクチャで常時40MBpsのスループットを出すことが出来た。LANでは通常ある程度の損失があるため論理的なスループットと実効スループットでは差があるのだが、HPSでは論理限界とほぼ同じ実効スループットを出すことが出来た。私がこのシステムを触っていた当時は100Base-Tが存在しておらず、Ethernetスイッチもあまり一般的ではなかったので40MBps=320Mbpsというのは驚異的なパフォーマンスだった。後のモデルではSPスイッチという改良版を採用して150MBpsのスループットが出るようになっていた。

このシステムの記憶はとにかく音がうるさかったことと、MPIと呼ばれる並列ライブラリを使った場合の計算速度の速さだった。私が支援していたお客様のシステムは40ノードで構成されていたので当時ではかなりの速度だった。ただ、世界を見ると当時ハワイにあるマウイ大学に世界最大の512ノード構成のTsunamiというシステムがあり、それと比べると．．．だった記憶がある。また、スイッチの故障の際に中に入っているボードを見たところIntelのチップが入っていたのを見て驚いた記憶がある。SCSI用のチップだったのかRISCチップだったのかは記憶が薄く覚えていない。PentiumなどのPC用のチップではなかったことだけは確かだ。

また、SP2のコンソール（通常のRS/6000デスクトップワークステーション）にNCSAモザイクを導入して、当時自分の会社内でも使えなかった専用線接続のインターネットを体験したのも思い出だ。このSP2システムのノウハウを持っている技術者は日本には殆どおらず情報をインターネットから入手するのが有用な手段だったのだ。当時作られたばかりのYahoo!のサイトなどは１画面で表示できるくらいしかサイトが登録されていなかった気がする。まだWWWとGopherを併用していたような時代のことだ。

今ではこのSP2シリーズは廃盤となっており、IBMのスーパーコンピューターではCPUとしてCellだったりOpteronが使われている。OSも独自のAIXではなくLinuxが使われているシステムが多いようだ。2008年末現在で世界最速のスーパーコンピューターは米国資源エネルギー省に導入されているIBM製のもので1ペタFLOPSの計算能力を持つ。CPUはCellとOpteronを組み合わせている。プロセッサの数は20,000個に及ぶそうだ。

仕事で触ったスーパーコンピューター 2 SGI Onyx

シリコングラフィックス社（SGI）のグラフィックスーパーコンピューターです。オニキスと読みます。

現在でこそノートPCレベルでも3Dグラフィックを簡単に表示することが出来ますが、10年以上前は3D専用のグラフィックボードなどがありました。シリコングラフィックス社は初期のハリウッド製作映画のCGを支えたメーカーでもあります。

上の写真だと今イチ大きさが掴みにくいですが、高さは大人の男性位の高さです。上部はメッシュになっていてブロワー（ファン）が上方に熱を排気するようになっています。このマシンの排気音は私がさわったことがあるサーバーの中でもかなり激しいもので電源投入時の迫力はかなりのものでした。

このシステムで何をやっていたかというと、映画作成ではなくバーチャル・リアリティーです。ある種の非常に習得に経験が必要な技能を3D空間に表示される画像とデータグローブを使って疑似体験させて習得させようとするシステムでした。

このシステムで印象的だったのは3Dのスクリーンセーバーです。SGIの独自UNIX OSが動いているのですが、スクリーンセーバーが動くと3Dのポリゴンで描かれたイルカ（クジラ？）が画面上を泳ぎます。今でこそこの手のスクリーンセーバーはノートPCでも実行できるわけで全く目新しくありませんが、当時はカラーで表示出来るノートPCがやっと出てきた時代なので3Dでスクリーンセーバーが表示されるだけで驚きだった訳です。

その後、SGI社は苦難の道を歩んだようです。何度か倒産をして、最近では高密度データセンター向けサーバーで有名なRackableに買収されました。買収された後の会社名としてはSGIが残ったようですが。

これも有名な話ですが、米国Googleの本社は旧SGIの本社だった社屋を使っています。まさにコンピューター業界の栄枯盛衰が見て取れる場所ですね。

仕事で触ったスーパーコンピューター 1 DEC MasPar

10年以上も前の話になるが、スーパーコンピューター（スパコン）を使用する科学技術計算システムを構築し、その後管理・運用をしていたことがある。そのプロジェクトで触ったスパコンの１つがDEC MasParだった。（写真は私が触った実機ではない）

Wikipediaによると、MasParは1996年に製造を止めているので私が触った機械は生産終了寸前の物だったらしい、日本にはそれほど台数が入っていなかったので貴重な経験をしたという訳だ。

このMasPar、内部には16,384個もの計算ユニットを内蔵していて、それぞれのユニットがグリッド状にクロスバースイッチで内部結線されていた。（機械が故障したときにDECのCEの人が中を開けて中を見たのだが恐ろしく配線密度の高い基盤が多層構造で入っていた）最近のWebの記事でMasParというキーワードに引っかかるものがあってびっくりしたのだが、グラフィックプロセッサーで有名なNVIDIAがMasParの技術者を引き抜いたそうだ。GPUを用いてスパコン的な処理をやらせることが最近流行り始めているので、MasParが用いているSIMDというアーキテクチャーを現代のGPUに応用しようとしたわけだ。

個人的にはこのマシンで開発などはしたことが無いが、root権限を持っていたのでシステムの基本的なところは触っていた。しかしながら、このMasParは16,384個の計算ユニットが動いているところにはシェルからは直接触れないようになっている。フロントエンドにDECのUNIXワークステーションがついていて、MasParへのジョブはこのワークステーションからサブミットする仕組みなのだ。したがって、マシンにログインしても普通のUNIXマシンと何も変わらない感覚で特におもしろいことは無かった。しいて挙げるなら、フロントのDECのマシンのコンソールがGUIではなくVTと呼ばれるキャラクター端末であったことが記憶にある。今でもtelnetなどで端末タイプを決めるときにVT-100などと設定することがあるが、VT-100というのは本当にあったハードウェアの端末なのだ。VT-100はかなり昔のものなので、さすがにMasParについているものはVT-3xxと300番台だった記憶がある。ただ、進化版のVT-3xxでも画面はグリーンディスプレイでキーボードは現代では考えられない非常に無骨なものだった記憶がある。タッチして入力するというよりは叩いて入力するという言葉が相応しいキーボードだった。

Paul Van DykのDJプレイの凄さ

Las Vegas Weeklyのインタービューより

I have two computer systems … midi controller keyboards … a custom-designed mixer … [and] several other controllers with me, and that enables me to basically merge what I do as a DJ with what I do when I’m in the studio making music … I’m a musician, and my favorite music is electronic music, and the most common way of presenting it is DJing. I have the possibility of remixing everything live … The whole experience of the track [and] the whole set is much more intense than just listening to somebody mixing two tracks into each other—that could be another reason why you should come and see me.

普通のDJはターンテーブルだったり最近ではCD-JやPCベースのDJツールでDJプレイをするのですが、Paul Van DykはAbleton Liveというスタジオでの音楽作成まで行えるほどのツールでDJプレイをしています。単に曲のデータを再生しているのではなく、曲の構成要素を分解した状態の素材をリアルタイムにつなぎ合わせたりエフェクトをかけたりししているわけです。そのため、彼のプレイのセットリストをリスナーが作っても聞いたことが無い曲が出てくるので”？”マークが入っていることが良くあります。プレイにはMac Book Proを２台使っていますが、１台のMacがコケてももう１台でプレイを続けられるFault Tolerantなシステムになっているところも凄いです。AppleのホームページでもPaul Van Dykの使用機材や環境についての説明があります。

Windowsのフォント

iPhoneを使いだしてから、iPhoneのフォントがあまりにも綺麗なので仕事で使うWindows PC（Windows XP）のフォントの見難さが気になって仕方が無かった。Twitter経由でWindows XPのフォントを綺麗にするGDI++というものがあるということを知り、wikiを見てみたが安定度の観点から仕事用のPCに使うには怖いと思ったので、フォントのみをWindows Vistaで使われるメイリオというものに変えてみた。結果としてはかなり快適である。ただプロポーショナルフォントを使わないミドルウェアなどのフォントが未解決なので何とかする方法を探したい。