ページへ戻る

− Links

 印刷 

design001 のバックアップソース(No.1) :: OSASK計画

osaskwiki:design001 のバックアップソース(No.1)

  Next »[4]
* 平凡プログラマ向けか、職人プログラマ向けか
-(by [[K]], 2008.07.02)
-このページは[[network_good]]の続編に相当します。
*** (0)
-たとえばCPUを設計する場合、どんな機械語(命令セット)を用意するかで性能は大きく変わります。このとき、誰でも適当にプログラムを書くだけでそこそこ性能が出る代わりに、がんばって最適化してもあまり性能が上がらないという設計方針があります(以降これをAタイプと呼ぶ)。一方で、適当にプログラムを書くとそこそこしか性能が出ない代わりに、職人プログラマが気合を入れて最適化すると爆発的に性能が上がるという設計方針もあります(以降これをBタイプと呼ぶ)。
*** (1)
-一般的に性能を比較すると、こんな感じだと思います。
 「Bタイプで究極に最適化したもの」>「Aタイプで究極に最適化したもの」>「Aタイプで最適化していないもの」>「Bタイプで最適化していないもの」
-もしこういう順序になっていないのなら、たとえば「Bタイプで究極に最適化したもの」<「Aタイプで究極に最適化したもの」なんてことになっていたら、それは単にBタイプの設計がヘボいだけです。Aタイプの設計が最強で、このCPUだけで十分です。また最適化してないもの同士での比較が逆転する場合は、Aタイプは最適化してもしなくてもBタイプにそれぞれ負けていることになるので、今度はAタイプの設計が不要になります。
-この話は何もCPUに限ったことではありません。言語やOSやアプリの設計においても同様です。
-たとえば言語を考えてみましょう。C言語とアセンブラの関係は、まさにAタイプとBタイプの関係にあります。C言語だけではどうして書けないプログラムがあったり(ブートセクタとか)、実行速度もサイズもアセンブラが得意な人との比較では勝負になりませんが、しかしレジスタの使いまわしで悩む必要はないですし、適当に書けばそれなりに動きます。・・・一方でアセンブラは使いこなすのがC言語よりも大変です。しかし完璧に(もしくはかなりのレベルで)使いこなせれば、C言語の出すコードなど敵ではありません。
*** (2)
-僕はこのような考えのもとで、どちらかといえばOSASKを「Bタイプ」のOSとして設計しています。つまり簡単で適当に作ったアプリに対しては最高性能は出ません。その代わり、気を配って工夫したプログラムに対しては、究極の(他のOSではまず真似できないような)性能を提供します。・・・しかし多くの例では、簡単で適当に作ったアプリでも、他のOSより早くなってしまっています。これはなんというか、他のOSが論外にヘボかったというだけです。
-もちろん適当に書いたプログラムに対しても、コンパイラやアセンブラに独自拡張を大量に埋め込むことによって、それなりにいいプログラムにさせることはできるはずです。しかしその分だけコンパイラやアセンブラが肥大化するのは避けられませんし、コンパイル時間も長くなるでしょう。そしてそれでも生成できるコードは究極には程遠く、何もしないよりはマシという程度でしかありません。これでもさらに性能を出すためには、OS側もアプリがC言語で作られることを前提にして、APIを処理する方法があります。つまりC言語と相性のいい方法を使うわけです。・・・しかしこれをやると、せっかくアセンブラを使っても、C言語と同じ方法でしかOSに命令できないので、効率は最高ではなくなります。ということで、これは結局Aタイプになってしまうのです。
*** (3)
-最近の世の中の流れでは「職人不要論」みたいなものがあります。つまり、職人でなくても性能が出せるようにしよう、ということです。これは実に結構なことですが、結局現状はAタイプの設計をしているだけです。最高性能が出せていないし出す方法もなくしているのです。ひどいときは、最高性能がどのくらいだったのかも忘れている場合すらあります(つまりAタイプ設計であることをやめればまだまだ性能が上がりそうなのに、その可能性に気付かなくなっていて「もう限界」だとかいう)。
-そしてこの流れのせいなのか、いわゆる「職人」も減ってきています。世の中は職人不要論に傾いているので、職人に職人向けの仕事を与えません。誰でも出来るような簡単な仕事ばかりです。職人も技を発揮する機会が無いので腕が鈍ってきます。
-これはつまり、本当の限界を知る人が減ってきているということでもあるのです。これはかなりやばいと僕は思います。本当の限界が分からなくなって、偽りの限界を本当の限界だと思ってしまったら、Aタイプの範囲での改良は終わってしまいます。「職人不要論」では、職人でなくても性能が出せるようにしよう、が目的だったのに、結局職人がいなくなって性能も出せなくなっただけになってしまいそうなのです。
*** (4)
-僕はBタイプ設計のこそ正しいと思います。性能が必要な場面では職人を雇えばいいではないですか。そしてOSやCPUの設計者は、その職人の書くプログラムがもっともうまく動くように設計すればいいのです。C言語が出すプログラムが速く動くことなんて、どうでもいいおまけでしかないはずです。・・・逆に言えば、Cコンパイラに最適化オプションなんてなくてもいいのです。それはちょっと気の利いた「おまけ」でしかないのです。小学生が中学生に追いつくためのおまけでしかないのです。大人には全然届かないのです。
-それよりもCコンパイラが重視するべきは、コンパイル時間を速くしたり、コンパイラ自身のバグが少ないことだったり、移植性の高いソースを書きやすくするために支援することなどのはずです。性能がほしいときはアセンブラを使えばいいんですし、性能よりも他のことが重要だからC言語で書いているはずなのに、それらのことを優先しないのはおかしいです。・・・OSだって、小学生が書いたプログラムをできるだけ高速に実行するようなおせっかいなんかしないで、大人が書いたプログラムを前提にして、しかし小学生が書いたプログラムでも最高速ではないけどちゃんと動くには動く、を目指すべきだと思うのです。
-しかしそうなってはいないのです。性能を追求するべきはずのOSは性能を追求せず、性能を重視する必要のないCコンパイラは最適化の度合いを競っています。その結果、アプリがどんなにがんばってもOSが重くて足を引っ張り(特に起動時間とか)、最適化に走ったコンパイラのせいで妙なコードが出てきて悩まされます(最適化オプションをOFFにすればいい場合が多いけど、OFFにしてもコンパイラのバグで回避できない場合も経験アリ)。本当にこれでいいんでしょうか?
* こめんと欄
#comment

  Next »[4]