ウイルス・スパイウェア検査・駆除 用ツール Dr.WEB CureIt! を無償配布中！
人間にとってマルチタスクを行うことは効率が悪い、という話。
っていうか、人間の意識はシングルタスクなので(無意識下は並行実行らしい) コンテキストスイッチのコストが高い上に、 簡単にマルチコアにできる方法が発見されていない以上、 効率が下がるのはほぼ自明なのでは。実験で確認したという事実が重要なのかな。
もっとも、人間はわりと簡単に入手できるリソースなので、 たくさん持ってくれば効率良くマルチタスクできる...と言いたいところなのだが、 「遅れているプロジェクトに人員をつぎ込むとさらに遅れる」というルールがある通り、 マルチコアにしても問題はつきまとうのである。
これはCPUでも言えることだ。マルチコアにしても早くならない問題の方が多い。 今後のプログラミングに対する課題は、どうやってマルチコアを有効活用するかだろうな。 たぶん、人間の思考のように表層ではシングルタスク、下層ではパラレルというのが 良いのだろう。データのベクトル化とか、その辺かな。
もしかすると将来、APLのような行列指向言語が復権するかもしれない。
奥村先生による昔話。
私は当時「パソコン通信」に参加していなかったので、 伝聞でしか知らない話がたくさんあった。 当事者の話はいつも面白い。
ところで、最近圧縮特許の話をあまり聞かなくなったけど、 それはただ単に話題になっていないだけなんだろうか。
クアッドコア、8コアも目前です。性能を稼ぐにはできるだけ大きな単位で並列化しないとあかんです。スレッドぐらいの粒度でないと性能は稼げません。でも、Rubyはカーネルスレッドを使わない方針だったような。Rubyが現在のポリシーを曲げないのなら、ガベジコレクションを他のCPUからバックグラウンドで行えるようにするくらい？
ちなみに人間CPUの方も、マルチタスクするとスループットは落ちますが、応答性はあがります。人間の仕事もスループットだけではないので、バランスでしょうか。
最近は性能のための並列性はプロセスでいいじゃん、という気になってます。
スレッド以下はプログラミングが簡単になる(ことがある)時に使えばいいかと。
次期VMであるYARVはnative threadを採用することになってますから、現在のポリシーのままというわけではありません。正直、今のグリーンスレッドも残したいんですが、こればっかりは実装者の都合があるようです。
ちなみに人間CPUの方も、マルチタスクするとスループットは落ちますが、応答性はあがります。人間の仕事もスループットだけではないので、バランスでしょうか。マルチチコアにしたときに少しでもスループットを落ち方を小さくしたければ、各コアで実行する処理をなるべく疎にしなければなりません。
マルチコアの並列性の場合はスレッドぐらいの粒度でないと性能は稼げません。そういえば、Rubyはカーネルスレッドを使わない方針だったような。Rubyが現在のポリシーを曲げないのなら、ガベジコレクションを他のCPUからバックグラウンドで行えるようにするくらい？
負荷かけすぎるとダウンしますしね
昔の超並列マシンとかトランスピュータとか再発掘になるのでしょうか？
データフローマシンは無さそうです、２Ｄ言語はフローぽいですが。
2006-09-30 ■2D language
http://d.hatena.ne.jp/akaiho/20060930/1159594806
Haskellの様に、遅延評価を行って、変数の代入を禁止すると、参照透明性を保つことが出来、処理の並列化が簡単に計れるのではないかと思うのですが、Rubyでも、例えば関数単位で、参照透明性を保つ言語仕様で動作させるかどうかを指定出来るようにし、その指示に応じて、インタープリターをRuby内部で切り替えて対処する、というのはいかがでしょうか？
この改良は、恐ろしく面倒だし、プログラミングする側にとっても大変だと思いますが、いろいろな方面で多大な恩恵を受ける事が出来るのではないかと思っております。
私はADHDなので疑似マルチタスクです。