「サーバサイドでは順調だが～」とか言ってるように、デスクトップ用途の話なんですよねこれきっと。 と、なると、マルチコアが有用な利用法を考えて、かつユーザに受け入れられる必要があります。ただ、デスクトップ用途のほとんどは「人間とのインタラクション」だと考えると、人間の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:ソフトウェアって一括りにするのは間違いで (スコア:5, 興味深い)
10人の妊婦が協力しても子供は1ヶ月で産まれてこない。
Brooksが「人月の神話」でソフトウェアの開発期間についてそんなことを書いていたと記憶しています。
本質的に並列化が向いている処理と向いていない処理がある、という点でソフトウェアの並列化にも同じ事が言えます。
並列化が向いている処理というのは「他の処理と独立して行える比較的時間のかかる処理」です。
「他の処理と独立して行えない処理」を並列化するなんてのは論理的に不可能だし、
「他の処理と独立して行えるが時間のかからない処理」は並列化しても同期処理に時間がかかって
作業効率はほとんど上がらない(場合によってはかえって遅くなる)、しかも並列化プログラムは
バグ取りに非常な困難が伴うので割に合わない、というのは並列プログラムを書いたことがある人に
とっては常識ですね。
で、「他の処理と独立して行える比較的時間のかかる処理」ってのはデスクトップ用途の場合だと既に挙がっているようなものしかないわけで。
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
いや、まだ「無駄にCPUを食っていいから」という「投機的実行」パターンが残っていると思うぞ。
あとは、「従来できなかったような総当たり戦」というものも…
fjの教祖様
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
このパターンは個人的にはものすごく目から鱗だったのですが、
落ち着いて考えると、現時点でも事務用途で利用しているときのCPUパワーは
あり余ってることが多いので上に挙がってることはある程度は実現可能ですよね。
誰か既に研究しててもおかしくなさそうな感じですが、どうなのかな。。。
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
CPUでは間に合わない処理ってのは大概並列化しやすい類のものですよね
（動画エンコードとかPCゲームとか）。
特にネットワークゲームとかだとゲーム本体だけでなくてチート防止用のソフトとかも
同時実行されるので、4コアか8コアくらいまでは現状のソフトでもマルチコア化の恩恵
に授かれるんじゃないかと思ってます。
あとは、マルチコアCPUが普及した後でそれを前提としたソフトウェアの革命が起きたら面白いですね
（個人的には個人に最適化したエージェントシステムとかが有望かなとか考えてます）。
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
「今のデスクトップコンピューティングじゃない何かを考えろよ」
と言ってるのに等しい気がしますね。
# もちろんみんな考えてるさ。答はまだないが。
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
多分例がないとまた無茶言ってるよだけで終わると思うなぁ～
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
クリエイティブな仕事なんだろ
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
まぁそれなら此処で議論する必要はないだろうな
考える人は対価を得られないだろうから
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
無茶言ってるよだけで終わる人は，成功しない。
無茶をやってみる人のほとんどは，失敗する。
でも，もしかしたら，成功するかもしれない。
ってことじゃないのかな。
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
PCでもたとえば「C2Q未満のCPUは起動時チェックで蹴落として良い」と言われたら、嬉々としてチューニングを始める開発者は多いと思います。
Intelが出資して、そういうソフトウェアを増やせば良いのでは。もし目覚ましい効果があれば、実行環境の足切りも促進されるでしょう。
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
バックグラウンドではゲームという物が常に動いているわけです
マルチプロセス/スレッドで組んでくれよってだけの話なので
旧CPUを蹴落とす必要はありません
シングルCPUだとしてもその辺はOSが調整してくれます
ただし、プロセス/スレッド間通信の分処理は遅くなるでしょうが...
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
> シングルCPUだとしてもその辺はOSが調整してくれます
じゃなくて
> シングルCPUだとしてもその辺はOSが問題なく確実に調整してくれます
だったら話も違ってくるだろうけど。
プロ用の動画編集ツールとか、パフォーマンス命な製品ならともかく、マルチコアの処理能力を存分に発揮なんてしなくても現状で十分、というケースも多いだろうし。
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
単一CPUでも動作しますよ
ただし、スレッドを使う/使わないはプログラム固有の事なのでさすがにCPUが単一だから
スレッドを別けずに自動的に動作するみたいな事はOSはしてくれません
(そんなこと勝手にしたらバグが出る可能性もあるし(笑))
別けておいてもらえれば、後は選択できるので問題はないでしょう
>マルチコアの処理能力を存分に発揮なんてしなくても現状で十分
と言うかデスクトップの場合、ゲーム等後ろで何か処理し続けるって物で無いと
現状で十分って状況になり始めてるかと
画像/動画処理等処理が重い物をマルチ化して高速化するって話以上は
デスクトップ環境では不要でしょう
後は人に余ってるCPUパワー貸し出すとか？
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
そこはIntelにしてもAMDにしても、使わない時はコアを停止させるって方に進んでいるみたいだから、いっそ逆に、負荷が少ない時は本当に一つのコア以外は使わない様にするって方が有効っぽいと思う。
それだけでモバイルなんかの運用時間は目で見て解るほど変わる筈だし。
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
＃えぇ、あくまでも動画エンコード用に導入したんです。
＃＃ということにしたいなぁ。
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
見落としてたけど、これ、とても大事な指摘だと思う。
ある処理をスレッドに分割するとして、「いくつ」に分割すれば良いのでしょうか。
スレッドが少なすぎると活かされないコアが出ます。スレッドが多すぎるとタスクスイッチングのコストがもったいなくなります。
現状では、1コア～2コア、ハイパースレッディングのP4で4コアぐらいですね。現状ではこの程度なので、4スレッドに分割！ と決め打っても問題なさそうですが、4コアとか8コアとか、さらにハイパースレッディングを復活！なんて出てくれば、この辺の問題を無視できなくなりそうです。
ちょっと解決法を考えてみます。
一つの方法としては、CPUからコア数を直接聞きに行く方法が思いつきます。しかし、重い処理をするときは、処理内容をN個のスレッドに分割する処理を入れるだなんて、プログラマはたいへんだと思います。
また、「スレッド数 = コア数」と決め打って良いかどうかという問題もあります。IO処理が伴うならば、コア数より多めが良いだろうし、バックで（重めの）別プロセスが走ってる場合は、コア数より少なめが良いだろうし。
どうも OS が「仲介役」をしてくれないと、この問題の解決は難しそうです。
おっ、この「仲介役」の仕組みで特許を取れば、MSから金をがっぽりとれそうな予感！！
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
1つのコードで対応するのは困難だし、コードを分けるといろいろな問題が噴出する訳ですね。
しかし、複数の環境が同時に絡むネトゲはともかく、
他のことはそう考えなくていい単体のアプリケーションなら、
それはそれで並列化が進んでもいい様な気がします。
低級な部分（OSとか）のより進んだ対応の方が求められているんでしょうか。
そうなるとプログラマやSEの時間的余裕も必要になるので、マネージャーや営業の意識改革も必要か。
購買求心力にさほど影響しない部分だから難しそうだな…。
でもそれで本当はどうでもいい見た目の為に無駄にマルチコアのリソース食うなんて、アホくさい哀しい未来だな。
技術的に夢のある未来が見たい…。
=-=-= The Inelegance（無粋な人） =-=-=
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
>他のことはそう考えなくていい単体のアプリケーションなら、
>それはそれで並列化が進んでもいい様な気がします。
逆ですよー、複数の環境/処理が同時に進む物はマルチ化の恩恵を受けやすいんです
人の入力とは関係なしに動作可能ですから
すでにマルチスレッド対応なゲームは出ています
MMOならSWGがマルチ対応です(日本語版ぽしゃったけど)他にも有るんじゃないかな？
逆に単一アプリはどうしても入力待ち/処理待ちと言う物が存在するので
処理自体を高速化するためにマルチにする事は可能でも
入力待ちを高速化することはできません
また処理中のデータをロックする必要が出た場合、
処理が終わる前に処理中断以外の入力を受け付ける事ができません
単一アプリで効率的にマルチ処理を実施するには入力装置の革命も必要かもしれませんね
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
そこまでして性能を向上しても到底コストに見合いませんから。
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
--
flame-baitなのでAC
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
かといって、全てが全て無理にスレッド化を最適化したとして、は大した効果が無いものも多いってのも既に解っているものですし。
「使えるものを使い方を新たに考えて使う」ってのは努力目標としては良いのでしょうけど、フツーに競争を行っている市場からするとプライオリティーが下がるのも仕方ない事。
そういうものって機能は一切変わらないのに人・時間・金は食いますし、当然の様に複雑化は不安定化を生んだりしますから、それらは全て利用者のコストアップに繋がる。
利点としては効率は上がるんでしょうけど、そもそも現状で速度的な物に対して不満を上げる人間は既に減ってますし。
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
大いに異議あり。もちろんCPUとアプリの話だけのせいではないが。
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
いまの新人はマルチスレッド、非同期API前提、ステート管理による実装をどんどん叩き込まれる。
簡単にマルチコアに対応できるように始めから設計実装の方法を刷り込まれるのさ。
かつて過去のソフト屋を笑ったWin のAPI を叩く程度のアプリ屋はいま同じ立場に立たされている
ことがわからないかなぁ。
ちゃんと動作するまで実装そのものに時間がかかっているようじゃ、過去の資産を捨てるのは
怖くて仕方ないだろうけど
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
そういうのを要求される環境もあるのかも知れないが、跡2者はたいていはスレッドが使えない時に仕方なくそうするものな気がするんだがなぁ...。
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
相互依存度の密度が高くそれでいて個別に動作するトリガがバラバラなもの
だとデータ共有の同期オブジェクトの利用率が次第に高まるので
そういうブロックが５０やら１００やらを越えだすとやってられなくなる。
致命的なのはスレッドは自走しているので
配下にいる独立スレッドを上位スレッドが好きなときに
かつ配下のスレッドがいいタイミングで止める設計が
意外に面倒で、させたい仕事を実装しているのか例外処理を実装しているのか
わけわからないコードが出来上がりやすい。
つまりレスポンスが悪く、バグの生まれやすいコードが出来上がる。
同時に要求される項目が増えれば増えるほどその傾向が顕著になる。
最適なマルチコアに向けたアプリ設計ならスレッドだけでなくそれらのタームも必要ということで。
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
そりゃそうだ。
ジョブを止めたくてもスレッドは直接止めないためにステート管理をする。
セマフォやらミューテックスのロックを減らすためにはスレッドの数も抑えたい。
いろいろ反論はあるだろうけど、
例えば時間のかかる自走するスレッドのジョブに対して即時停止させたい場合にも、
停止要求を出しても止められない事由がある。この相反する要件に
内部では停止処理を始めるんだけど表向きは停止したことにして、
内部では停止完了を遅延させる。
次の要求ではリソースが重ならない限り別のジョブの受付が可能だし、
そういった（まってる間になにかほかの
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
そんなスレッドはとっとと止めるべきだと思う。
仕事が終わってからもタスクが走ってるのはCPU時間の無駄。
そのジョブがまた入るなどの理由でタスクを消滅させたくなければジョブキューあたりでジョブ待ちにしておけばいい。
>セマフォやらミューテックスのロックを減らすためにはスレッドの数も抑えたい。
なんでだろう...。
ロックの数はクリティカルなブツの数に依存するのであって、タスクの数には依存しないんだけどなー。
>例えば時間のかかる自走するスレッドのジョブに対して即時停止させたい場合にも、
...
>次の要求ではリソースが重ならない限り別のジョブの受付が可能だし、
>そういった（まってる間になにかほかのことできるでしょ）という
>観点で考えることができる。
そりゃ「停止要求を受け付けて実際に停止するまで」がそのタスクの仕事であって、
ステート云々で「待ってる間に他のこと」というのは間違い。
それこそタスクをスイッチすることで実現すべきもの。そのためのマルチタスクじゃないか？
上の「ジョブキューあたりでジョブ待ちにしておけばいい」のメカニズムを使うところだよ。
適切に排他処理されてればいくつタスクを投入しても処理経路上のコードを変更する必要はないんだし。
>なのでスレッドは実行優先順位のついた別のプロセッサだと割り切って、
>それ以上のことを期待するにはステート管理して設計しないと、もっさりアプリが出来上がるのよね。
スレッドを別のプロセッサだと考えることこそもっさりの原因だと思うけどね。
理由は最初の「とっとと止めるべきだと思う。」あたり。
(当り前だけど)プロセッサの数以上のタスクは同時には走らないんだよ？
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
プログラムの並列化の研究って、やってるところでは目一杯研究してるけど、
以前から依存関係の問題から、命令レベルでは頑張って投機実行をやっても、
IPC 4.5程度から先に進めないという結果が出ていて既に頭打ち状態。
並列化による高速化ってのは、やらせたい処理を多数の計算機資源に割り振って、
同時に実行させる事によって、処理時間を短縮しようとする訳だけど、割り振った
処理の内容に依存関係があると、処理を水平に割り振っても同時実行できなくなっ
ちゃうので、依存関係がある部分については並列化しても処理が高速に終わらない。
並列化で処理速
Re:ソフトウェアって一括りにするのは間違いで (スコア:0)
これからは、時間がかかる処理は今までのような関数呼び出しじゃなくて、スレッド起こして後で結果だけもらう(結果が要らなかったらそのまま放置)といった設計が主流になっていくと予想してるけど。
＃あまり簡単な処理はスレッド起こしてもオーバヘッドが大きいだけなので意味無いけどね。
＃＃スレッドにした方がいい閾値としては、処理時間が0.1秒〜1秒くらい？