「サーバサイドでは順調だが～」とか言ってるように、デスクトップ用途の話なんですよねこれきっと。 と、なると、マルチコアが有用な利用法を考えて、かつユーザに受け入れられる必要があります。ただ、デスクトップ用途のほとんどは「人間とのインタラクション」だと考えると、人間のI/Oは並列化しづらい性質のものなので(少なくとも言語的思考の流れや注視点は2つ以上にすることは困難)、CPUにはI/Oに関係しない仕事をやらせるか、「壁紙を動画にする」などの無駄な仕事をやらせるかのどちらかになるのだと思います。 そもそも、今のPCに求められてる機能って
- In
ソフトウェアって一括りにするのは間違いで (スコア:2, 興味深い)
と、なると、マルチコアが有用な利用法を考えて、かつユーザに受け入れられる必要があります。ただ、デスクトップ用途のほとんどは「人間とのインタラクション」だと考えると、人間のI/Oは並列化しづらい性質のものなので(少なくとも言語的思考の流れや注視点は2つ以上にすることは困難)、CPUにはI/Oに関係しない仕事をやらせるか、「壁紙を動画にする」などの無駄な仕事をやらせるかのどちらかになるのだと思います。
そもそも、今のPCに求められてる機能って
- In
Re:ソフトウェアって一括りにするのは間違いで (スコア:2, 興味深い)
それこそが古く凝り固まった考え方なのではないか？と思うのです。
人間が同時に操作できない点に縛られて後ろ向きになったり、
別々の複数のソフトウェアやバックグラウンドのI/Oを走らせる用途しかアイデアがないとか、
そういう古典的な並列コアの使い方を何とかしろよと問われているのだと思うのですが。
ほとんど効果が見えないSIMD命令の類も同じ。本当に動画のエンコードぐらいしか活用方法がないの？
マルチメディア処理用命令と業界全体が思い込んでるだけじゃないの？
=-=-= The Inelegance（無粋な人） =-=-=
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
いまの新人はマルチスレッド、非同期API前提、ステート管理による実装をどんどん叩き込まれる。
簡単にマルチコアに対応できるように始めから設計実装の方法を刷り込まれるのさ。
かつて過去のソフト屋を笑ったWin のAPI を叩く程度のアプリ屋はいま同じ立場に立たされている
ことがわからないかなぁ。
ちゃんと動作するまで実装そのものに時間がかかっているようじゃ、過去の資産を捨てるのは
怖くて仕方ないだろうけど
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
そういうのを要求される環境もあるのかも知れないが、跡2者はたいていはスレッドが使えない時に仕方なくそうするものな気がするんだがなぁ...。
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
相互依存度の密度が高くそれでいて個別に動作するトリガがバラバラなもの
だとデータ共有の同期オブジェクトの利用率が次第に高まるので
そういうブロックが５０やら１００やらを越えだすとやってられなくなる。
致命的なのはスレッドは自走しているので
配下にいる独立スレッドを上位スレッドが好きなときに
かつ配下のスレッドがいいタイミングで止める設計が
意外に面倒で、させたい仕事を実装しているのか例外処理を実装しているのか
わけわからないコードが出来上がりやすい。
つまりレスポンスが悪く、バグの生まれやすいコードが出来上がる。
同時に要求される項目が増えれば増えるほどその傾向が顕著になる。
最適なマルチコアに向けたアプリ設計ならスレッドだけでなくそれらのタームも必要ということで。
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)