ユメのチカラ

バザールモデルにおける品質

ソフトウェア開発モデルとしてのバザールモデルというのは従来のソフトウェア開発モデルとまるっきり違うので、簡単に対比して考えてみる。

古典的なウォータフォールモデルでは、工程を要求定義、外部設計、詳細設計、実装、単体テスト、統合テスト、運用保守となる。工程による分割可能で、要求定義を上流工程と実装、テストなどを下流工程と言う。それぞれの工程には明確なアウトプットがあり、要求定義のアウトプットは要求定義書で、それが外部設計のインプットになる。

要求の獲得から実装という一連の流れのなかで、利用者の何らかの問題を解決しなければならないのだけど、要求定義が利用者の要求とかけはなれたものであったら、いくら設計から実装が正しくとも、まったく意味のないものができあがってしまう。要求を的確に把握する事が重要なのだけどそれが一番難しい。

仮に要求定義の時点で利用者の要求を把握していたとしてもウォータフォールモデルでは要求定義をしてから実装が出て運用にいたるまで長い期間がかかるため、その間に要求が変化してしまうこともあり、利用者にジャストミートなソフトウェアを提供することが難しい。

そのためプロトタイプを作って要求の見える化をしたり、素早く実装をくりかえして環境変化による要求変化に追随したりする。

一方バザールモデルはというと、明確な要求定義書とか外部設計書、詳細設計書の類いは通常は存在しない。誰かが問題を発見し、それがバグフィックスであったり、機能的な不備であったり様々なわけであるが、通常は問題を認識した人が実装する。実装者が要求者の場合、実装する人は要求(問題)を正しく認識しているので、要求そのものの齟齬というのは原理的には発生しえない。

機能の需要者が供給者という構図である。

実装については多数の目玉がピアレビューをする。それは機能面と実装面から徹底的にレビューされる。メーリングリストへ、ＸＸという機能を実装したいというRFC (Request for Comments)を投げると様々な観点からのレビューがおこなわれる。実装(パッチ等で提供される場合が多い)についても同様にレビューがおこなわれるだけではなく、様々な環境でテストされるので、機能的な問題、実装上の問題が効率よく発見される。

ソフトウェアのバージョンは安定版と開発版と分離し、通常、新機能については、開発版でProof of Conceptされて、有用性や互換性が検証され、安定版には重要なバグ修正のみを適用することによって安定性互換性を担保している。

リグレッションテストのような自動化した互換性確認というのの適用は今後の課題となっている。

Linuxの品質特性の一つとしてセキュリティについての数字があってWindowsとの比較すると下記になる。

Windowsの脆弱性の緊急度、最高(5%)、高(33%)に対しLinux Kernel 2.6は0%である。狭義の品質不良(機能的不具合)についての定量的データは少ないが、定番のOSSのバグ密度が低い事はよく知られている。

商用ソフトウェアのような予算、スケジュール、リソースの明示的な制約(？)というのはなく自発的な開発者による自発的な開発に依存している。

ただしOSS(オープンソースソフトウェア)だからといって上述したバザールモデルの開発になるとは限らない。むしろ多くのOSSはバザールにならず、ひっそりと誰にも注目も利用もされず忘れさられている。しかしLAMP(Linux/Apache/MySQL/Perl/PHP)等に代表される定番のOSSはバザール開発モデルになっている。

バザールモデルは環境変化、要求変化に対し極めて柔軟にしかも素早く対応する。要求に適合したものがタイムリーにリリースされる。これは通常のウォータフォールモデルによる開発ではなかなか達成できないものである。

このようにバザールモデルで開発したソフトウェアの品質は極めて高いといえる。

なぜソースコードを読むのか？/ユメのチカラ

オープンソースの生産性/ユメのチカラ

ハッカーのつくりかた

先日も朝から3人面接し、午後外出の後、夕方1人とじっくり話しこんでしまい、結局ディスカッションは2時間くらいになった。

まあ、ブレストなのか雑談なのかなんなのかよくわからない面接なのであるが、忘れないうちにブログのネタとして書いておく。

