design001 :: OSASK計画

平凡プログラマ向けか、職人プログラマ向けか

• (by K, 2008.07.02)
• このページはnetwork_goodの続編に相当します。network_goodはdesign000ってことで。

(0)

• たとえばCPUを設計する場合、どんな機械語（命令セット）を用意するかで性能は大きく変わります。このとき、誰でも適当にプログラムを書くだけでそこそこ性能が出る代わりに、がんばって最適化してもあまり性能が上がらないという設計方針があります（以降これをAタイプと呼ぶ）。一方で、適当にプログラムを書くとそこそこしか性能が出ない代わりに、職人プログラマが気合を入れて最適化すると爆発的に性能が上がるという設計方針もあります（以降これをBタイプと呼ぶ）。

(1)

• 一般的に性能を比較すると、こんな感じだと思います。

  「Bタイプで究極に最適化したもの」
   ＞「Aタイプで究極に最適化したもの」
    ＞「Aタイプで最適化していないもの」
     ＞「Bタイプで最適化していないもの」

• もしこういう順序になっていないのなら、たとえば「Bタイプで究極に最適化したもの」＜「Aタイプで究極に最適化したもの」なんてことになっていたら、それは単にBタイプの設計がヘボいだけです。Aタイプの設計が最強で、このCPUだけで十分です。また最適化してないもの同士での比較が逆転する場合は、Aタイプは最適化してもしなくてもBタイプにそれぞれ負けていることになるので、今度はAタイプの設計が不要になります。
• この話は何もCPUに限ったことではありません。言語やOSやアプリの設計においても同様です。
• たとえば言語を考えてみましょう。C言語とアセンブラの関係は、まさにBタイプの関係にあります。C言語だけではどうして書けないプログラムがあったり（ブートセクタとか）、実行速度もサイズもアセンブラが得意な人との比較では勝負になりませんが、しかしレジスタの使いまわしで悩む必要はないですし、適当に書けばそれなりに動きます。・・・一方でアセンブラは使いこなすのがC言語よりも大変です。しかし完璧に（もしくはかなりのレベルで）使いこなせれば、Cコンパイラの出すコードなど敵ではありません。
• 逆にもしそこそこの性能の一つの言語ですべてをカバーしようと計画した場合は、Aタイプの設計だということができます。

(2)

• 僕はこのような考えのもとで、どちらかといえばOSASKを「Bタイプ」のOSとして設計しています。つまり簡単で適当に作ったアプリに対しては最高性能は出ません。その代わり、気を配って工夫したプログラムに対しては、究極の（他のOSではまず真似できないような）性能を提供します。・・・しかし多くの例では、簡単で適当に作ったアプリでも、他のOSより早くなってしまっています。これはなんというか、他のOSが論外にヘボかったというだけです。
• もちろん適当に書いたプログラムに対しても、コンパイラやアセンブラに独自拡張を大量に埋め込むことによって、それなりにいいプログラムにさせることはできるはずです。しかしその分だけコンパイラやアセンブラが肥大化するのは避けられませんし、コンパイル時間も長くなるでしょう。そしてそれでも生成できるコードは究極には程遠く、何もしないよりはマシという程度でしかありません。これでもさらに性能を出すためには、OS側もアプリがC言語で作られることを前提にして、APIを処理する方法があります。つまりC言語と相性のいい方法を使うわけです。・・・しかしこれをやると、せっかくアセンブラを使っても、C言語と同じ方法でしかOSに命令できないので、効率は最高ではなくなります。ということで、これは結局Aタイプになってしまうのです。

(3)

• 最近の世の中の流れでは「職人不要論」みたいなものがあります。つまり、職人でなくても性能が出せるようにしよう、ということです。これは実に結構なことですが、結局現状はAタイプの設計をしているだけです。最高性能が出せていないし出す方法もなくしているのです。ひどいときは、最高性能がどのくらいだったのかも忘れている場合すらあります（つまりAタイプ設計であることをやめればまだまだ性能が上がりそうなのに、その可能性に気付かなくなっていて「もう限界」だとかいう）。
• この流れのおかげで、平凡な人が適当に書いても60点くらいの結果が出ます。しかし職人が本気を出しても70点しか出せません。
• そしてこの流れのせいなのか、いわゆる「職人」も減ってきています。世の中は職人不要論に傾いているので、職人に職人向けの仕事を与えません。誰でも出来るような簡単な仕事ばかりです。職人も技を発揮する機会が無いので腕が鈍ってきます。
• これはつまり、本当の限界を知る人が減ってきているということでもあるのです。これはかなりやばいと僕は思います。本当の限界が分からなくなって、偽りの限界を本当の限界だと思ってしまったら、Aタイプの範囲での改良は終わってしまいます。「職人不要論」では、職人でなくても性能が出せるようにしよう、が目的だったのに、結局職人がいなくなって性能も出せなくなっただけになってしまいそうなのです。

(4)

