1: 2008-07-02 (水) 03:06:59  |
2: 2008-07-02 (水) 04:08:21 |
| | *** (1) | | *** (1) |
| | -一般的に性能を比較すると、こんな感じだと思います。 | | -一般的に性能を比較すると、こんな感じだと思います。 |
| - | 「Bタイプで究極に最適化したもの」＞「Aタイプで究極に最適化したもの」＞「Aタイプで最適化していないもの」＞「Bタイプで最適化していないもの」 | + | 「Bタイプで究極に最適化したもの」 |
| | + | ＞「Aタイプで究極に最適化したもの」 |
| | + | ＞「Aタイプで最適化していないもの」 |
| | + | ＞「Bタイプで最適化していないもの」 |
| | -もしこういう順序になっていないのなら、たとえば「Bタイプで究極に最適化したもの」＜「Aタイプで究極に最適化したもの」なんてことになっていたら、それは単にBタイプの設計がヘボいだけです。Aタイプの設計が最強で、このCPUだけで十分です。また最適化してないもの同士での比較が逆転する場合は、Aタイプは最適化してもしなくてもBタイプにそれぞれ負けていることになるので、今度はAタイプの設計が不要になります。 | | -もしこういう順序になっていないのなら、たとえば「Bタイプで究極に最適化したもの」＜「Aタイプで究極に最適化したもの」なんてことになっていたら、それは単にBタイプの設計がヘボいだけです。Aタイプの設計が最強で、このCPUだけで十分です。また最適化してないもの同士での比較が逆転する場合は、Aタイプは最適化してもしなくてもBタイプにそれぞれ負けていることになるので、今度はAタイプの設計が不要になります。 |
| | -この話は何もCPUに限ったことではありません。言語やOSやアプリの設計においても同様です。 | | -この話は何もCPUに限ったことではありません。言語やOSやアプリの設計においても同様です。 |
| | *** (3) | | *** (3) |
| | -最近の世の中の流れでは「職人不要論」みたいなものがあります。つまり、職人でなくても性能が出せるようにしよう、ということです。これは実に結構なことですが、結局現状はAタイプの設計をしているだけです。最高性能が出せていないし出す方法もなくしているのです。ひどいときは、最高性能がどのくらいだったのかも忘れている場合すらあります（つまりAタイプ設計であることをやめればまだまだ性能が上がりそうなのに、その可能性に気付かなくなっていて「もう限界」だとかいう）。 | | -最近の世の中の流れでは「職人不要論」みたいなものがあります。つまり、職人でなくても性能が出せるようにしよう、ということです。これは実に結構なことですが、結局現状はAタイプの設計をしているだけです。最高性能が出せていないし出す方法もなくしているのです。ひどいときは、最高性能がどのくらいだったのかも忘れている場合すらあります（つまりAタイプ設計であることをやめればまだまだ性能が上がりそうなのに、その可能性に気付かなくなっていて「もう限界」だとかいう）。 |
| | + | -この流れのおかげで、平凡な人が適当に書いても60点くらいの結果が出ます。しかし職人が本気を出しても70点しか出せません。 |
| | -そしてこの流れのせいなのか、いわゆる「職人」も減ってきています。世の中は職人不要論に傾いているので、職人に職人向けの仕事を与えません。誰でも出来るような簡単な仕事ばかりです。職人も技を発揮する機会が無いので腕が鈍ってきます。 | | -そしてこの流れのせいなのか、いわゆる「職人」も減ってきています。世の中は職人不要論に傾いているので、職人に職人向けの仕事を与えません。誰でも出来るような簡単な仕事ばかりです。職人も技を発揮する機会が無いので腕が鈍ってきます。 |
| | -これはつまり、本当の限界を知る人が減ってきているということでもあるのです。これはかなりやばいと僕は思います。本当の限界が分からなくなって、偽りの限界を本当の限界だと思ってしまったら、Aタイプの範囲での改良は終わってしまいます。「職人不要論」では、職人でなくても性能が出せるようにしよう、が目的だったのに、結局職人がいなくなって性能も出せなくなっただけになってしまいそうなのです。 | | -これはつまり、本当の限界を知る人が減ってきているということでもあるのです。これはかなりやばいと僕は思います。本当の限界が分からなくなって、偽りの限界を本当の限界だと思ってしまったら、Aタイプの範囲での改良は終わってしまいます。「職人不要論」では、職人でなくても性能が出せるようにしよう、が目的だったのに、結局職人がいなくなって性能も出せなくなっただけになってしまいそうなのです。 |
| | *** (4) | | *** (4) |
| - | -僕はBタイプ設計のこそ正しいと思います。性能が必要な場面では職人を雇えばいいではないですか。そしてOSやCPUの設計者は、その職人の書くプログラムがもっともうまく動くように設計すればいいのです。C言語が出すプログラムが速く動くことなんて、どうでもいいおまけでしかないはずです。・・・逆に言えば、Cコンパイラに最適化オプションなんてなくてもいいのです。それはちょっと気の利いた「おまけ」でしかないのです。小学生が中学生に追いつくためのおまけでしかないのです。大人には全然届かないのです。 | + | -僕はBタイプ設計のこそ正しいと思います。平凡な人には40点くらいしか出せないでしょう。でも動くんだからいいじゃないですか。しかも職人が努力すれば80点、90点、そして100点も出しうるのです。 |
| - | -それよりもCコンパイラが重視するべきは、コンパイル時間を速くしたり、コンパイラ自身のバグが少ないことだったり、移植性の高いソースを書きやすくするために支援することなどのはずです。性能がほしいときはアセンブラを使えばいいんですし、性能よりも他のことが重要だからC言語で書いているはずなのに、それらのことを優先しないのはおかしいです。・・・OSだって、小学生が書いたプログラムをできるだけ高速に実行するようなおせっかいなんかしないで、大人が書いたプログラムを前提にして、しかし小学生が書いたプログラムでも最高速ではないけどちゃんと動くには動く、を目指すべきだと思うのです。 | + | -性能が必要な場面では職人を雇えばいいではないですか。そしてOSやCPUの設計者は、その職人の書くプログラムがもっともうまく動くように設計すればいいのです。C言語が出すプログラムが速く動くことなんて、どうでもいいおまけでしかないはずです。・・・逆に言えば、Cコンパイラに最適化オプションなんてなくてもいいのです。それはちょっと気の利いた「おまけ」でしかないのです。小学生が中学生に追いつくためのおまけでしかないのです。大人には全然届かないのです。 |
| - | -しかしそうなってはいないのです。性能を追求するべきはずのOSは性能を追求せず、性能を重視する必要のないCコンパイラは最適化の度合いを競っています。その結果、アプリがどんなにがんばってもOSが重くて足を引っ張り（特に起動時間とか）、最適化に走ったコンパイラのせいで妙なコードが出てきて悩まされます（最適化オプションをOFFにすればいい場合が多いけど、OFFにしてもコンパイラのバグで回避できない場合も経験アリ）。本当にこれでいいんでしょうか？ | + | -それよりもCコンパイラが重視するべきは、コンパイル時間を速くしたり、コンパイラ自身のバグが少ないことだったり、移植性の高いソースを書きやすくするために支援することなどのはずです。性能がほしいときはアセンブラを使えばいいんですし、性能よりも他のことが重要だからC言語で書いているはずなのに、それらのことを優先しないのはおかしいです。・・・OSだって、小学生が書いたプログラムをできるだけ高速に実行するようなおせっかいなんかしないで、大人が書いたプログラムを前提にして、しかし小学生が書いたプログラムでも（プログラムが正しい限りにおいて）高速ではないけどちゃんと動くには動く、を目指すべきだと思うのです。 |
| | + | -しかしそうなってはいないのです。性能を追求するべきはずのOSは性能を追求せず、性能を重視する必要のないCコンパイラは最適化の度合いを競っています。その結果、アプリがどんなにがんばってもOSが重くて足を引っ張り（特に起動時間とか）、最適化に走ったコンパイラのせいで妙なコードが出てきて悩まされます（最適化オプションをOFFにすれば解決する場合が多いけど、OFFにしてもコンパイラのバグで回避できない場合も経験アリ。そもそもこんなことで悩まされてもしょうがない、ってことになっていること自体がおかしい）。本当にこれでいいんでしょうか？ |
| | + | *** (5) 補足 |
| | + | -つまり僕はこうするべきだと思っています。 |
| | + | --まず、天才職人プログラマや究極の最適化プログラムを想定し、それらが使ったときに最高性能が出るように設計します。 |
| | + | --次に、平凡なプログラマがそのままでは使いこなせないのは目に見えているので、使いやすいライブラリみたいなものを用意します。このライブラリを使えば結構簡単に一通りの機能が使えます。でも性能は最高ではありません。 |
| | + | --OSASKでいうと、lib_putstringみたいなのは後者で、前者に相当するのがI.Tak.さんのNASMプログラム、中間がlib_execcmdを使う方法です。これに対し、WindowsやLinuxではlib_putstringみたいな方法までしか考えられていません（もっと込み入ったこともきっと出来るが、そういう方法を一般に説明しようという傾向がないし、込み入った方法を使えばぐっと性能が出るというわけでもない）。 |
| | + | -これに対し、世間の多くの設計はこうなっています。 |
| | + | --まず、平凡な利用者を想定し、これらが使う範囲での高速化だけを考える。しかも究極の高速化とか、最高性能とかはあまり考えていなくて、最近の普及機で実用的な性能が出ればそれでいいやくらいに思っている。 |
| | + | --自分より頭がいい人がいるかもしれないこと、そういう人たちがこの設計に不満を持つかもしれないことは想定していない。もし想定していたら、そういう人の期待にもこたえられるような拡張性を持たせるはずなんだけど、そうなってない。 |
| | + | -「職人でなくても作れるようにしよう」には無条件で賛成ですが、「職人でなくても最高性能が出せるようにしよう」は現状では不可能だと思うので、賛成できません。不可能なのに、自動最適化でできる範囲を「最高性能」だと思い込むことでごまかす今のやり方は、むしろ最悪だと思います。 |
| | + | -そして平凡な人こそ「標準」とし、平凡なプログラムでどのCPUが一番いいかを競うなんて、なんかおかしいです。CPUの設計者が気合入れてベンチマークを作って、その結果で比較していいと思います。どう使えば一番性能が出るのか分かっている人が性能を出し切った状態で比較するべきだと思います。使い方も分からないような人が適当に比較した結果で優劣を決めてしまって本当にいいのでしょうか。・・・これじゃあまるでイチロー選手にサッカーをやらせて、なんだスポーツの才能はたいしたことないな、みたいなことを言うのと同じだと思います。野球をやらせたら天下一品で、そのために練習してきたのに。 |
| | * こめんと欄 | | * こめんと欄 |
| | #comment | | #comment |