彼は弊社一番のカーネルハッカーでバックエンドチームに所属している。カーネルにまつわるどんな問題も魔法のごとく解決する凄腕である。

わたしの下心としては、彼のコピーをどのようにして作るのかというところにある。もちろん人間のコピーなんていうのが簡単にできるわけはない。しかしそれでも彼の1/10くらいのハッカー予備軍ができればおつりがくる。

カーネルの場合、必要とする知識はユーザーランドのアプリケーションより遥かに広範囲である。知識量勝負の部分がある。詳解Linuxカーネル程度の事は常識として理解していないといけない。割り込みの場合、コントローラのレジスタがどうだこうだという知識も必須である。

ある程度の知識がないと時間ばっかりかかって全然前に進めない。一方で、必要最低限の知識が得られたら、あとはずんずん経験を積んでいくしかない。その原動力は結局のところ、その作業が好きか嫌いかによる。

社内でのカーネル勉強会というのは知識の共有には非常に役にたつが楽しさの共有という点ではどうだろうか。

勉強の方法というか、知識の獲得方法の獲得方法というようなものも必要になてくる。カーネルハッカーが持っている暗黙的な知識や知識の獲得方法を、どうにかして明文化したいというのがわたしの下心なのであるが、カーネルハッカーはそのような事を無意識のうちにやっているので、言語化するなんていうことはあんまり考えたことがないようである。

銀の弾丸はないので、カーネルハッカーのそばに座って、その背中を見ながら盗むしかないのであるが、いかんせんこの方法だとスケールしない。手間暇がかかる。

そこでわたしがカーネルハッカーにお願いしたのは、何らかのトラブルシューティングをしたら、それをケーススタディとして、どのような作業をして、その問題を分析したか簡単(本当は詳細にと言いたいところだけど、ちょっと遠慮した)に記述してほしいと。その記述をもとに皆でそのケースについて議論をしてベストプラクティスを獲得する。

ソースコードのちょっとした読み方のコツとかエディタの便利な使い方とかいうのは、そのケーススタディではごっそり抜け落ちてしまうのだが、それは背中を見ながら盗むか、質疑応答であぶりだしてほしいのだが、初心者は質問ができないというワナがある。

トラブルシューティングの方法を記述するというのは、エキスパートだけではなく初心者にとっても大変役にたつ。初心者は自分の作業をふりかえる良いきっかけになるし、それ以上に、そのプロセスを明示化することによって、ムラ、無駄、無理、などを発見する機会にもなる。明示化されることによって初心者には気がつかない落し穴とかもっと良い方法などがエキスパートによって発見されるようになるかもしれない。

作業の見える化という感じである。

一つの作業が数分で終わるようなものだとプロセスの記述の手間のオーバヘッドが大きいが、複雑な問題だと数時間から数日かかる場合があるので、それをまとめておくメリットは大きい。

ハッカーへの道は遠いが、その一歩としてハッカーがやっている事を観測して理解するというのはあながち遠回りという事はないと思う。

How To Become A Hacker (ハッカーになるために）
Eric Raymond, 12/19/'98

オープンソースマガジン連載「ハッカー養成塾」リンク集

人材

今年にはいってから一対一の面接を延々おこなっている。一人あたり30分から1時間くらいフリーディスカッションをする。真剣に話を聞くので一日4人〜5人もやるとふらふらになる。

わたしの仕事は、顧客に価値を提供することだが、その価値を創造する人材を育成することも重要な仕事である。

ソフトウェア会社はヒトが価値を創造するのだから(製造業は工場がモノを生産するが、ソフトウェア会社は別に設備投資とか莫大に必要というわけではない)、そのヒトがモチベーションを最大化するように考えないといけない。

そのためには一人一人のエンジニアの満足度をキープすることが必要である。

そこで先日そのベンチマークのために社員意識調査というのを人材コンサルティング会社におねがいした。この手のサーベイは継続しておこなわなければ意味がないのだが何事も最初の一歩がなければはじまらない。

アンケートは75項目あって、マネジメントの視点、顧客の視点、業務プロセスの視点、組織と人材の視点という着眼点から質問が構成されている。

スコアのよかったトップ3を見ると
1) 当社をもっともっと良い会社にするために貢献したい
2) 当社では、多様な個性が受け入れられる雰囲気がある
3) 私は、顧客(社内・社外を問わず)が誰であるかを認識している
一方ワーストは
75) 私の周りでは人手はちょうど足りている
である。

