前回、マルチコアCPUの事をかいたのですが、一部の記事で、マルチスレッドで盛り上がっているようです。
http://blogs.wankuma.com/episteme/archive/2009/09/17/181351.aspx
元記事によると、マルチスレッド/コアCPUでの開発は「Parallel Inspector」 を使えば、言語はC/C++に限定されるらしいが、効率よく開発できるらしい。
私の知識不足の為なんですが、よく解りませんでした。メリットが見えない。
確かに、マルチスレッドのコーディングはできそうです。でも、「それがどうしたの」というのが感想です。
マルチコア・スレッドは新テクノロジーではなく、随分以前からあるテクノロジーです。いまさら開発スタイルが変わるものではありません。
従来から有る手法なのに、アプリプログラムでメジャーにならないのは、必要とする分野が限られているからでしょうね。
(一般的にアプリでは)そもそも、複数コアのバランスを調整するのはOSの仕事であって、事務アプリが考慮することではありません。
アプリで考慮せよというのでは、開発の単純化の流れに逆行しますし現場が混乱するだけです。ましてや開発スタイルが変わってはいけません。
OSが割り振るスケジュールを差し置いて、アプリか実行コアに任意に指定すると、バランスが狂って逆に悪化する可能性もあります。結構調整が難しいようです。
Windowsアプリも過去の蓄積が多くなっているので、過去の資産の継承も大きな要素となっています。過去の仕様を否定してまで新仕様を普及させるのは、難しくなっていると思います。
新テクノロジの提供は、SilverlightやWPFなどにように新パラダイムの提供といった形になるのでしょうね。
画像や音声の加工処理などはメリットが大きいです。でもRDBアプリはシリアルATAやUSBが全盛なので、外部DISKをマルチスレッド/タスクで使うとQueue処理同期がコスト高になりそうだし。SCSIに戻ることはないだろうし。トラフィック限界もあるし。
事務アプリでマルチスレッドの出番ってあるのだろうか、パラレルクエリーは、RDB上の処理なので、アプリシナリオとは別次元の話ですよね。
実行中の処理中断などは、現行でも行っているし。
科学計算でも、手順は手続き型が多いので、処理を分散させて、結果を同期で取得する仕組みをつくって、同期コストを掛けるより、シングルスレッドで行ったほうがシンプルだろうし。
CPUのクロックアップは限界のようで、流れはマルチコアになってますが、シングルスレッドの実行速度はこれ以上大幅なアップしないのだろうか。パイプ段数の増加も限界がありそうだし。
RISC系CPUが復権するのだろうか...