4: 2009-11-17 (火) 12:06:24  |
現: 2024-01-08 (月) 12:58:49 k-tan |
| - | * 小さいこと・速いことをどれだけ重視するか | + | TITLE:x |
| | + | * 小さいこと・速いことをどれだけ重視するか [#dca4ecc2] |
| | -[[OsaTech]]より | | -[[OsaTech]]より |
| | -(by K, 2004.09.05) | | -(by K, 2004.09.05) |
| | | | |
| - | *** 0.重要なこと | + | *** 0.重要なこと [#i542e2ab] |
| | -以下に書いてあることは「よいこと」ではありません。速くて小さいプログラムを作るために役立つ思想が書いてあるだけであって、これはただの技術なのです。何が正しいのかとか、ここに書いてあることは正しいのかどうかではなくて、''開発をしているときだけこういう気分になりさえすれば''、小さくて速いプログラムが誰でも作れるようになりますよ、とそれだけのことなのです。小さくて速いことよりも、他のことが重要なことは十分にありえます（仕事の上ではまず納期が一番重要、なんてことはあるでしょう。・・・そんなときはどんな犠牲を払っても納期が優先です。納期に間に合うと分かってから納期に遅れない範囲で以下の努力をするのはとてもすばらしいです）。それをはき違えてはいけません。 | | -以下に書いてあることは「よいこと」ではありません。速くて小さいプログラムを作るために役立つ思想が書いてあるだけであって、これはただの技術なのです。何が正しいのかとか、ここに書いてあることは正しいのかどうかではなくて、''開発をしているときだけこういう気分になりさえすれば''、小さくて速いプログラムが誰でも作れるようになりますよ、とそれだけのことなのです。小さくて速いことよりも、他のことが重要なことは十分にありえます（仕事の上ではまず納期が一番重要、なんてことはあるでしょう。・・・そんなときはどんな犠牲を払っても納期が優先です。納期に間に合うと分かってから納期に遅れない範囲で以下の努力をするのはとてもすばらしいです）。それをはき違えてはいけません。 |
| | -以下はもっとも効果のある「技術」であり、たとえばWindowsプログラミングの範囲内であっても劇的に改善するでしょう（つまりは僕の作るwin32アプリが小さい秘訣は、これなのかな？）。これによってえられる効果（ソフトウェアの価値の向上）は10倍以上になることもあるでしょう。 | | -以下はもっとも効果のある「技術」であり、たとえばWindowsプログラミングの範囲内であっても劇的に改善するでしょう（つまりは僕の作るwin32アプリが小さい秘訣は、これなのかな？）。これによってえられる効果（ソフトウェアの価値の向上）は10倍以上になることもあるでしょう。 |
| | -もし新しいことを始める場合などは、以下の観点を多少は意識してもいいと思いますが、あまりべったりなのはよくないかもしれません。最初は試行錯誤するものですから、たくさんのコードを書いてたくさんのコードを捨てるのは避けられないでしょう。捨てるコードに時間をかけて最適化しても、それは最適化の練習くらいにしかなりませんので。むしろ、何をするべきかがしっかり決まっているときや、リファクタリングするときなどには有用な視点だと思います。 | | -もし新しいことを始める場合などは、以下の観点を多少は意識してもいいと思いますが、あまりべったりなのはよくないかもしれません。最初は試行錯誤するものですから、たくさんのコードを書いてたくさんのコードを捨てるのは避けられないでしょう。捨てるコードに時間をかけて最適化しても、それは最適化の練習くらいにしかなりませんので。むしろ、何をするべきかがしっかり決まっているときや、リファクタリングするときなどには有用な視点だと思います。 |
| | | | |
| - | *** 1.サイズや速さをどう評価するか | + | *** 1.サイズや速さをどう評価するか [#v045b31c] |
| | -非常に単純です。機能を損なうことなくサイズが半分になれば機能密度は倍になるので、サイズが半分にできたらこのプログラムは倍の価値になったと解釈します。それくらいサイズを価値あるものと認識するべきです。もちろん倍の価値であれば、値段が2倍になってもいいのです。開発時間が2倍になってもいいのです。僕はそういう価値観でOSASKに到達しました。 | | -非常に単純です。機能を損なうことなくサイズが半分になれば機能密度は倍になるので、サイズが半分にできたらこのプログラムは倍の価値になったと解釈します。それくらいサイズを価値あるものと認識するべきです。もちろん倍の価値であれば、値段が2倍になってもいいのです。開発時間が2倍になってもいいのです。僕はそういう価値観でOSASKに到達しました。 |
| | -速さも同様です。機能やサイズを損なうことなく速度が2倍になれば、それだけCPUタイムを節約できているのですから、時間に対する機能密度が倍になります。だからこのプログラムは倍の価値になったと解釈します。 | | -速さも同様です。機能やサイズを損なうことなく速度が2倍になれば、それだけCPUタイムを節約できているのですから、時間に対する機能密度が倍になります。だからこのプログラムは倍の価値になったと解釈します。 |
| | -ついでにここでサイズ最適化のためのルールを簡単に説明しておきます。80%-20%ルールによれば、コードの20%が実行時間の80%に影響しているわけで、つまりコードの80%は速度が落ちてもほとんど影響がないということです。だからそのような80%に対してはサイズ優先で最適化します。サイズ優先部分では、高速なアルゴリズムなんて不要です。単純な（いわゆる馬鹿にされているような）アルゴリズムが重宝します。 | | -ついでにここでサイズ最適化のためのルールを簡単に説明しておきます。80%-20%ルールによれば、コードの20%が実行時間の80%に影響しているわけで、つまりコードの80%は速度が落ちてもほとんど影響がないということです。だからそのような80%に対してはサイズ優先で最適化します。サイズ優先部分では、高速なアルゴリズムなんて不要です。単純な（いわゆる馬鹿にされているような）アルゴリズムが重宝します。 |
| | | | |
| - | *** 2.人間本位な考えを捨ててみる | + | *** 2.人間本位な考えを捨ててみる [#e12e7701] |
| | -今までいろいろなプログラミング手法が提唱されてきましたが、それは常に正しいことでも正義でもなんでもなく、その多くは基本的にはプログラマが楽をするためのものでしかないということを認識しなければいけません。しかし少々強引なことを言えば、本来プログラムは人間が読むために書くのではなく、機械が読むために書いているのです。だからまずは機械にとっての都合を優先してみてはどうでしょうか。この視点で今まで見えなかったものが見えてきます。 | | -今までいろいろなプログラミング手法が提唱されてきましたが、それは常に正しいことでも正義でもなんでもなく、その多くは基本的にはプログラマが楽をするためのものでしかないということを認識しなければいけません。しかし少々強引なことを言えば、本来プログラムは人間が読むために書くのではなく、機械が読むために書いているのです。だからまずは機械にとっての都合を優先してみてはどうでしょうか。この視点で今まで見えなかったものが見えてきます。 |
| | -たとえば汎用的なライブラリは非常に便利ですし、オブジェクト指向はすばらしいです。しかし汎用的なライブラリは使わない機能を多く持つ傾向がありますし、オブジェクト指向においても使わないインターフェースを大量に持ったものを知らずに使っている場合があります。 | | -たとえば汎用的なライブラリは非常に便利ですし、オブジェクト指向はすばらしいです。しかし汎用的なライブラリは使わない機能を多く持つ傾向がありますし、オブジェクト指向においても使わないインターフェースを大量に持ったものを知らずに使っている場合があります。 |
| | -僕の個人的な考えとしては、プログラミングというのは、与えられた機械で問題を解くという数学的な問題で、それは究極的には人間が自分たちの便利のために考えたルールや記法や命名規則や階層構造などには依存せず、その問題に応じたベストのルールや記法や命名規則や階層構造があるはずです。そのときの社会的背景やプログラミングスタイルの流行などによって、解が変わるなんてことはありえません。だから、そういうことは一度忘れて、まずは機械を中心に考えるわけです。 | | -僕の個人的な考えとしては、プログラミングというのは、与えられた機械で問題を解くという数学的な問題で、それは究極的には人間が自分たちの便利のために考えたルールや記法や命名規則や階層構造などには依存せず、その問題に応じたベストのルールや記法や命名規則や階層構造があるはずです。そのときの社会的背景やプログラミングスタイルの流行などによって、解が変わるなんてことはありえません。だから、そういうことは一度忘れて、まずは機械を中心に考えるわけです。 |
| | | | |
| - | *** 3.時代に依存しないプログラミング | + | *** 3.時代に依存しないプログラミング [#y0d180b3] |
| | -今はCPUが速いからとか、今はメモリがたくさんあるから、みたいな理由でベストの解は変化しません。メモリをたくさん使うけどCPUの負荷は小さいとか、CPU時間を多く使うけどメモリの負荷は小さい、みたいなのはありえます。どっちがベストなのかは状況によりますが、どちらも重要な解でしょう。どちらか一方で済むとは思えません（だからtek1だけでいいとかtek5だけで十分であるという発想は僕にはありえない）。 | | -今はCPUが速いからとか、今はメモリがたくさんあるから、みたいな理由でベストの解は変化しません。メモリをたくさん使うけどCPUの負荷は小さいとか、CPU時間を多く使うけどメモリの負荷は小さい、みたいなのはありえます。どっちがベストなのかは状況によりますが、どちらも重要な解でしょう。どちらか一方で済むとは思えません（だからtek1だけでいいとかtek5だけで十分であるという発想は僕にはありえない）。 |
| | -もしあなたがプログラムの改良を「今は～」的な理由や「これからは○○だから」的な理由でやめたのなら、それはそういうくだらないものであって、OSASKがいうところのベストではありません。たぶん時代が変わるとまた書き直すことになるんでしょう。 | | -もしあなたがプログラムの改良を「今は～」的な理由や「これからは○○だから」的な理由でやめたのなら、それはそういうくだらないものであって、OSASKがいうところのベストではありません。たぶん時代が変わるとまた書き直すことになるんでしょう。 |
| | -ということで、時代に依存したプログラムは結局その場限りのものであって、多くの人に使われてはいきません（まあそれでも無理にそういうものが普及した結果がWindowsやLinuxの肥大化なのかもしれません）。時代を言い訳にしなければいけないような中途半端なものを作るくらいなら、その数倍の時間をかけてでもベストなものを一つ作るほうがずっとマシです。 | | -ということで、時代に依存したプログラムは結局その場限りのものであって、多くの人に使われてはいきません（まあそれでも無理にそういうものが普及した結果がWindowsやLinuxの肥大化なのかもしれません）。時代を言い訳にしなければいけないような中途半端なものを作るくらいなら、その数倍の時間をかけてでもベストなものを一つ作るほうがずっとマシです。 |
| | | | |
| - | *** 4.機能の重要性 | + | *** 4.機能の重要性 [#a0269609] |
| | -必要な機能はどんどんつけるべきです。しかし利用頻度が低い上に他の機能の組み合わせで表現できるなどという場合は、そんな機能はいらないということです。いらない機能がどんなたくさんあっても、それはソフトウェアの価値にはなりません。使いにくくてサイズが無駄に増えるだけで、かえって害にもなります。 | | -必要な機能はどんどんつけるべきです。しかし利用頻度が低い上に他の機能の組み合わせで表現できるなどという場合は、そんな機能はいらないということです。いらない機能がどんなたくさんあっても、それはソフトウェアの価値にはなりません。使いにくくてサイズが無駄に増えるだけで、かえって害にもなります。 |
| | -こんな機能は機械にはつらいから本当はあったほうがいいんだけど省こう、という姿勢は行きすぎです（その論法を強烈に押し進めていいなら、0バイトの何もしないプログラムが最高の価値だということになりかねません）。その機能が人間にとって有用ならたとえプログラムのサイズや速度の低下を招いてもつけるべきです。デザインでがんばって限界に達したらそれでいいのです（これ以上機械本意にしたら目標の便利さに到達しない、など）。ただ処理があまりにも重いのなら、設定やオプションなどによって必要なときだけ機能するようにするとか、その機能がないサブセット版も用意しておくとかの、そんな工夫はあったほうがいいかもしれません。 | | -こんな機能は機械にはつらいから本当はあったほうがいいんだけど省こう、という姿勢は行きすぎです（その論法を強烈に押し進めていいなら、0バイトの何もしないプログラムが最高の価値だということになりかねません）。その機能が人間にとって有用ならたとえプログラムのサイズや速度の低下を招いてもつけるべきです。デザインでがんばって限界に達したらそれでいいのです（これ以上機械本意にしたら目標の便利さに到達しない、など）。ただ処理があまりにも重いのなら、設定やオプションなどによって必要なときだけ機能するようにするとか、その機能がないサブセット版も用意しておくとかの、そんな工夫はあったほうがいいかもしれません。 |
| | -本質的にどうしても速くできない処理は存在します。そういうものは、今のCPUをもってしても高速にはできないようなものであっても、そのようにプログラミングするしかないのです。それはプログラマのせいではありませんし、実用レベルではなくてもプログラムとしてはベストなのです。これは浪費ではないので全く問題ありません。速くできるのに速くしないのはおかしいですし、小さくできるのに小さくしないのはおかしいですが、もうこれ以上速くできないものや小さくできないものは、たとえどんなに遅くて大きくても、素晴らしいプログラムです。 | | -本質的にどうしても速くできない処理は存在します。そういうものは、今のCPUをもってしても高速にはできないようなものであっても、そのようにプログラミングするしかないのです。それはプログラマのせいではありませんし、実用レベルではなくてもプログラムとしてはベストなのです。これは浪費ではないので全く問題ありません。速くできるのに速くしないのはおかしいですし、小さくできるのに小さくしないのはおかしいですが、もうこれ以上速くできないものや小さくできないものは、たとえどんなに遅くて大きくても、素晴らしいプログラムです。 |
| | | | |
| - | *** 5.コンパイラの最適化との関係（追記） | + | *** 5.コンパイラの最適化との関係（追記） [#g7cbccb6] |
| | -もしコンパイラが十分に優秀になれば、人間はこんな苦労をする必要は全くないです。これは非常に正論であり、僕も大いに賛成であります。だからコンパイラをかしこくしようという試みは大賛成です。また、「この程度なら将来はコンパイラの最適化でカバーできるはずだから」という理由であえてプログラムを人間本位にしておくのも理にかなっていると思います。 | | -もしコンパイラが十分に優秀になれば、人間はこんな苦労をする必要は全くないです。これは非常に正論であり、僕も大いに賛成であります。だからコンパイラをかしこくしようという試みは大賛成です。また、「この程度なら将来はコンパイラの最適化でカバーできるはずだから」という理由であえてプログラムを人間本位にしておくのも理にかなっていると思います。 |
| | -僕としては、「最近はCPUが速いから人間は無駄をしてもいい」みたいな発想は（性能向上を目指すプログラミングのためには）有害でしかない、といいたいのです。コンパイラの最適化が優秀だから（もしくは優秀になる予定だから）人間はそこまで機械本位になる必要はない、ということであれば問題はないと思います。 | | -僕としては、「最近はCPUが速いから人間は無駄をしてもいい」みたいな発想は（性能向上を目指すプログラミングのためには）有害でしかない、といいたいのです。コンパイラの最適化が優秀だから（もしくは優秀になる予定だから）人間はそこまで機械本位になる必要はない、ということであれば問題はないと思います。 |
| | -いやむしろ、あてにするべきだといってもいいかもしれません。機械にできることをわざわざ苦労して人間がやるなんて、ただのコストの浪費でしかありません。しかし道具の進歩でも克服できないのなら（そんなレベルの最適化がそもそも存在するのかどうかも分かりませんが）、それは人間がやるしかありません。将来の最適化技術をあてにする場合、あるレベルの最適化が理論的に可能だとしても、その最適化コンパイラが出るまでに10年掛かるなら、10年間はその非効率プログラムで我慢することになるので、それで問題がないかを検討する必要はあるでしょう。 | | -いやむしろ、あてにするべきだといってもいいかもしれません。機械にできることをわざわざ苦労して人間がやるなんて、ただのコストの浪費でしかありません。しかし道具の進歩でも克服できないのなら（そんなレベルの最適化がそもそも存在するのかどうかも分かりませんが）、それは人間がやるしかありません。将来の最適化技術をあてにする場合、あるレベルの最適化が理論的に可能だとしても、その最適化コンパイラが出るまでに10年掛かるなら、10年間はその非効率プログラムで我慢することになるので、それで問題がないかを検討する必要はあるでしょう。 |
| | | | |
| - | * こめんと欄 | + | * こめんと欄 [#ce043121] |
| | #comment | | #comment |