弊社のエンジニアはモチベーションが高く、専門性も高いが仕事の絶対量が多すぎるという状況がかいまみられる。

そこで採用がトッププライオリティになるのであるが、それ以上に現状の仕事ぶりを正確に私自身理解する必要があるので、忙しいエンジニアの皆さんに時間をもらって一対一のディスカッションをしている。

十人十色で非常に勉強になる。いろいろな観点からの指摘をうけその度に発見がある。面接そのものはとっても楽しい。

エンジニアはプロジェクトによって成長する。プロジェクトの経験が彼、彼女を成長させる。企業は従業員が成長する機会を提供する義務がある。仕事によって一回りも二回りも大きくなる。

一方でエンジニアはプロフェッショナルとして深い知識、技量、そして志も求められるが、それは自ら様々な方法で獲得するか、先輩エンジニアあるいは同僚部下から明示的あるいは暗示的に継承する類のものである。

各種講習会、セミナー、会社での勉強会、あるいはカーネル読書会のようなコミュニティの勉強会、様々な機会を利用するかしないかは一人一人にかかっている。

弊社ではエンジニアを募集中であるが、びびらないで気楽に応募してほしい。

http://www.miraclelinux.com/corp/recruit/

どうでもいいプチ蘊蓄、i18nの話

読者の皆様、これはブックマークだ。

baccus-dのブログを見ていたらi18nのお話が出ていたので、i18nの起源というプチ蘊蓄を語る。
この起源についての質問はインターネットでも時々間欠温泉のようにわきあがるいわばFAQみたいなものなのだが、90年代初頭にはつかわれていたとかいう証言がえられるが、なかなか起源まで行きつくものは少ない。

これはずばり85年頃のDEC (Digital Equipument Corporation) (後にコンパックに買収され、その後コンパックはHPに買収された)にScherpenhuizenという人がいて、彼のマシン(VMS/DECNET)名にS12Nという名前をつけていた。当時のVMS/DECNETはノード名の制限が6文字だった。なんでS12NかというとScherpenhuizenという名前は最初のSから最後のnまでに12文字あるからである。

この長い名前を(最初の一文字+中間の文字数+最後の一文字)という風に略すやり方は当時のDECでは流行っていて、DECのヨーロッパのソフトウェア国際化チームがそれにならってInternationalizationをI18Nと略すようになった。

当時のDECの社内は全てのマシンがDECNETで結合されていてI18N::というノードも存在した。

------------------
さて上記のような蘊蓄を語ろうと思ったのだけど、記憶が曖昧だったので当然Googleにたよった。しかし、i18nだけで検索したらどう考えても、どうでもいい定義には行きつくが、起源までには辿りつけないと思った。

そこで、自分のはてなの日記(未来のいつか/hyoshiokの日記)をi18nで検索するが回答にたどりつけない。http://d.hatena.ne.jp/hyoshiok/searchdiary?word=i18n

自分はDECが起源であるという正解を知っているので、その知識を利用して、「dec i18n 起源」を検索キーワードとして検索した。

そうすると、http://b.hatena.ne.jp/donayama/20060930というブックマークがあって、その対象がそのものズバリの質問である。

LocalizationをL10N, MultilingualizationをM17N, InternationalizationをI18Nという風に省略しますが、こういう風な表記をし始めた発端、普及した経緯・きっかけなどを教えて下さい。http://q.hatena.ne.jp/1159582709

そして、その第一回答がそのものずばりの回答で、
http://www.i18nguy.com/origini18n.html
である。