• 僕はBタイプ設計のこそ正しいと思います。平凡な人には40点くらいしか出せないでしょう。でも動くんだからいいじゃないですか。しかも職人が努力すれば80点、90点、そして100点も出しうるのです。
• 性能が必要な場面では職人を雇えばいいではないですか。そしてOSやCPUの設計者は、その職人の書くプログラムがもっともうまく動くように設計すればいいのです。C言語が出すプログラムが速く動くことなんて、どうでもいいおまけでしかないはずです。・・・逆に言えば、Cコンパイラに最適化オプションなんてなくてもいいのです。それはちょっと気の利いた「おまけ」でしかないのです。小学生が中学生に追いつくためのおまけでしかないのです。大人には全然届かないのです。
• それよりもCコンパイラが重視するべきは、コンパイル時間を速くしたり、コンパイラ自身のバグが少ないことだったり、移植性の高いソースを書きやすくするために支援することなどのはずです。性能がほしいときはアセンブラを使えばいいんですし、性能よりも他のことが重要だからC言語で書いているはずなのに、それらのことを優先しないのはおかしいです。・・・OSだって、小学生が書いたプログラムをできるだけ高速に実行するようなおせっかいなんかしないで、大人が書いたプログラムを前提にして、しかし小学生が書いたプログラムでも（プログラムが正しい限りにおいて）高速ではないけどちゃんと動くには動く、を目指すべきだと思うのです。
• しかしそうなってはいないのです。性能を追求するべきはずのOSは性能を追求せず、性能を重視する必要のないCコンパイラは最適化の度合いを競っています。その結果、アプリがどんなにがんばってもOSが重くて足を引っ張り（特に起動時間とか）、最適化に走ったコンパイラのせいで妙なコードが出てきて悩まされます（最適化オプションをOFFにすれば解決する場合が多いけど、OFFにしてもコンパイラのバグで回避できない場合も経験アリ。そもそもこんなことで悩まされてもしょうがない、ってことになっていること自体がおかしい）。本当にこれでいいんでしょうか？

(5) 補足

• つまり僕はこうするべきだと思っています。
  • まず、天才職人プログラマや究極の最適化プログラムを想定し、それらが使ったときに最高性能が出るように設計します。
  • 次に、平凡なプログラマがそのままでは使いこなせないのは目に見えているので、使いやすいライブラリみたいなものを用意します。このライブラリを使えば結構簡単に一通りの機能が使えます。でも性能は最高ではありません。
  • OSASKでいうと、lib_putstringみたいなのは後者で、前者に相当するのがI.Tak.さんのNASMプログラム、中間がlib_execcmdを使う方法です。これに対し、WindowsやLinuxではlib_putstringみたいな方法までしか考えられていません（もっと込み入ったこともきっと出来るが、そういう方法を一般に説明しようという傾向がないし、込み入った方法を使えばぐっと性能が出るというわけでもない）。
  • ライブラリに関しては、出来るだけ簡単さを損なわずに最高速度に近づけるように改良します。それが難しいときは中間くらいの難しさでそこそこ速く出来るようなライブラリも考えます。
• これに対し、世間の多くの設計はこうなっています。
  • まず、平凡な利用者を想定し、これらが使う範囲での高速化だけを考えます。しかも究極の高速化とか、最高性能とかはあまり考えていなくて、最近の普及機で実用的な性能が出ればそれでいいやくらいに思っています。
  • 自分より頭がいい人がいるかもしれないこと、そういう人たちがこの設計に不満を持つかもしれないことは想定していません。もし想定していたら、そういう人の期待にもこたえられるような拡張性を持たせるはずなんだけど、そうなってないのです。
• 「職人でなくても作れるようにしよう」には無条件で賛成ですが、「職人でなくても最高性能が出せるようにしよう」は現状では不可能だと思うので、賛成できません。不可能なのに、自動最適化でできる範囲を「最高性能」だと思い込むことでごまかす今のやり方は、むしろ有害だと思います。
• そして平凡な人を「標準」とし、平凡なプログラムでどのCPUが一番いいかを競うなんて、なんかおかしいです。CPUの設計者が気合入れてベンチマークを作って、その結果で比較していいと思います。どう使えば一番性能が出るのか分かっている人が性能を出し切った状態で比較するべきだと思います。使い方も分からないような人が適当に比較した結果で優劣を決めてしまって本当にいいのでしょうか。・・・これじゃあまるでイチロー選手にサッカーをやらせて、なんだスポーツの才能はたいしたことないな、みたいなことを言うのと同じだと思います。野球をやらせたら天下一品で、そのために練習してきたのに。

• 僕がこんなことを思うのは、結局僕が職人プログラマで、OSや言語のせいで自分の思い通りの性能が出ないでイライラした経験を何度もしているからかもしれません。・・・自分で産地まで行けば100円で買えると分かっているのに、産地に行くのが禁止で指定されたお店で150円で買わされるのに腹が立ったという感じです。で、お店での値段が200円になってもいいから、自力で産地に行って100円で買うのも許可しろ、と。・・・でもそうではない普通の人にとっては、自分は平凡なプログラムしか書かないわけで、それならそれがそれなりに速いほうがいいと思うかもしれません。確かにそれも道理です。
• それでも僕は、言い方はよくありませんが、バカにあわせてみんなバカになることはないと思うのです。バカには少々きつくても、能力に応じて成果が得られるほうがいいと信じているのです。僕の都合を無視したとしても、今のままだと結局みんなバカになって進歩はなくなるような気がするのです。
• そして不思議なことに、職人プログラマであっても「職人不要論」を唱える人がたくさんいます。自分で工夫して平均よりもずっといいプログラムを書けるのに、それでも職人がいないと出せない性能なんてほとんど価値がない、というのです。これはどういうことなんでしょうか。もう自分は疲れたから作りたくないということなんでしょうか。仮にそうだとしたら、それは老人の意見であって、その考えを苦労をいとわず最高を追い求める若者に押し付けないでほしいなと思います。・・・確かに一般向けの改良はいいことです。でも職人向けの改良だって同じくらい評価されてもいいと思うのです。そんなのはきっと平凡な人には使いこなせない、だからだめ、とかいうのはどうかと思うのです。世の中には平凡な人だけではないのです。そしてその平凡ではない人が技術を引っ張っているのですから。その人たちが気持ちよく能力を発揮できる環境を整備することがどうして「ムダ」だといわれてしまうのでしょうか。

こめんと欄