コンピュータのつくりかた
How to make your own computer architecture?
2016.02.26
Updated by Ryo Shimizu on February 26, 2016, 20:40 pm JST
How to make your own computer architecture?
2016.02.26
Updated by Ryo Shimizu on February 26, 2016, 20:40 pm JST
東京大学理学部情報科学科にはCPU実験という必修科目があります。
チームをつくり、半年かけてできるだけ高速なコンピュータを開発するというものです。
この実験では、CPUからOS、コンパイラ、アプリケーションといったものを全てゼロから作り上げます。
うわさに聞くだに難しそうな課題ですが、これを楽しんでこなせるか苦しいと思うかによって、その人のこの分野への適正と才能を推し量るいい試金石になりそうです。
この実験を提案したのは、当時の東大助教で、現在は奈良女子大の教授となっている松本尚先生で、日本IBMの基礎研究所で並列計算機の研究開発に取り組んでいた凄腕で、自身もSSS-PCという、分散OSを開発されている方です。
先日、非常に幸運な出会いがあって、この松本先生にお目にかかる機会を頂いたのですが、非常に刺激的な会話になりました。
そこで一つの会話のテーマになったこと、そして筆者が普段から「OSをつくる」「コンピュータをつくる」と一口に言った時にどういう意図を持っているか、ということが議論になりました。
松本先生はCPUアーキテクチャから作ってしまうような方なので、発想も非常にユニークです。
実は大昔には、様々なCPUアーキテクチャがあり、世界中のアーキテクトがしのぎを削っていた時代があります。
今のIntel Core iシリーズのもとになったCPUは1970年代のIntel 8086ですが、この時期はいろいろなアーキテクチャがありました。
そもそも8086の前身である8ビットCPUの8080、その互換CPUのZ80は、一世を風靡しました。パソコンから戦闘機まで、全てがZ80だった時代もあります。
Appleが初期のコンピュータAppleIIで採用していたのはMOS6502で、このチップはAppleIIをきっかけに大ヒットとなり、その後、任天堂のファミリーコンピュータにもMOS6502の互換CPUであるRP2A03(RICOH製)が採用されました。
Z80や6502が8086が小型コンピュータ、いわゆるパソコン向けに設計された16ビットCPUだったのに対し、大学や企業、軍の研究所などで使用される高性能な32ビットCPUとして重宝されたのがモトローラのMC68000という32ビットCPUです。
68000は高価でしたが、性能が良かったのとアーキテクチャの効率が良かったので、高級なワークステーションに採用された後、AppleのLisa、Macintoshにも使用されました。アポロ計画でも採用されています。
この頃のCPUアーキテクチャの細かな違いを説明しても、本誌の読者にはピンとこないでしょうから割愛しますが、とにかく、CPUといえばIntel、という今の時代からは考えられないほど多様な設計が試され、その中で互換性に強く拘るあまり性能面ではやや不利に思えたIntelのx86アーキテクチャは、次第に困難を乗り越え、性能面でもライバルを凌駕し始めます。
OSの設計はCPUアーキテクチャに強い影響を受けます。
たとえば、UNIX互換OSをZ80で動かすのはCPUの制約からほとんど不可能です。UNIXは基本的に16ビット以上のアーキテクチャを前提とした設計がされているからです。
ところが現在は、一部のマイコンを除くと32ビットCPUが組み込みでも使われるようになってきました。
32ビットCPUを効率的に動かすためには、殆どの場合はUNIX、特にLinuxが使われます。
UNIXとLinuxの関係性についても最初に明らかにしておいたほうが良さそうです。
UNIXは、AT&Tベル研究所で開発されたOSです。しかも、当初はライセンス料を徴収せず、しかもソースコードごと配布していたので、そのシンプルさがウケてまたたく間に普及しました。ところが1980年代、UNIXが十分普及してしまったあとで、AT&Tベル研究所はUNIXの商用化を決定します。
このあと起きたことはものすごい混乱でした。
各社が独自にUNIXのライセンスを購入し、改造を施した自社UNIXを次々とリリースするのです。
つまり、乱暴にいえば、当時はOSはメーカーの数だけ存在していました。
しかも、それらは全て有料で、趣味で使えるものは限られていました。
UNIXはもともとオープンソースだったのに、ビジネス上の都合で様々なライセンスの制約を受けることになったのに反発したプログラマーのコミュニティは、独自にUNIX互換のOSとツールチェイン(UNIXと同じソフトウェアを動作させるためのソフトウェア群)を開発し、それらを全てオープンソースにします。その中心的存在を果たしたのがGNUプロジェクトのリチャード・ストールマンでした。
さらにヘルシンキの学生だったライナス・トーバルズが、自宅の32ビットPCでUNIX互換OSを動作させたいと思ってカーネル(OSのコアとなる主要部分)を書き、GNUプロジェクトのツールチェインを活用して作ったのがLinuxと呼ばれるようになりました。
現在、AppleのiOSもMacOSXも、内部的にはUNIX互換のOSを内包しています。Androidも、Linuxベースで開発されています。Raspberry Piのような組み込み製品もLinuxを採用しており、今LinuxまたはUNIXとなんの関係もないのはMicrosoftのWindowsシリーズくらいです。
さて、では今の時代、全く新しいコンセプトのCPUアーキテクチャや、OSを設計するというのはどういうことでしょうか。
日本のベンチャー企業、PEZY Computingも、独自の発想で開発したCPU、PEZY-SCを開発し、スーパーコンピュータのエネルギー効率を競うGreen500で1位から3位を独占、スーパーコンピュータの絶対性能を競うTop500でも160位で、これはベンチャー企業としては世界初の快挙と言えます。
スパコンを開発するモチベーションは様々ですが、その根底に流れるのはエンジニアとしての本能的な欲求、もっと速く、もっと大容量に、というものです。
そしてCPUアーキテクチャを刷新することでそこで生まれるであろうソフトも大きく変化することになります。
たとえばPlayStationは、ワークステーション級のCPUであるR3000にカスタム化したDSPを搭載し、3Dグラフィックスに強いゲームマシンという新しいカテゴリーを切り開きました。
初代PlayStation以後は、全てのゲーム機がPlayStationの設計を後追いするというほどのインパクトで、ゲームというもののあり方を根本的に変えたターニングポイントとなった製品でした。
その後、PS2でEmotion EngineとGraphics Synthesizer、PS3でCELLとRSX、というようにカスタムCPUとGPUを作る路線を推進してきて、常にゲーム機の次の時代を切り開いてきました。
本来、CPUのアーキテクチャが変わるというのはそれほどのインパクトがあることで、CPUのアーキテクチャが通常と大きく異なる場合、それを駆動するためのOSも必然的に変化を迫られます。
全く新しいCPUアーキテクチャに対応したOSを作ることそのものはさほど難しくありません。ものによっては既存のOSを一部修正するか、全く修正しなくてもいいものもあります。
ところが全く新しいOSを作ってしまうと、一つ別の大きな問題が立ちはだかることになります。ツールチェインです。
今現在、UNIX互換OS向けのフリーソフトウェアは無数に存在していて、もはや近代的なコンピュータシステムを実現するのになくてはならない存在になっています。
UNIX互換OSであれば既存のツールチェインをまるごと使うことが出来ます。ツールチェインを流用できれば、大学生でも独自のOSを書けるわけです。それがLinuxだったわけですから。
Microsoftが取り組んでいるような、数年に一回の間隔で完全独自開発の自社OSを刷新していくようなやり方は、ツールチェインの開発をまるごと自社内に抱えなければならないという点で大きな負担になります。
それでもWindowsには長い歴史があるので、過去に開発されたツールチェインや、UNIXから移植されたツールチェインを使うことが出来なくもありません。
でも猫の目のように変わる最先端のコンピュータ・サイエンスの世界ではWindowsは数少ない例外的な事象を除いては、UNIX互換環境に常に一歩遅れてしまうイメージです。
たとえば深層学習ひとつとっても、Windowsで動作保証されている深層学習環境というのはMicrosoftが作ったものだけです。
Windows以外の世界、LinuxやMacOSXといったUNIX互換環境では、あまり苦労しなくても最先端のソフトウェア・パッケージを使うためのフルセットのツールチェインが揃っているのですが、Windowsの場合、たとえばフォルダ(ディレクトリ)の切り方ひとつとっても独特だったり、やたらとディレクトリ名が長過ぎたりする上に、UNIXと同じことをするコマンドに互換性がないというのが大きな問題です。
例えばUNIXではファイル一覧を見るのにlsというコマンドを使いますが、Windowsではdirというコマンドを使います。
ここまで違うと、UNIX用に作られたプログラムを全てWindows用に書き変えるという余計な作業が必要で、しかもそんな余計なことはできれば誰もしたくはないわけです。
それに、データセンターに設置されているサーバーはたいがいがUNIX互換OSですから、WindowsでWebサービスを作ったり動かしたりするのは至難の業です。
結果、プログラマーがどんどんWindowsから離れていって、コンシューマ向けならUNIX互換OSを搭載しつつ使い勝手の良いMacか、いっそサーバーと全く同じ環境で動作させることができるLinuxをインストールして使うか、という感じで、最近はWindowsでしか動かないソフトというのも聞かなくなってきています。
全く新しいコンピュータ・アーキテクチャを作る、というのはとても魅力的で、ワクワクするような冒険です。
ところが、実際に作った独自のコンピュータ・アーキテクチャを使ってもらうためには、なにか全く別の目的が必要になります。
個別のコンピュータ・アーキテクチャのアイデア、今よりもっと冴えた方法、効率的な管理方法、独特のファイルシステム、そういうものはOSという概念の根幹を成すものであり、そしてOSの個性を最大限発揮できる場所でもある反面、あまりにも個性が強すぎると既存のコンピュータと利用方法が違いすぎて混乱のもとになってしまいます。
新しいコンピュータ・アーキテクチャのアイデアは数あれど、実のところそれを作ることそのものが大変というよりは、それを実用的に使える領域に持っていったりだとか、それをやらなければならない理由を考える方がずっと大変なのです。
エンドユーザは「こっちのOSはとても効率的で省電力になりました」と言われても、それがたとえば30%の省電力で動作するとしても、そこでしかできないことが無かったり、そこでやる必然性がなかったりすれば魅力を感じません。
PlayStationが良かったのは、独自のアーキテクチャの延長線上にはっきりと「新しい時代のゲーム」という目標が描かれていたからで、しかもPlayStationでは既存の世界でできることができる必要は全くなかったわけです。つまり互換性を無視できた。
同様にiOSやAndroidもありますが、たとえばiOSは内部的にはMacOSXと同じようにUNIX互換OSを内包しているものの、それはプログラマーにもエンドユーザーにもできるだけ見えないようになっていて、プログラマーもエンドユーザーも、「スマートフォンでのコンピュータ体験」に集中できるようになっています。
つまりOSやアーキテクチャが変わるときというのは、なによりもまず、コンピュータとの接し方が変わるときなんです。
筆者がペンに着目したのも、そもそもはペンを常用するような世界になるとすると、それはやはりコンピュータとの接し方がこれまでとは根本的に変わることを意味します。
OSの主な機能はリソース(メモリーやHDD、CPUなど)の管理ですが、現代においては、OSの最も重要な機能はアプリケーションの定義とファイルシステムの定義、そこに尽きるのではないかと思っています。現実のリソースの管理は内包したUNIX互換OSがやればよろしい。これはAndroidも同様です。
汎用的なOSを使うことで多少の効率が落ちたとしても、アーキテクチャの良さを表現するためにはまず手近なゴールから示すのが得策なのではないかと思います。
むしろ今は頭ひとつ抜きん出た存在がないため、コンピュータ・アーキテクトにとっては新しいアイデアを試す絶好のチャンスが到来した時代と言えるのかもしません。
おすすめ記事と編集部のお知らせをお送りします。(毎週月曜日配信)
登録はこちら新潟県長岡市生まれ。1990年代よりプログラマーとしてゲーム業界、モバイル業界などで数社の立ち上げに関わる。現在も現役のプログラマーとして日夜AI開発に情熱を捧げている。