Excerpts of the Email Discussionでの登場人物は80年代後半〜90年代にソフトウェア国際化で活躍したエキスパート達である。Jim Melton はDECで ISO SQL標準にかかわり(SQL標準の編集者)、SQLの国際化機能を設計した人、John McConnel、Tim Greenwoodは当時のDECの国際化アーキテクト(わたしもその一人)、樋浦さんはSunの人である。

--------------------
まったくもって思い出モードにはいってしまうのだが、80年代というのはソフトウェアの国際化という概念がまだ確立されていなかった。当時日本DECという外資系に勤務していて、ソフトウェアの日本語化に四苦八苦していたわたしはどうにかしてこの問題を解決したいと強く思っていた。未来のいつか日本語化というような作業なしに英語と同じように簡単に日本語が利用できる世界を夢見ていた。

米国本社と議論をかさねるうちに、ソフトウェアの国際化で苦労しているグループがヨーロッパにいることを知った。わたしにとっては米国も欧州も同じようなものかと思っていたので(われわれはよく欧米と一括りにする)、驚きであった。

ドイツ語、フランス語のアクセント記号やウムラウト付文字は7ビットのASCII文字にははいっていないので、それらの言語が正しく表現できないのである。

ソフトウェアが7ビットASCIIを仮定していたので欧州系の言語ですら正しく表現されないというのが80年代初頭の状況であった。そこでヨーロッパのエンジニアリングチーム(Jurgen Bettelsらのチーム)と共同でソフトウェアの国際化について議論をはじめたのが80年代中頃である。その後、各種標準活動を通じて他社のエンジニアと議論をふかめていった。

当時のプログラミング言語はCを筆頭にASCII前提の言語仕様になっている。ソースコードがASCII前提というのは現実的制約ではあるが、プロセスコードも多くはASCII前提である。

UnixはCの影響でばりばりASCII依存のコードになっていたのはよく知られている。

当時は、わたしはDEC Rdbの開発チームにいたので、Jim Meltonらとも標準や実装について徹底的に議論をしたし、その後ISO/IEC JTC1/SC22/WG20  というそのものずばりソフトウェア国際化について議論するグループに参加したので、企業や地域の枠を越えたコラボレーションをおこなっていた。標準化活動というのは通常は企業の利害対立の場でもあるのだがソフトウェア国際化という夢の実現にむけては利害が一致していた。非常に貴重な経験をしたと思っている。

企業や地域の枠を越えたコラボレーションの例としてISO/IECのような標準化団体での活動、Xコンソーシアムのような産学共同プロジェクト、/usr/groupなどのUnixユーザグループなどの形態がいろいろあるが、それらのコラボレーションの経験を積んだ人々は、オープンソースのバザールモデルへの理解が深いのも特徴だといえる。

解くべき正しい問題を解決するには地域や組織の枠をこえた多くの人や組織とのコラボレーションが必須であることを、わたしはその経験から学んだ。それがわたしのオープンソースに対するコミットメントの原点にもなっている。

マルチプロセッサ向けソフトウェアパラダイムとは？(その２)

「マルチプロセッサ向けソフトウェアパラダイムとは？」で、今後はますますマルチプロセッサ技術が重要になると指摘した。

またありがたいことにいくつかトラックバックをいただいた。

「Cのような低レベルの言語で書いているのであれば、それもしょうがないと思うが、スクリプト言語で書いたようなアプリケーションであれば言語処理系でよきにはからって欲しいとも思う。例えば構文で繰り返しを発見したらそれを自動的に並列化するくらいの事をやってくれてもばちはあたらない。Fortranのような数値計算処理系だとDOループを自動的にパイプライン化したり並列化したりして性能向上をシステムがおこなってくれたりする。」

薄いブログ／ホワット・ア・ワンダフル・ワールド

それなんて第五世代コンピュータ計画，と

ムーアの法則によりインテルの単一 CPU パワーの激増によって淘汰された超並列計算機アーキテクチャとプログラミングが，ムーアの法則の限界に直面し再び表舞台に復活するかもしれない，という歴史の皮肉．やはり時代を先取りしすぎだったのでしょうねぇ．

