「サーバサイドでは順調だが~」とか言ってるように、デスクトップ用途の話なんですよねこれきっと。 と、なると、マルチコアが有用な利用法を考えて、かつユーザに受け入れられる必要があります。ただ、デスクトップ用途のほとんどは「人間とのインタラクション」だと考えると、人間の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)
相互依存度の密度が高くそれでいて個別に動作するトリガがバラバラなもの
だとデータ共有の同期オブジェクトの利用率が次第に高まるので
そういうブロックが50やら100やらを越えだすとやってられなくなる。
致命的なのはスレッドは自走しているので
配下にいる独立スレッドを上位スレッドが好きなときに
かつ配下のスレッドがいいタイミングで止める設計が
意外に面倒で、させたい仕事を実装しているのか例外処理を実装しているのか
わけわからないコードが出来上がりやすい。
つまりレスポンスが悪く、バグの生まれやすいコードが出来上がる。
同時に要求される項目が増えれば増えるほどその傾向が顕著になる。
最適なマルチコアに向けたアプリ設計ならスレッドだけでなくそれらのタームも必要ということで。
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
そりゃそうだ。
ジョブを止めたくてもスレッドは直接止めないためにステート管理をする。
セマフォやらミューテックスのロックを減らすためにはスレッドの数も抑えたい。
いろいろ反論はあるだろうけど、
例えば時間のかかる自走するスレッドのジョブに対して即時停止させたい場合にも、
停止要求を出しても止められない事由がある。この相反する要件に
内部では停止処理を始めるんだけど表向きは停止したことにして、
内部では停止完了を遅延させる。
次の要求ではリソースが重ならない限り別のジョブの受付が可能だし、
そういった(まってる間になにかほかの
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
そんなスレッドはとっとと止めるべきだと思う。
仕事が終わってからもタスクが走ってるのはCPU時間の無駄。
そのジョブがまた入るなどの理由でタスクを消滅させたくなければジョブキューあたりでジョブ待ちにしておけばいい。
>セマフォやらミューテックスのロックを減らすためにはスレッドの数も抑えたい。
なんでだろう...。
ロックの数はクリティカルなブツの数に依存するのであって、タスクの数には依存しないんだけどなー。
>例えば時間のかかる自走するスレッドのジョブに対して即時停止させたい場合にも、
...
>次の要求ではリソースが重ならない限り別のジョブの受付が可能だし、
>そういった(まってる間になにかほかのことできるでしょ)という
>観点で考えることができる。
そりゃ「停止要求を受け付けて実際に停止するまで」がそのタスクの仕事であって、
ステート云々で「待ってる間に他のこと」というのは間違い。
それこそタスクをスイッチすることで実現すべきもの。そのためのマルチタスクじゃないか?
上の「ジョブキューあたりでジョブ待ちにしておけばいい」のメカニズムを使うところだよ。
適切に排他処理されてればいくつタスクを投入しても処理経路上のコードを変更する必要はないんだし。
>なのでスレッドは実行優先順位のついた別のプロセッサだと割り切って、
>それ以上のことを期待するにはステート管理して設計しないと、もっさりアプリが出来上がるのよね。
スレッドを別のプロセッサだと考えることこそもっさりの原因だと思うけどね。
理由は最初の「とっとと止めるべきだと思う。」あたり。
(当り前だけど)プロセッサの数以上のタスクは同時には走らないんだよ?