とのこと。

第五世代は論理型プログラミングだったけど、もちろん関数型言語やスクリプト言語でもかまわない。副作用のない言語だと並列性を発見した時の処理が素直に実装できるのでいく分有利かもしれない。

APLのような配列を簡単にあつかえる言語もいいかもしれない。PrologとかGHCとかKL1みたいな言語を勉強するのもいいかもしれない。

コンピュータアーキテクチャとして大規模並列マシンのコネクションマシン(プロセッサ数約6万)での経験より、
http://www.personal-media.co.jp/book/comp/062_f.html#part1

アルゴリズムの研究も必要である。ハロルドストーン(IBMワトソン研)はIEEE Computer誌にコネクションマシン上の文献検索アルゴリズムは一見高次の並列度を有しているように見えるが、インデックスを利用したシーケンシャルアルゴリズムを用いれば同じ主記憶サイズのたった1台のプロセッサで実行した方が速いという結果を詳細に導きだしている。このように必ずしもプルートフォースなアプローチで並列度が出たと喜んでいてもすぐ足をすくわれかねない。

並列度を生かすアルゴリズムの研究がかかせない。つまり並列度を構文的に発見できたとして、それを単にプロセッサにはりつけているだけではだめだったりするのである。

実装においても、いろいろな工夫が必要かと思うが、まだまだこれからの世界だと思う。

Pugsでの実装例
Parallel Scripting Now!

% /usr/bin/time pugs -e '(1..100000).>>sqrt'
        9.27 real         9.09 user         0.13 sys
% env GHCRTS=-N2 /usr/bin/time pugs -e '(1..100000).>>sqrt'
        5.79 real         6.92 user         0.15 sys

More SMP parallelism.
デュアルぐらいではパラダイムはシフトしがたい
 
Rubyのまつもとさんのブログより
20XX年のユビキタス、ロボット、Web／Ｔｅｃｈ総研

プログラミング言語も超メニーコアの時代になって、 1PCに65536個くらいCPUが載るようになると並列性を人間に取り扱える形で(つまり、あまり見せないように)、取り扱える言語が求められるようになり、 FORTRANのベクトル化技術に類似するものが復権してスクリプト言語を含めて広く利用されるようになる。

か、並列化が行いやすい副作用のない関数型言語が今とは別の意味で注目される。

http://www.rubyist.net/~matz/20070104.html#p02

オープンソースソフトウェア(OSS)ビジネスにおける競争優位性の確保

オープンソースソフトウェア(OSS)ビジネスと商用ソフトウェアビジネスにおける競争優位性の確保戦略についてどのような差異があるのかないのか。わたしはOSSビジネスではサポートサービスに競争優位性を見出す戦略が必然であると考える。なぜか。

長いこと商用ソフトウェアビジネスにいるとどうしてもそこからの発想から抜けきらない部分がある。

通常の商用ソフトウェア製品の場合、比較優位性を例えば製品機能に求める。競合製品と差異分析をして、機能の○×表を作って、足りない機能や競合製品にない魅力的な機能を追加したりする。

そのような機能の実装は知的財産権（著作権等）によって保護されるので、競合他社は容易にコピーできない。著作権ではアイデアは保護されないので同様のソフトウェアを競合会社が作ることを妨げることはできないが、それでもある機能を実装するにはそれなりのコストと時間がかかるので、それが参入障壁になる。

一方、オープンソースソフトウェア(OSS)の場合、ある機能の実装はその定義により公開しているので、競合他社がコピーするコストと時間は原理的にはゼロである。従って、あるオープンソースソフトウェアから別途新機能てんこもりのソフトウェアを作成したとしても、それが素晴らしいものであればあるほど、コピーされる可能性が高くなる。

似たようOSSを別途作る（フォークすると呼ぶ）というインセンティブはライセンス上、生じにくい。新機能を開発するのは、コミュニティにおいてバザール的に行なわれる。積極的にフォークしそれをメンテナンスするということは現実的にはそれほど発生しないのは、フォークするメリットとコストをはじめとするデメリットを計りにかけるとフォークするデメリットがメリットよりも遥かに大きいからである。

機能開発をバザールで行なうと、競合他社とは、開発においては協力しあうという商用ソフトウェアの開発ではありえない事態が発生する。商用ソフトウェアビジネスの常識で考えると自社で開発したものはなるべく隠して成果だけを得ようとするが、そのスタイルはバザールモデルでは間違いなく破綻する。そのような開発スタイルは持続可能ではないのである。バザールモデルというソフトウェア開発の革命性は競合他社とビジネスの根幹であるソフトウェアを共同で開発することを強制させることである。この革命性について理解をしている経営者は残念ながら少ない。

いずれにせよ、オープンソースソフトウェアの場合、機能による差別化という商用ソフトウェアでとられている戦略はとることは難しい。

機能開発による競争優位性戦略がとれないとするとどこで競争優位性を確保するべきなのか？

ソフトウェアの本質はそれによって顧客の問題を解決することである。完璧なソフトウェアというのがありえない以上、狭義のバグ修正から環境変化による機能変更、追加等の保守作業が絶対必要になる。ソフトウェアを導入すれば当然それを運用するためにサポートサービスが必要になってくるのである。

OSであれば、各種パッケージのセキュリティフィックス、バグ修正などである。一度運用に入ってしまえば新機能の追加よりもそれらのほうが重要なのである。これらの作業は通常サポートサービスとして提供されている。

オープンソースの場合、すべての情報は公開されているので、原理的にはセキュリティフィックスもバグ修正もユーザができなくはない。例えば技術力のあるユーザはdebianのような完全に自由なパッケージを自己責任で管理運用していたりする。しかし、多くのユーザは自社内にそのような技術スタッフを雇用しているわけではないので弊社のようなディストリビューションベンダの商用Linuxを購入し、サポートサービスの提供を受けている。自前でセキュリティフィックスを作るコストを考えたら、年間15万円ほどのコストを払いプロダクトサポートを購入するというのは極めて経済的な判断である。

商品としての各種パッケージの出所はオープンソースなのである意味一緒であるが、サポートサービスそのものはそれぞれのベンダが各種サービスレベルのメニューを提供している。ユーザはその中で自分のニーズにあったものを購入する。
価格とサービスが透明化したのでユーザの選択肢が広がった。

商用ソフトウェア製品の場合、製品の提供だけではなく、製品のサポートも一社が独占するが、オープンソースの場合、誰でもサポートを提供できる。製品とサポートが分離（アンバンドル）されたのである。これはユーザにとってのメリットである。

オープンソースの場合、製品そのもので差別化するというのが原理的に難しいと先に指摘した。好むと好まらずに関わらずベンダはサポートサービスで差別化するしかないのである。ユーザにとってはサポートの質が満足できないのであればベンダを変えることができるようになった。商用ソフトウェアの場合は、商用ソフトウェアのスイッチングコストが高いのでサポートに不満足でも容易にベンダを変えることが難しかったがオープンソースの場合はその敷居は低い。

オープンシステムの普及によって、ハードウェアベンダとソフトウェアベンダが明確に分離され、ユーザもそのメリットについてよく理解している。かつては（80年代の中ごろまで）IBMを代表とした垂直統合、すなわち、ハードウェアもOSもデータベース管理システムも各種ミドルウェアもシステムインテグレーションもすべて一社で提供する、のではなく、水平統合、すなわち、ハードウェア、OS、データベース管理システム、等々がそれぞれ別々のベンダが提供するという形態が、ユーザにとって選択肢を得られると言う意味でより好ましいと理解されている。（選択の自由あるいはベンダロックインからの解放という風に理解されている）

ユーザはオープンソースの時代になって、オープンソース製品とそのサービスのアンバンドルのメリットを理解しつつある。それはとりもなおさずサービスを提供するベンダにとってはビジネスチャンスであり競争優位性を提供するフィールドでもある。

我々ベンダは顧客に対しより満足度の高いサービスを提供すべく日々努力しているというところである。そこに競争優位性の源泉を見出す。

まとめると、オープンソースソフトウェア製品の競争優位性は、製品の機能ではなく、製品サポートサービスに比重が高まってきている。その重要性を正しく理解した企業が次のOSSビジネスの覇者になるとわたしは思う。

マルチプロセッサ向けソフトウェアパラダイムとは？

年末に会社の机を整理して、(席替えがきっかけだったのだけど)、読もうとおもってコピーしていた論文なんかを書類置きの下の方から発掘した。一度スタックにつまれてしまうと時々ゴミ集め(GC -- Garbage Collection)して整理しないと二度と発見されない。

半年ぶりにこんにちはの論文たちよ。その一つに"Ideas on improving Linux infrastructure for performance on multi-core platforms", Maxim Alt というのがある。

最初の会社に入社したのは20年以上前の話で、その頃わたしは、「ムーアの法則」などという言葉を知らなかったが、その会社は間違いなく「ムーアの法則」という事を正しく理解している会社であった。VAXというミニコンで一時代を築いた会社で、PDP-11という16ビットコンピュータのベストセラーマシンを開発したチームがVAXを開発していた。新人社員であるわたしはあこがれのエンジニア達の開発秘話に胸をときめかせたものである。

Godon BellだかBill Streckerかの論文にCPU memoryの需要は一年に0.7 bit増大する、従ってうんぬんかんぬんというお話があった。数百万円するワークステーションが何年かのうちに個人で経済的に利用できるようになる。

メモリコストがどんどん下るのならメモリを上手に利用するプログラミングパラダイムが絶対必要になる。その文脈でDECはVAX/VMSというアーキテクチャを設計した。VAX (Virtual Address eXtension)というアーキテクチャと VMS (Virtual Memory System)というOSは仮想記憶を徹底して意識した作りになっている。

DECにはVAXLというプログラミング言語のコミッティがあって共通言語インターフェースを定義していたがFORTRANの実装者もCOBOLの実装者もAdaの実装者も一つのコミュニティとして仮想記憶を意識したプログラミングパラダイムを共有していた。

プログラミング言語はソースコードを読みとり、字句解析、構文解析などをへて中間言語に翻訳され、最後に機械語になる。前方参照などを解決するために、ソースコードを複数回読む場合がある。通常ソースコードを読むプロセスをパスと呼ぶので複数回読むコンパイラをマルチパスコンパイラなどと呼ぶ。最もコストのかかる操作は物理的にファイルから読む作業なので、できればそれをさけたい。

VAXの言語コミュニティは論理的には複数回ソースコードを走査するのだが物理的には一度しか読まない実装をとった。一度読んだソースコードを仮想記憶上に展開し論理的なファイルを仮想記憶に持ち、それを複数回読むという実装をした。物理的な入出力にくらべ、仮想記憶へのアクセスは遥かに速いのでコンパイル速度は向上するという考えである。

仮想記憶の管理は言語処理系がするのではなくOSの仕事である。当時のVMSのチームにはトップノッチのエンジニアがごろごろいたので、仮想記憶のパフォーマンスチューニングは彼らにとっては、朝飯前の仕事であった。

仮想記憶の処理がうまくないとページングが発生し性能がでない。ページングは物理メモリにのりきらない仮想記憶をディスクへ退避復帰する処理なので物理的入出力が発生するため大変コストがかかる。いろいろなアルゴリズムを駆使してページングの発生を最小化するのがOSの仕事である。

いい実装であればページングはほとんど発生しないし、悪い実装であればページングが発生する。共有ライブラリのようなものは複数のプロセスで物理的なページを共有するので(物理メモリの需要が減る)、上手に実装するとページングを減少させる。VMSはデフォルトでそれを実装していたが、Unixでそれが一般化するよりはるか以前の頃の話である。

ハードウェアアーキテクチャ、OS、コンパイラ、ミドルウェア等々仮想記憶を前提に実装されていた。その結果、メモリがどんどん安くなってメモリを大量に装着できるようなると、ハードウェアを変更しなくても、ソフトウェアの実装を変更しなくても、メモリを追加するだけで文字通り性能が向上するという実装に収斂していったのである。

DEC社内のコミュニティはムーアの法則を仮想記憶の実装という形で理解していた。エンジニアリングコミュニティでそれが共有されていた。

Alphaの開発チームはVAX開発チームの後継で、ある意味DNAを受けついでいるのだが、当時の論文(90年ごろ)で、マイクロプロセッサのスケーラビリティを、クロックの向上で10倍、アーキテクチャの進歩で10倍、マルチプロセッサで10倍、10x10x10=1000倍の性能向上を達成するとかしないとか書いてあって、感心したのを覚えている。

第一世代のAlphaは150MHzで当時他社製プロセッサは20〜40MHzだったので、それでも十分高クロックであったが、それを10倍も高めるアーキテクチャ上の設計になっているというのに心底たまげた。今からふりかえってみれば10倍というのも控え目のゴールで20倍ないし30倍程度は向上した。

アーキテクチャの進歩というのはスーパースカラ、スーパーパイプライン、アウトオブオーダ実行、投機的実行等々様々なアイデアを実装することによって性能向上をはかるという事である。コンパイラの進歩もあいまってこれも10倍程度の性能向上はあったであろう。

最後のマルチプロセッサ化による性能向上というのは、別段とりたてておどろくような話ではないが、最初の二つがアプリケーションソフトウェアの変更をほとんどなしにシステムによってほぼ自動的に達成できる類のものに比べ、マルチプロセッサというのはアプリケーション側で積極的に対応しないと性能向上になかなか寄与しない。という事で一番地味で簡単に達成可能かと思われたマルチプロセッサでの性能向上というのがソフトウェア的には一番最後まで残ってしまったということである。

OSのマルチプロセッサ対応の歴史は古くからあるのだが、その上に載るRDBMS等のミドルウェア、さらに上のアプリケーションなどはじめからマルチプロセッサを意識した作りになっていないと、プロセッサの数を10倍増したからといっても性能が10倍向上するということはない。

Cのような低レベルの言語で書いているのであれば、それもしょうがないと思うが、スクリプト言語で書いたようなアプリケーションであれば言語処理系でよきにはからって欲しいとも思う。例えば構文で繰り返しを発見したらそれを自動的に並列化するくらいの事をやってくれてもばちはあたらない。Fortranのような数値計算処理系だとDOループを自動的にパイプライン化したり並列化したりして性能向上をシステムがおこなってくれたりする。

SQLの最適化エンジンも実行プランをかなり賢く選択するようになってきている。

で、話をムーアの法則に強引に戻すと、20年前であれば、それは仮想記憶をどう上手に使うかという問題に帰着したわけで、それと同様な問題を設定するとすると、ムーアの法則をソフトウェアパラダイムの問題として考えると、それはマルチコアなプロセッサをどう上手に使うかという問題に帰着する。

数年前にインテルがハイパースレッディング技術をうちだしたとき、何もしない(？)で20〜30%性能が向上するというふれこみであったが、残念ながらなかなかそう上手くはいかなかった。アーキテクチャ上の工夫(スーパスカラとか投機的実行のたぐい)というより、むしろマルチプロセッサによる性能向上というような技術に近かったため、アプリケーションの変更が必要であったからと言える。

32ビットアーキテクチャから64ビットアーキテクチャの移行はある程度機械的な変更でおこなえるがシングルプロセッサ向けのソフトウェアをマルチプロセッサ向けへ変更する事は容易ではない。

ロックをはじめとする同期のアルゴリズムの再発見が必要となる。

ということで今後ますますマルチプロセッサ技術が重要になるというブログ初エントリーである。

机を整理していたら、Wait-Free Synchronization, Maurice Herlihy, 1993というのも発見されたことを付記しておく。