[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 2chのread.cgiへ]
Update time : 05/09 15:34 / Filesize : 215 KB / Number-of Response : 855
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

【マルチコア】並列化について語る【使いこなせ】



1 名前:デフォルトの名無しさん [2006/01/18(水) 08:31:11 ]
最近のCPUはマルチコアが技術トレンドになっています。

それに伴い、ソフトウェアは並列化というパラダイムシフトが
求められています。効率のよく並列化を実現するためにはアル
ゴリズムやデータ構造といった部分を根本から見直す必要が
あります。しかし、トレンドができてからあまり時間が経って
ないため、そいういったノウハウが蓄積されていません。

そこで、マルチコアを生かすためのソフトウェア設計というのは
どういうものか?という議論をするためのスレッドを立てました。

ソフトウェアの並列化に対して考えのある人や、インターネット
上のリソース、論文等があればどんどん書き込んだりリンクを
貼ってください。

【関連スレ】
OpenMPプログラミング
pc8.2ch.net/test/read.cgi/tech/1102483474/l50


160 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:14:23 ]
簡単に別スレッド使える構文が欲しい。C++では何度も導入の
意見が出て却下され続けてるそうだが、

make_thread for(i=0; i<100; i++){
hogrhoge....;
}

って書いたら勝手にスレッド作ってメインは続行、for内は
独立したスレッドで動き出すみなたいな。

CreateThreadしたりオブジェクト作ったりマンドクセ

161 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:18:40 ]
現状のsmpのままだとメモリのボトルネックがもっとひどい事にならない?
コア数が増えるとクロスバースイッチとか導入するPCも出るのかな?


162 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:21:31 ]
>>159
シングルコア・シングルプロセッサの場合でも、
とあるスレッドがI/Oで待たされてる間に他のスレッドで
他の処理ができる(かもしれない)、という普通のマルチ
スレッドの利点も提供される。

イベントやトランザクションを処理するのに用いる。
スレッドは、1粒度の処理を行ったらプールに戻って
次に利用されるまでイベント待ちなどで待機する。
ずーっと続くセッションみたいなものの処理には無意味。

普通は>>155の「論理CPU数x2」とかよりもっと多くのスレッドを使う。

163 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:22:31 ]
>>160
スレッド生成クラスとラムダで事足りるからじゃないの?
make_thread終了の同期とる方法をOSから隠蔽する方が面倒くさそうだし。



164 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:33:48 ]
>スレッド生成クラスとラムダ
それなあに?

165 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:36:15 ]
どっちかっていうと閉包欲しいよ閉包。
ちょっとスレッドとかにも便利だよ。

166 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:50:57 ]
make_thread foo();

ってやったら別スレッドで関数起動してくれるのが欲しい。

167 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:52:28 ]
216.55.183.63/pdc2005/slides/TLN309_Sutter.ppt

168 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:55:31 ]
BGMの補充に関してはいわゆるブロッキングキューでいい
充填する側はキューサイズがいっぱいだとキューがあくまで待つ
そして取り出す側はキューが取り出せる状態になるまで待つ

取り出す側が待つようだと音が途切れてるので意味はないけど、
充填する側をキューサイズでコントロールできるとバッファのサイズを
コントロールしたり自前でリングバッファ持ったり待機させたりとか
面倒なことはしないですむ

ロジックだけに集中できるってことだーね

こういうのをJavaとかは用意してる
ほかにもカウントダウンラッチとかサイケリックバリアとか優先度つきキューとかもある
もうロック処理も優先順位つけたり細かく動けるようになったし
使い方は難しいがロックフリーでスレッドセーフのアトミックもある

ソフトに限らずハードも異なるクロックでキュー使うの普通だし
そういう考え方は必要だと思う

おいしいところは真似しないとな



169 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:59:42 ]
で、まあ、今話題になっているような内容は
マルチコアとは直接関係無く
普通にマルチスレッド、或いはマルチプロセッサに関する話題でして。

↓以下ループ

170 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 21:33:12 ]
一々、茶々入れんと気が済まんのか。御主は。

171 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 21:45:26 ]
普通にマルチスレッドの話でいいんでないの?
スレの名前も並列化だけだし。
マルチコアが普及することによって・・・というだけでしょ。

172 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 21:52:45 ]
あっちよりこっちが賑わってるのはスレタイの勝利ですか

173 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 21:58:02 ]
>>172
あっちってOpenMPスレ?


174 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 22:14:53 ]
マルチスレッドって名前付いてるスレ

175 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 22:25:37 ]
まあ、賑わってるって言ったって、住人の顔ぶれは
ほとんど変わらないと思うけどな。

176 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 22:31:25 ]
あっちはC+Win32ベースでしかも基本的なところから先に進んでない
単純な排他制御だけではお話になりませぬ

ロジックとしてどういうのがいいかという話のレベルまでいってないんだよな
>>1とかみてもこっちのほうが広い目というかもっと上位の話題にみえる

マルチコアを生かすのに簡単なのがマルチスレッドってだけで
マルチスレッド以外で現実的な並列プログラミングの方法があれば・・・というところだろう


177 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:14:45 ]
このスレッドの場合は極端な事を言い出しても、
まだまだ使い古されて無い技術だから叩きづらいんだよ
だから好き勝手に色々な事が言える


178 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:16:55 ]
>>164
多分、どっかの誰かが作ったスクリプト言語だったと思う




179 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:19:21 ]
まあ結局、並列化を効率よくやろうとすると、自前でスクリプト言語を作るか、
現時点で存在するスクリプト言語に頼るかの、二者択一になってくるんだよな


180 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:20:46 ]
あるいは、同期機能を駆使してC++で作るとか・・・

181 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:23:25 ]
でも、自前でスクリプト言語を作ったりすると、
わざわざマルチスレッドにする必然性が、
高速化以外には全く無くなったりする罠。w


182 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:28:21 ]
Javaもまあ、スクリプト言語の一種といえば一種か

183 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:36:41 ]
>>160
一カ所のメモリーに対する多重アクセスを防ぐのが難しくなるからかと


184 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:36:58 ]
>>178
Boost か何かのライブラリの機能でしょ。

185 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:38:03 ]
>>179
スクリプト言語は、GC という並列化と相性が悪い物を抱え込む事になる。

186 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:38:23 ]
何でマルチコアの話で「スクリプト言語」がでてくるんだ?

187 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:40:51 ]
気にしちゃダメ

188 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:44:35 ]
>>186
スレッドの管理が面倒だからかと
面倒な処理は、誰かが勝手にやってくれる方が楽だからな



189 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 00:15:33 ]
>>160
Javaならすぐかけるのにね

190 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 00:31:21 ]
そろそろC++も言語にスレッドを組み込んでしまって、何らかの
シンタックスシュガーが欲しいところ。



191 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 01:46:14 ]
たしかにJavaだと

Thread t = new Thread(){
 public void run(){
  for(int i=0;i<100;i++){
   hogehoge
  }
 }
}.start();

hugehuge//メインスレッドの処理
t.join();//おわるまでまつ

とインナークラスでかけるな
スタック変数とのやり取りでは面倒なことになるが


192 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 02:00:13 ]
スレッドの話はスレ違いだろ。スレッドだけにスレ違いw

193 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 06:15:51 ]
>>191
へ〜、Javaだと仮想関数をそんな風に作れるんだ・・・

194 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 09:46:54 ]
マルチコア時代もJavaで決まり!!!
ドントネット死滅ケテーイ(禿藁嘲笑)

195 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 11:01:49 ]
>>191
記述は楽なんだけど、外側のローカル変数を受け継いで欲しい。
中の処理にパラメータはどうやって渡すのがお行儀いいの?

>>193
仮想関数?

196 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 12:24:58 ]
>>195
受け継ぐだろ。finalにするだけで。
final必要にしたのは、リークが見つかりにくくなるからとSUN社員のブログか何かに書いてあった。

ぜんぜん並列と関係ないな…。

197 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 12:54:27 ]
final宣言されたローカル変う右派コンストラクタでコピーされて渡されてる
そもそもfinalは変更が不可能なのでお手軽に変数を渡すわけにはいかないよ
普通にクラス作ればいいだけだけどね

198 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 12:58:30 ]
>>191
>>160の例はそういうことじゃなくて、i=0からi=99までの初期状態を持つ
100個のスレッドの生成と実行と待ち合わせが簡易な構文でできればなー、
という話なのでは?

そうじゃないならCでも関数一個定義するだけだからそう面倒じゃないし、
このスレ的に迫力ないし。

>>196
ホント?Javaっていつのまにかクロージャが使えるように成ってたんだ。
世の中には信じられないようなことが起きているなあ。



199 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 13:42:21 ]
Javaのそれをクロージャと呼ぶと、変な人が湧いてくるよ。

200 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 15:58:45 ]
>>133
お前はスレッドの優先度を設定しないアホプログラマか。

201 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 16:55:05 ]
Win32限定なら、QueueUserWorkItem()一発かな。
自動的にスレッドプールを作って関数を実行してくれる。

202 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 19:01:32 ]
>>198
匿名内部クラスでぐぐれ

203 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 23:28:05 ]
マルチスレッドなんて時代遅れ。
これからはマルチコア。これだね。

204 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 00:12:15 ]
>>199
コンパイラ・スクリプトエンジン相談室によく出没するあいつらか?

205 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 00:13:24 ]
Lispこそがすべての起源。
Lispを知らずしてプログラミングを語るべからず。

206 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 01:06:43 ]
>>200
いや、プライオリティの問題もあるが、それだけじゃない。

207 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 03:25:18 ]
マルチコアだと重いタスクを裏に回せるのがメリットかね。
シングルコアで重いタスクを裏に回しても、裏のタスクの
進行が遅くなるか表のタスクが足を引っ張られることが
多い。

マルチコアなら重いタスク専門に1コア割り振れるから
表はノーペナルティ(に近い速度)で動ける。

まあ重いったって基本的にはI/Oとメモリを大量に使う
処理ぐらいしかないんだけどな。

208 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 03:36:50 ]
×マルチコアなら
〇マルチプロセッサ(HTT含)なら



209 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 08:43:17 ]
で、結局、バス幅とバスクロックの壁はどうにかなりますか?

210 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 09:03:54 ]
>>206
いくらプライオリティが低くても、
一旦CPUを割り当てられたら、割り込みがかかるまで、一定時間はCPUを占有する、
という問題はあるけれど、ユーザのインタラクティブな操作は割り込みをかけるので問題なし。

211 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 09:07:08 ]
スループットを犠牲にしてでもレスポンスを良くしたければ、
CPUの割り当て時間を短くしてしまうのも手ですよ。

たとえばWindowsの場合は、HALによっては変更をサポートしてる。
ちなみにデフォルト値がWindows2000の場合、
マルチプロセッサだとシングルプロセッサの1.5倍の時間に設定される。
WindowsXPの場合、シングルプロセッサでも、マルチプロセッサと同じ時間に設定される。
WindowsXPがモッサリな原因の1つが、1.5倍に設定されたことだよ。

212 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 13:16:58 ]
>>211
アフィニティを下げたら各コアのキャッシュが汚れるから、デュアルコア時のメリット薄いんじゃないかな。
シェアードキャッシュなら良いんだろうけど、普通 L1 はシェアしないでしょ。

213 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 14:46:16 ]
インテルのデュアルって肩並べて爆熱してるだけのツインプロセッサじゃないのか?

214 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 15:46:58 ]
IntelCoreしらんのか

215 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 17:54:54 ]
しらんがな

216 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 18:13:20 ]
>211から>212へ行く話の流れがわからない。
>212は何に関するaffinityのことを言っているの?
CPUの割り当て時間との関係は?

217 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 23:50:22 ]
Windows では Thread Affinity って言葉は使わないのかな。

と思ったが、>>211 は CPU Quantum の事を言っていたのか...
スマソ。勘違いしてた。

218 名前:デフォルトの名無しさん mailto:sage [2006/01/27(金) 22:22:57 ]
Windowsでアフィニティと言えば、
プロセスやスレッドを特定のCPUだけにしか割り当てないようにアプリがOSにお願いすることだよね。



219 名前:デフォルトの名無しさん mailto:sage [2006/01/28(土) 05:00:41 ]
それは UNIX で Processor Bind と呼んでる機能かな。

220 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 18:42:42 ]
名前を前例に倣わんのはMSの悪いところ。とはいえスレッド関連は
NTのほうがUNIXより早いんかね?

221 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 22:15:40 ]
お前ら並列プログラミングを語る前にLispについて学べ

222 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 22:23:30 ]
>>221
なんで?いまの並列化言語は論理型のほうがすすんでないか?

223 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 22:43:33 ]
Lispを知らずしてプログラミング言語を語るべからず

ム板にいながらこんな常識すら知らないとは・・・

224 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 22:46:33 ]
>>223
各所で Lisp を貶めるのは止めてくれ

225 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 22:57:15 ]
>>223
おまえみたいなのがいるからLisp使いがバカにされる

226 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 23:23:26 ]
>>223はこういう念仏を唱えるだけのアホウがいる、という話かと思ったら
アホウ当人だったのか。

こいつ、どうせLispスレじゃ何にもレスしてないよ。
以前もRuby使えないくせにあちこちのスレにRuby万歳突撃やってた基地外がいたが、
同一人物かもしれん。

227 名前:デフォルトの名無しさん mailto:sage [2006/02/02(木) 19:13:07 ]
そんなことしてるのがリアルに居るとは信じられんが、カナシス

228 名前:デフォルトの名無しさん mailto:sage [2006/02/02(木) 23:35:39 ]
正直なところ、Lisp知らん奴が語ってるのって、幼稚なんだよね。
本質でない、些細な部分に無駄に労力を費やしてるって感じ。
議論も設計もコーディングもスマートにやれるのがLisp、
これを学ばない手はないね。



229 名前:デフォルトの名無しさん mailto:sage [2006/02/02(木) 23:41:51 ]
>>228
>>224

230 名前:デフォルトの名無しさん mailto:sage [2006/02/03(金) 03:19:53 ]
Lispって何でもありすぎる。あれならマシン語で
プログラミングしてるのと代わらんような。
適度に制限されたフレームを提供するのが言語の大事な役割
というキガス。

231 名前:デフォルトの名無しさん mailto:sage [2006/02/03(金) 04:00:13 ]
>>230
>適度に制限されたフレーム

こういうのは時間とともに綻びが生じて来るから、新しいパラダイムが来たら
無理矢理建て増しするハメになるよ。既定のフレームに沿わなくてはいけない
環境では、未知の問題への適応能力も自ずと低下してしまうから、Lisp の
出自を考えると受け入れられないだろうね。

とは言っても、Lisp は元祖超高級言語なわけで、マシン語と比較する物では
無いでしょう。適度な強制が好きなあなたには Python をお勧めします。

あ、それから…、

ここは並列化のスレなんで、言語の善し悪しの話は完璧にスレ違いです。
お引き取りください。

232 名前:デフォルトの名無しさん mailto:sage [2006/02/03(金) 04:49:07 ]
俺はlisp知らんけど、
もし本当にlispが並列処理向きだったとして


現状のlispインタプリタは、マルチスレッドで並列処理してるのか?
仮にマルチスレッド動作しているとしても
並列可能な処理数はかなり大幅に増減すると思うのだが(for_eachとかあったよな?)
全部並列にやろうとするのか?スレッド数も増減させて。

まあ、スレッドプールとか使ってうまくやっているのかも知れないが。

233 名前:デフォルトの名無しさん mailto:sage [2006/02/03(金) 04:57:20 ]
>>232
>もし本当にlispが並列処理向きだったとして

Common Lisp の事なら、そもそも ANSI 規格では並列化は考慮されていない。
フリーの実装に限って言えば、マルチスレッドのコンパイラは少ない。
並列/分散処理の研究に Lisp が使われてたりはあったと思う。

234 名前:デフォルトの名無しさん mailto:sage [2006/02/03(金) 05:03:49 ]
並列化言語の側も盛り上がってないし、今の並列処理の枠組みは pthread とかに
依存しているんで、今後も C とか Java でどうするかって話が主流なんじゃないかな。
関数型言語にもちっと頑張って欲しい所。

235 名前:デフォルトの名無しさん mailto:sage [2006/02/03(金) 09:51:27 ]
どの言語がいいだの悪いだのはモノ作れるようになってから語れ
('A`)

236 名前:デフォルトの名無しさん mailto:sage [2006/02/03(金) 09:57:14 ]
自分で言語を作るのは、手間がかかるんだよ。w

続きは「コンパイラ・スクリプトエンジン」のスレッドでやらないか?


237 名前:デフォルトの名無しさん mailto:sage [2006/02/03(金) 21:26:44 ]
別に実装の話まで入り込む必要は無いんだけど、並列化を支援する言語のフィーチャーに
どんな物があるのかは興味がある。

238 名前:デフォルトの名無しさん mailto:sage [2006/02/04(土) 00:05:15 ]
>>237
そういう話題は、「マルチスレッドプログラミング相談室」で。




239 名前:デフォルトの名無しさん mailto:sage [2006/02/04(土) 05:24:48 ]
あっちは実践、こっちは理論や研究レベルってことで、こっちでもいいんじゃない?

並列化の支援というか、上にもあったと思うけど、
関数型言語なんかはプログラマが並列化なんか気にせずに並列化できたりする、理屈の上では。

これなんか実際に、後から何スレッドで動かすか指定するみたい。
www.haskell.org/haskellwiki/GHC/Concurrency#Multiprocessor_GHC

240 名前:デフォルトの名無しさん mailto:sage [2006/02/04(土) 05:28:19 ]
と思ったら普通にプログラムの方でも指定するみたいだな。
並列に出来るからって勝手に全部並列化したらオーバーヘッドの方が大きくなっちまうか。

241 名前:デフォルトの名無しさん mailto:sage [2006/02/04(土) 13:27:34 ]
ウザいLisp厨のせいで折角のふいんきが台無しだな

242 名前:デフォルトの名無しさん mailto:sage [2006/02/11(土) 19:50:33 ]
スレ頓挫か?

243 名前:デフォルトの名無しさん mailto:sage [2006/02/11(土) 20:06:40 ]
なんかネタがねぇ。だれかネタ提供してくれ。

www.coins-project.org/
そうそう、こういうのを最近みつけた。
日本のコンパイラ界の重鎮、中田育男先生とか、その他にも
Javassistの千葉滋先生とかオールスターメンバーっぽい。

SIMDによる自動並列化や、自動的に普通のコードをOpenMPに
変換してくれたりするらしい。関連した論文もたくさんでて
いるみたい。

個人的には大学で研究やっている先生方が、どの程度の実用的な
コンパイラがつくれるか注目している。マイクロソフトやインテル
なんかとも張り合えると思っているんでだけど、期待しすぎ?



244 名前:デフォルトの名無しさん [2006/02/11(土) 20:12:43 ]
たまにはageとく

245 名前:デフォルトの名無しさん mailto:sage [2006/02/11(土) 21:05:00 ]
     -‐-  
__ 〃       ヽ
ヽ\ ノノノ)ヘ)、!〉
 (0_)! (┃┃〈リ  はわわ〜マルチが245ゲットですぅ〜〜
  Vレリ、" lフ/    
    (  ̄ ̄ ̄《目
    |  ===《目
    |__|    ‖
   ∠|_|_|_|_ゝ   ‖       ∧__∧
     |__|_|     ‖       ┝・∀・┥トララーも2ゲット。
     | | |     ‖       (     ) 
     |__|__|     ‖       |〓 | 〓|   
     | \\   皿皿      (__) __). 


246 名前:デフォルトの名無しさん mailto:sage [2006/02/12(日) 10:34:53 ]
トララーがワカンネ

247 名前:デフォルトの名無しさん mailto:sage [2006/02/12(日) 23:55:41 ]
OSがプリエンプティブであればマルチコアかどうかは
さほど問題ではないと思うのだがどうか。

248 名前:デフォルトの名無しさん mailto:sage [2006/02/13(月) 00:18:59 ]
>>247
それは必要条件であって十分条件じゃない。

そもそも何に対して問題無いって言ってる訳さ?
スケジューラがプリエンプティブに出来ていたら、カーネルが
ジャイアントロックしても問題無い?

大体、マルチコアつっても色々ある訳だが、どのマルチコアを
指して問題無いって言ってるんだ?
非対称コアなのか対称なのか、キャッシュは共有されている
のかいないのか、スレッディングはあるのか無いのか、それは
SMT なのか CGMT なのか FGMT なのか??
NUMA なマルチプロセッサとマルチコアじゃ最適化ポイントが
全然違うんだぜ。

それに、マルチコアは OS だけの問題じゃ無い。コンパイラは
CPU の実装を理解して最適化を掛けているのか、アプリは
MT でスケールするように作られているのか???

ネタ振りとしてはこれくらいで良いか?



249 名前:デフォルトの名無しさん mailto:sage [2006/02/13(月) 10:57:19 ]
シングルスレッド最強

250 名前:デフォルトの名無しさん mailto:sage [2006/02/13(月) 20:52:13 ]
シングルスレッドで作って、適当にexecすればいいじゃん。
何を悩んでいるのかわからない。

251 名前:デフォルトの名無しさん mailto:sage [2006/02/13(月) 20:58:46 ]
もう面倒くさいよ。

252 名前:デフォルトの名無しさん mailto:sage [2006/02/14(火) 15:41:09 ]
おわりか

253 名前:デフォルトの名無しさん [2006/02/23(木) 13:09:55 ]
japan.cnet.com/news/ent/story/0,2000047623,20097056,00.htm
Cell向けにOctopilerツールが発表されるらしい。
どういう形で支援するか謎だ。そのあたりの情報が外部にも出してもらえると、
今後のマルチコア向けアプリケーションの開発に少しは参考になりそう。

聞きかじりなんだけど、Cellってバス予約という機能があって、コアごとに
あらかじめ必要なバス帯域をキープできて、一度に複数のバスアクセスが
集中しないようにできているみたいだね。バス帯域の問題はどうにかして
欲しいけど、PCでは同様の解決方法は難しいかな?

仕事でCellとか触れる人はいいね。自分は関係ない職種だから触れません。


254 名前:デフォルトの名無しさん [2006/02/23(木) 13:48:56 ]
マルチコアでマルチスレッド処理が平気でできれば、これから食いぶちがありますあ?

255 名前:デフォルトの名無しさん mailto:sage [2006/02/23(木) 14:21:45 ]
なにやっても食っていける。重要なのは仕事取る(就職含む)対人スキル。
プログラミングはそれからだ。

とはいえ、金出す側の鼻が利く場合に備えて腕は磨いとけ

256 名前:デフォルトの名無しさん mailto:sage [2006/02/23(木) 14:56:45 ]
ドカタ乙

257 名前:デフォルトの名無しさん mailto:sage [2006/03/04(土) 22:34:53 ]
特に意味はないが、保守っとく。
ちょっと古いけど、Timed Calculus of Communicating Systems つーのを調査中。

258 名前:デフォルトの名無しさん [2006/03/06(月) 22:39:39 ]
保守



259 名前:デフォルトの名無しさん [2006/03/06(月) 23:37:03 ]
>>257
googleで検索したけど、TCCSって何ですか?TimedがつかないCCSなら
たくさん説明があるんですが、似たものもしくは同じものなんですかね。
Calculusいうぐらいだからπ計算とかの親戚の計算モデルっぽいのは
わかるんですが。

ここを読んでいる人でプロセス代数とかやってる人っています?


260 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 08:21:54 ]
そりゃCCSなら説明がたくさんあるだろうな・・・

261 名前:デフォルトの名無しさん mailto:sage [2006/03/12(日) 02:13:05 ]
>>253
OpenMPのpragmaを流用するみたい

262 名前:http://www.vector.co.jp/soft/win95/util/se072729.html mailto:http://msdn2.microsoft.com/ja-jp/library/h2k70f3s.aspx [2006/03/18(土) 22:08:36 ]
TextSS のWindowsXP(Professional)64bit対応化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか?

そういや64bitにネイティブ対応している2chブラウザてありましたっけ?

263 名前:デフォルトの名無しさん [2006/03/18(土) 22:23:01 ]
>>261
そうなんですか。できることは限定されているような気がしますが、
普通にCellに最適化されたプログラムを書くより大分楽にはなり
そうですね。


264 名前:デフォルトの名無しさん [2006/03/22(水) 23:49:32 ]
it.nikkei.co.jp/digital/news/index.aspx?i=20060320ew000ea
やっぱり開発が難しいそうですよ。新しいノウハウが必要らしい。予想通りだ。
マルチコアはいいけどソフトウェアの負担は大きい。

265 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 00:22:34 ]
86とか汎用の石のマルチコアが難しいというのと
Cellが難しいというのとはたぶん難しい場所が違う

CellはPS2の延長と考えればすっきりするしその程度


266 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 00:25:24 ]
>>265
それが新しいノウハウだろw
PS2 のころから Vu0 マイクロコード動かしてた連中にとっては、今までの延長だろうけど


267 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 01:12:40 ]
86系ってCPUの思想があれだから、マルチコア化を困難にさせてるんだよな・・・


268 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 01:20:43 ]

こういう知ったかがわくのはどうにかならないのか?



269 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 01:22:39 ]
>>267
思想がアレなのはiApx432だろ。

270 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 01:24:49 ]
レジスタが専業化されてるってやつだろ?
今でこそ区別無く使えるようになったけど、それでもニーモニック汚過ぎ。

271 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 10:15:02 ]
uOp fusion のコストが高すぎるといってるのか?
俺には的外れに思えるが。

272 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 05:57:20 ]

こういう知ったかがわくのはどうにかならないのか?

273 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 11:57:44 ]
267が論旨を明確にすればいいだけの話。

274 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 17:50:04 ]
デコーダが複雑になるから、メニイコアでかつ個々のコアの
処理速度も上げるってのがやりにくいんじゃない?

という意味だと漏れは思う。

275 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 22:46:44 ]
つまりメタセコイアは生きた化石だということか。

276 名前:デフォルトの名無しさん [2006/05/14(日) 23:36:57 ]
鯖側は、簡単というか今まで通りでよいが、
クライアント側は大変だな。

277 名前:デフォルトの名無しさん mailto:sage [2006/05/14(日) 23:54:33 ]
そうでもない

278 名前:デフォルトの名無しさん mailto:sage [2006/09/10(日) 14:07:50 ]
ho



279 名前:デフォルトの名無しさん mailto:sage [2006/09/10(日) 20:48:00 ]
>>276
2-4 並列くらいでいいんだから余裕じゃ。
大変って言ってる奴が居たら、それは「マンドクセ」って意味か、「もっと金寄越せ」って
意味かのどちらか。

280 名前:デフォルトの名無しさん mailto:sage [2006/09/15(金) 00:56:12 ]
Objective-C + Cocoa なソースで OpenMP って使えるの??


281 名前:デフォルトの名無しさん mailto:sage [2006/09/30(土) 23:13:10 ]
Cilkってどう?

282 名前:デフォルトの名無しさん mailto:sage [2006/09/30(土) 23:34:11 ]
イソテルが発表した4コアってプログラミング的にはどうなん?
性能を活かせるコンパイラってあるの?

283 名前:デフォルトの名無しさん mailto:sage [2006/10/01(日) 00:38:46 ]
80コアか・・・
機械的に最適化できる方法あるのかな?
ttp://techon.nikkeibp.co.jp/article/NEWS/20060927/121563/?ST=edaonline&ref=rss


284 名前:デフォルトの名無しさん mailto:sage [2006/10/03(火) 09:41:30 ]
まぁ数年間は OpenMP 使ってチマチマ並列化するのが手っ取り早いだろーね。
でも 80 コアの時代には言語レベルで並列化/分散処理をサポートした
新しい言語が主流になってると思う。
そうじゃないとプログラミングがしんどくなるね。


285 名前:デフォルトの名無しさん mailto:sage [2006/10/08(日) 15:44:34 ]
そこまでしてx86である必要がないような。

286 名前:デフォルトの名無しさん mailto:sage [2006/10/08(日) 19:56:41 ]
互換性が重要だからね。
x86系は(PC/AT互換機が業界標準になったおかげで)業界標準になったから過去の互換性切れないんだよ。

287 名前:デフォルトの名無しさん mailto:sage [2006/10/08(日) 22:54:13 ]
ソースレベルで保持運用されてるUNIXなら、CPUの互換性なんて関係無いのにね。

288 名前:デフォルトの名無しさん mailto:sage [2006/10/08(日) 23:29:37 ]
そういうわけに行かない業界と素人と過去の遺産の都合を考えろってこと。
カーネルやドライバ部分なんかはCPU変わったらほぼ完全に書き直しだろうし。
CPUごとに使用するコンパイラ&ミドルウェアが変わることで開発やサポートのコストは跳ね上がる。
(商用ソフトがほとんどの場合ライセンス上の理由でソースコード公開できないことくらいは分かってると思うけど)



289 名前:288 mailto:sage [2006/10/08(日) 23:32:09 ]
×公開
○開示
だな。まぁ公開も商用である限りまず望めないだろうね。

290 名前:デフォルトの名無しさん mailto:sage [2006/10/09(月) 00:12:55 ]
倒産したソフト会社のプログラム使ってるわけでもあるまいて
その会社がコンパイルし直せば済む事をチマチマとw

291 名前:デフォルトの名無しさん mailto:sage [2006/10/09(月) 00:29:27 ]
>>290
ユーザーが増えないから売れそうもないので対応しない
バイナリが流通しないから新しいアーキテクチャのユーザが増えない
以下繰り返し

この悪循環が始まるだけなんでそういう事を言われても困る。


292 名前:デフォルトの名無しさん mailto:sage [2006/10/10(火) 01:06:52 ]
「対応しないと売れない」の間違いじゃね?
つか、対応せずに済むというのはユーザー側の思考で、本来なら企業のビジネスチャンスのためにも積極的にハードウェアアーキテクチャを変更するべきなんだよ。
儲かるのはマイクロソフトだけ。っていう図式が何を意味しているかしっかりと考えてみろ。

293 名前:デフォルトの名無しさん mailto:sage [2006/10/12(木) 15:26:01 ]
OpenMPは全然性能が出ないとか書いてあるページがあるけど、どうなのかなあ。
適切に大きな粒度でやれば、スケールしないはずが無いと思うんだけど・・・

294 名前:デフォルトの名無しさん mailto:sage [2006/10/12(木) 21:35:46 ]
>>293
それは使い方間違ってるだけだろ。
俺が反論してやるからURLキボソ


295 名前:デフォルトの名無しさん mailto:sage [2006/11/18(土) 02:08:28 ]
そいつの考え方がおかしいんじゃねーのかどこか知らんが

296 名前:デフォルトの名無しさん mailto:sage [2006/11/26(日) 14:08:24 ]
>>290
コンパイルできれば、そしてできたバイナリが予想通りの挙動を示してくれればいいんだけどね。

297 名前:デフォルトの名無しさん mailto:sage [2006/11/26(日) 14:41:15 ]
挙動不審

298 名前:デフォルトの名無しさん [2006/11/26(日) 22:38:34 ]
マルチコアって何で難しいの?同期処理も必要なの以外はvolatille宣言しとけばいいんじゃないの?
あるいはSETI@homeみたいに部分に分けて処理させるのはどうなの?
あとマルチコアって確率論とか統計学とかいるの?(学問ではなにが関係するの?)

というか今までもスパコンはほとんどマルチコアだと思うけどあれはなんで問題なく高速化できてるの?



299 名前:デフォルトの名無しさん [2006/11/26(日) 22:45:47 ]
volatile最強宣言ktkr

300 名前:デフォルトの名無しさん [2006/11/26(日) 22:53:22 ]
> マルチコアって何で難しいの?同期処理も必要なの以外はvolatille宣言しとけばいいんじゃないの?
釣りですか?

> あとマルチコアって確率論とか統計学とかいるの?(学問ではなにが関係するの?)
プロセス代数という数学。プロセス代数にはSP、π計算、CCSなどがある。

> というか今までもスパコンはほとんどマルチコアだと思うけどあれはなんで問題なく高速化できてるの?
分散処理の研究が進んでいるのと、それ様のプラットフォーム(MPIとか)が
整備されているから。何も考えずに無為にやっているけど大丈夫なわけでない。


301 名前:デフォルトの名無しさん [2006/11/26(日) 22:54:32 ]
訂正
> プロセス代数という数学。プロセス代数にはSP、π計算、CCSなどがある。

> プロセス代数という数学。プロセス代数にはCSP、π計算、CCSなどがある。


302 名前:デフォルトの名無しさん mailto:sage [2006/11/26(日) 23:10:00 ]
ヘテロ環境での最適配置戦略とか
reconfigurableなLSIを活用するとか
学者さんは嫌いそうだが必要になりそう

303 名前:デフォルトの名無しさん mailto:sage [2006/12/20(水) 00:38:23 ]
おお、こんなスレが。
並列プログラム用のライブラリを作成しています。(C++/Unix用)
pards.sourceforge.jp/
よろしければ御意見下さい。

>>166 の人のお望みの通り、SPAWN(foo());とすると関数fooを並列に実行します。
スレッドじゃなくてプロセスだけど。
プロセス間の通信、同期はSync<int> a;のように宣言した変数に対して、
a.write(1), a.read() のようにすることで行います。readはwriteが終わるまで
ブロックします。

実用的な例として、bzip2の並列化も行っています。
詳しくは上記URLをご参照下さい。宣伝失礼致しました。

304 名前:デフォルトの名無しさん mailto:sage [2006/12/20(水) 00:53:18 ]
sureddo版を作る気はないのかえ?

305 名前:303 mailto:sage [2006/12/20(水) 01:14:41 ]
スレッド版? >>304
スレッドはデフォルトで全メモリ領域をシェアするので、デバッグ困難なバグの
温床になっているという主張なのですよ > このライブラリ
グローバル変数触るだけでMT-unsafeになるので、スレッドを使った
既存のプログラムの並列化は難しいのですが、プロセスはメモリ空間を
分けるので、そんなことは無いと。
もちろんその分オーバヘッドはあるのですが、最近のOSなら我慢できる範囲では
無いかと思います。
# とか言いながらスレッド版作ったりして

306 名前:デフォルトの名無しさん mailto:sage [2006/12/20(水) 02:09:16 ]
なるほろ。

コードはそのままで、
デバッグ中は別プロセス、リリース時はスレッドで実行できるとかだと
超カッコEかもしれませんな。

ぬー、でもあんまり差が出ない気がしてきた。

307 名前:デフォルトの名無しさん mailto:sage [2006/12/20(水) 18:23:59 ]
>>303
ネットワーク越しあり?


308 名前:デフォルトの名無しさん [2006/12/20(水) 23:21:00 ]
あら、すごいと思ったけど、やはりその筋の研究をされている方ですか。

実際にどれだけパフォーマンスに差がでるかわからないけど、
スレッド版を用意してくれると実際に使う人がベンチマークが取れて
プロセス版かスレッド版かどちらかを選択するか判断できていいですな。

> スレッドはデフォルトで全メモリ領域をシェアするので、デバッグ困難なバグの
> 温床になっているという主張なのですよ > このライブラリ
さすがに含蓄のあるお言葉ですな。




309 名前:303 mailto:sage [2006/12/20(水) 23:28:00 ]
>>307
いや、SMPだけを対象にしてます。
MPC++/SCoreとか、ネットワークで接続されたコンピュータを
SMPに見せるのもあるけど、あそこまで作るのは大変っすよ(^^;

310 名前:デフォルトの名無しさん mailto:sage [2006/12/21(木) 19:53:02 ]
JAVAってマルチCPUやマルチコアでも恩恵が無いって
昔は言ってたが今は変わったのか?

311 名前:デフォルトの名無しさん [2006/12/21(木) 20:09:14 ]
>>310
JAVAはマルチスレッドにしても速度は上がらんよ。

312 名前:デフォルトの名無しさん [2006/12/21(木) 22:00:09 ]
>>310
速度を気にするならJAVAは問題外

313 名前:デフォルトの名無しさん [2006/12/21(木) 23:29:59 ]
てっきり >>194 みたいなことが書いてあるから…
.netは対応?済みらしいがマルチコア環境じゃないから試せない。

314 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 00:01:18 ]
マルチスレッドは速度を向上させるのが目的ではないと思うがなあ

315 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 00:09:25 ]
サーバ的に言えばスループットを多重化に影響されず一定とするためのものだわな。
XMLのパースとその他みたいなパイプライン?は既にやってるとこもあるみたいだけど。

316 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 00:10:31 ]
>>310-313
AP レイヤで使うのに十分なくらいならスケールするがな。
マルチノード、マルチインスタンスにはした方が良いけど、
かなりの大規模ノードじゃなければ十分。

317 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 04:56:33 ]
>>285
x86である必要があってx86なのではなく、
数が出ているx86のコストパフォーマンスが優れているからx86なのだと思う。


318 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 05:05:09 ]
>>314
何が目的なのか、ハッキリ言ってよ。

>>316
クライアントが同時に複数いる状況で性能を要求されるサーバならば、
2コアとか4コアくらいなら、
同期する必要のない部分と同期する必要がある部分に分けるだけで、
十分だったりするしね。

>>315
XMLのパースなんかは、他のスレッドと同期する必要がない処理なので、
パイプラインにするよりも、普通にスレッドプーリングでいいでしょう。



319 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 12:35:22 ]
>>310
他の言語と同じように恩恵はあるよ。
恩恵がないのは遥か昔の green thread の頃かな。


320 名前:デフォルトの名無しさん [2007/02/14(水) 06:21:12 ]
Intel,80コアでTFLOPSを実現する浮動小数点演算プロセッサ開発
ttp://www.4gamer.net/news.php?url=/news/history/2007.02/20070213183701detail.html

321 名前:デフォルトの名無しさん mailto:sage [2007/03/06(火) 16:26:58 ]
トイレで大きい方をして席に戻ってきたら、周りの席の同僚女3人に大笑いされた。

職場の女がニコニコしながら、
「上司の○○さんが呼んでいたので『地球の平和を守りにいってます!』と答えておきましたよ〜」

死にたい気持ちになった。


322 名前:デフォルトの名無しさん mailto:sage [2007/03/06(火) 16:32:41 ]
へたくそなコピペじゃねーぞ!
あまりにショックなので、こんな過疎スレに書き込んでいる。
今夜は一人で飲みたい。

323 名前:デフォルトの名無しさん mailto:sage [2007/03/06(火) 16:38:00 ]
↓あまりに悔しいから、お前のあだ名は「ウンコマン」にしてやる!

324 名前:デフォルトの名無しさん mailto:sage [2007/03/06(火) 16:47:30 ]
オッス、オラうんこまん!
地球防衛隊員ってのをやってるんだ。よろしくな!

325 名前:デフォルトの名無しさん [2007/03/06(火) 16:57:41 ]
>>324
恥ずかしい自演乙

326 名前:デフォルトの名無しさん mailto:sage [2007/03/07(水) 01:42:39 ]
>>321
なんじゃそのFFやらDQの発売日翌日に遅刻した予備校生の言い訳みたいなのは。


327 名前:デフォルトの名無しさん [2007/03/13(火) 14:25:23 ]
それより昼に仏跳麺を食った後に目薬を買おうとミドリ薬品に寄ったら会社の山下
さん(結構かわいい)がレジで支払いしてるトコだった。そのレジ台に置いてあったの
がイチジク浣腸の10個入りパッケージ。もう裕子ちゃんがお尻にイチジク浣腸を入
れてるのを想像して今も勃起しっぱなし。このことは会社の同僚にはだまってる。
噂を流したら俺だってわかるし山下さんもかわいそうだから。

328 名前:デフォルトの名無しさん mailto:sage [2007/03/20(火) 01:14:45 ]
動画エンコってマルチスレッド化するより単純にコアの数だけ時間か容量で等分して
それぞれエンコさせたファイルをつなぎ合わせた方が速そうな気がするけど、結局は>>106,115,209なの?



329 名前:デフォルトの名無しさん [2007/03/20(火) 22:13:18 ]
linuxでやれ。

330 名前:デフォルトの名無しさん mailto:sage [2007/03/21(水) 15:28:42 ]
やってみる価値は非常にありそうだな。

331 名前:デフォルトの名無しさん mailto:sage [2007/03/21(水) 16:43:18 ]
つなぎ目ってどうするんだろう
mpegでいうIフレームにすればいいだけ?

332 名前:デフォルトの名無しさん mailto:sage [2007/03/21(水) 20:02:48 ]
>>331
たぶんそうなんじゃない。
動画は前の画像の圧縮して解凍したものを使うから
ある程度の時間の動画をひとつのスレッドにしたほうが
効果ある上に作るのがとても楽だね。


333 名前:デフォルトの名無しさん mailto:sage [2007/03/21(水) 21:17:47 ]
キャッシュ効率が下がるんじゃない?

334 名前:デフォルトの名無しさん mailto:sage [2007/03/21(水) 21:47:44 ]
下がるだろうね。

キャッシュ重視で1枚の画像を複数のスレッドでMPEG圧縮する。
手間かける余裕があるかどうか。

CPUのマルチコア化を一般ユーザが使うようになるころは
メモリとかHDDの性能はどうなるのかしら。


335 名前:デフォルトの名無しさん mailto:sage [2007/03/21(水) 22:43:12 ]
エンコードに必要なワーキングセットをNとすると
総キャッシュ量/Nより多いスレッド数でやると効率下がるだけやね
・・・そこまでやるか?

336 名前:デフォルトの名無しさん mailto:sage [2007/03/22(木) 03:49:20 ]
ここだと一般論を装った妄想でお茶を濁されがちだから
Core2限定の専用スレ立てていい?

337 名前:デフォルトの名無しさん mailto:sage [2007/03/22(木) 11:25:18 ]
ダンゴ様の許可があればいい

338 名前:デフォルトの名無しさん mailto:sage [2007/03/22(木) 14:28:33 ]
>>336
Xeonは除外?



339 名前:デフォルトの名無しさん mailto:sage [2007/03/23(金) 02:25:42 ]
>>336
どんな話がどう濁されているのか具体的に。
そもそも過疎ってるんだしスレを良い方向に変えていくのも一つ。
>>338
XeonもCore2ファミリじゃね?

340 名前:デフォルトの名無しさん mailto:sage [2007/03/23(金) 02:55:13 ]
初期のXeonもCore2だっけ?

341 名前:デフォルトの名無しさん mailto:sage [2007/03/23(金) 03:15:39 ]
ダンゴ的にはどうよ?

342 名前:デフォルトの名無しさん mailto:sage [2007/03/29(木) 00:56:14 ]
結局は高クロックのシングルコアが速い?

343 名前:デフォルトの名無しさん mailto:sage [2007/03/29(木) 04:29:47 ]
それができないからthe free lunch is overなのでは?

344 名前:デフォルトの名無しさん [2007/03/29(木) 20:44:06 ]
Core2は使うレジスタ数を減らせば速いとかどっかで見たんですが
どういうことでしょうか
Pen3やNetBurst系とは逆?

345 名前:デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:00:33 ]
この質問はダンゴじゃないとマトモに返答できないと見た

346 名前:・∀・)っ-○◎● mailto:sage [2007/03/30(金) 01:52:36 ]
.

347 名前:デフォルトの名無しさん mailto:sage [2007/03/30(金) 03:33:19 ]
32bitモード、つまり
増えたレジスタを活かさないモードなら速い、ということなら
皆知ってるけどね。

348 名前:デフォルトの名無しさん mailto:sage [2007/03/30(金) 22:22:50 ]
人間活動 → スカラ
自然現象 → ベクトル
中途半端 → 今のCMP全般



349 名前:デフォルトの名無しさん [2007/04/03(火) 09:13:21 ]
       ____
     /⌒  ⌒\ ホジホジ
   /( ●)  (●)\
  /::::::⌒(__人__)⌒::::: \  <で?
  |    mj |ー'´      |
  \  〈__ノ       /
    ノ  ノ

350 名前:デフォルトの名無しさん mailto:sage [2007/04/03(火) 19:26:14 ]
おちんぽ

351 名前:デフォルトの名無しさん mailto:sage [2007/04/13(金) 21:20:44 ]
結局、下手に最適化せずに、単純なバイナリで、プロセッサに条件予測させた方が速いってことか。

352 名前:デフォルトの名無しさん mailto:sage [2007/04/15(日) 03:08:29 ]
既出かもしれんけど
cag.csail.mit.edu/ps3/index.shtml

353 名前:デフォルトの名無しさん [2007/05/06(日) 00:35:15 ]
JCSPの話はここでいいのか?

354 名前:デフォルトの名無しさん mailto:sage [2007/05/06(日) 02:41:23 ]
良いんじゃない。
Java 固有の質問だったら Java のスレでやった方が良いかもしれないけどね。

355 名前:デフォルトの名無しさん [2007/06/03(日) 02:01:31 ]
保守

356 名前:デフォルトの名無しさん [2007/06/03(日) 15:31:56 ]
逐次処理を並列処理に分割する手法で代表的なものって何?

357 名前:デフォルトの名無しさん mailto:sage [2007/06/03(日) 15:33:02 ]
OpenMP とか関数型言語で書き直すとか?

358 名前:デフォルトの名無しさん mailto:sage [2007/06/03(日) 15:41:12 ]
>>356
OpenMP、pthread、MPI 辺りですかね。

# SMP 環境でわざわざ MPI する人も少ないかもしれませんが。

ちなみに性能的には MPI > pthread > OpenMP、
お手軽さでは OpenMP > pthread > MPI の順でしょうか。




359 名前:デフォルトの名無しさん mailto:sage [2007/06/03(日) 16:43:38 ]
>>358
>ちなみに性能的には MPI > pthread > OpenMP、
ええっ!? SMP環境でMPIってpthreadより性能いいの?


360 名前:デフォルトの名無しさん mailto:sage [2007/06/03(日) 17:47:44 ]
OpenMP、pthread、MPI ってどこにあるの?

361 名前:デフォルトの名無しさん mailto:sage [2007/06/03(日) 18:15:19 ]
一番星を右に進んだ所、虹の彼方に

362 名前:デフォルトの名無しさん [2007/06/04(月) 19:05:59 ]
ジョブを並列に分割する際に、何に注目して並列化すればよいのでしょう?
データですか?タスクですか?

363 名前:デフォルトの名無しさん mailto:sage [2007/06/04(月) 19:20:07 ]
適材適所。

364 名前:デフォルトの名無しさん [2007/06/04(月) 19:22:08 ]
栄枯盛衰

365 名前:デフォルトの名無しさん mailto:sage [2007/06/06(水) 00:22:34 ]
>>359
MPIは複数の計算ノード(例えばPCとか)を高速な通信回線で接続した
HPCクラスタ用ですね。

pthreadは共有メモリシステムじゃないと使えないので、CPUの数を増や
してもいくつかの理由(メモリアクセスの集中やキャッシュコヒーレンシ
維持のためのオーバーヘッド増加)のために、システム全体の性能はある
程度で飽和してします。大体 CPU 8〜16 個くらいが限界でしょうか。

クラスタシステムではCPUだけではなくメモリも分散配置しているので、
うまく仕事を複数のノードに配分するようにプログラムを作ることがで
きれば、もっとCPUを増やしてもシステム性能を向上させることができ
ます。

# でもそのソフトを作ったりデバッグするのが大変なので、MPIは暇な
# 学生が使える教育機関でしか人気が無いような気がする…。


366 名前:デフォルトの名無しさん mailto:sage [2007/06/06(水) 13:37:00 ]
>>365
MPIが性能を十分に発揮するのは「高速な通信回線で接続したHPCクラスタ」での話ですよね

>>358
># SMP 環境でわざわざ MPI する人も少ないかもしれませんが。
>
>ちなみに性能的には MPI > pthread > OpenMP、
>お手軽さでは OpenMP > pthread > MPI の順でしょうか。
「SMP 環境でわざわざ MPI」してpthreadより性能を発揮する場面ってあるんでしょうか?
あるいは下から2行目の「MPI」っつてるのは「高速な通信回線で接続したHPCクラスタ」が前提と読むべきなんですかね?


367 名前:デフォルトの名無しさん mailto:sage [2007/06/07(木) 11:12:37 ]
358じゃないけど、
>>366
>「SMP 環境でわざわざ MPI」してpthreadより性能を発揮する場面ってあるんでしょうか?
SMPだけどNUMAなアーキテクチャとかどうなんだろ。Opteronマシンみたいなの。
pthreadでNUMA考慮して書けばいいけど、間にMPIはさんどくと、誰かが最適化してくれるかもしれない。
もう最適化されてるのかな?

MPIはHPCクラスタ用っていうけど、日立やNECも自社のスパコン用にMPI提供してて、
クラスタならmpich、スパコンならベンダオリジナルのMPIってことで計算コードを使いまわせるんで、
MPIの利用率は高いと思う。10年ぐらい前スパコン使ってたころは高かった。
メモリ共有ノード内と、分散メモリになるノード間の通信の使い分けとか考えたら、
トップスピード出すにはMPIか、その手のライブラリ使うことになると思う。

368 名前:デフォルトの名無しさん mailto:sage [2007/06/07(木) 23:03:08 ]
>>367
>SMPだけどNUMAなアーキテクチャ

これは定義矛盾
Opteron は NUMA
NUMA への最適化は最近のカーネルなら大抵入ってるよ



369 名前:デフォルトの名無しさん mailto:sage [2007/06/07(木) 23:13:02 ]
>>367
もまいはこれよめ
www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40555.pdf

370 名前:デフォルトの名無しさん [2007/06/15(金) 00:05:56 ]
これってどう?
www.rbbtoday.com/news/20051219/27869.html

371 名前:デフォルトの名無しさん mailto:sage [2007/06/15(金) 00:10:53 ]
機械語レベルで、並列化すんだろな
能書きは本当か知らんけど発想はありだな

372 名前:デフォルトの名無しさん mailto:sage [2007/06/15(金) 00:13:22 ]
>>370
ttp://www.nec.co.jp/press/ja/0512/1902.html
これのことか?

373 名前:デフォルトの名無しさん mailto:sage [2007/06/15(金) 06:55:05 ]
何を並列化するかによるわな。
マンデルブロ集合の計算とか、完全に並列化できるものなら、そらN台でN倍に
なるだろうけど、そんな簡単な用途は極めてまれなわけで。
宣伝の一人歩きだろう。

374 名前:デフォルトの名無しさん mailto:sage [2007/06/15(金) 07:46:05 ]
>極めてまれ
そうでもない。
処理はシンプルでも大量に捌かないといけない場合はままある。
#尤も、そういうケースは並列化の自動化も難しいが。

375 名前:デフォルトの名無しさん mailto:sage [2007/06/16(土) 01:44:51 ]
んなこたあねえべさ。
むしろ順次処理じゃないといけない場面の方が少ないんじゃねぇかな?


376 名前:デフォルトの名無しさん mailto:sage [2007/06/16(土) 02:10:48 ]
画像処理とオンライン系のトランザクションは並列化に向いてる処理が多いって
よくいわれるよね。××ルータ、××フィルタ、××サーバと名前に付くアプリは
並列化してナンボな物が多い。

デスクトップアプリは 4 コアもあれば十分だと思うけど。

377 名前:デフォルトの名無しさん mailto:sage [2007/06/16(土) 11:53:25 ]
大規模マルチコアプロセッサの発売に向け準備を進めるインテル
japan.cnet.com/news/ent/story/0,2000056022,20350948,00.htm

IntelのTera-Scale Computing Research Program担当共同ディレクタ
ーJerry Bautista氏によると、現在、Intelの研究者らは、コンピュータ
メーカーやソフトウェア開発者らが、大量のコアを搭載するマルチコア
チップにより簡単に適応できるようにするため、それらのチップの複雑
な機能性を意識させないための手段を模索しているという。

異種マルチコアチップ内のすべてのコアを外骨格のようなもので覆い、
それらすべてのコアを複数の従来型x86コア、あるいは1個の大きなコア
に見立てる。Bautista氏は、「それは、いわば1つのリソース貯蔵庫のよ
うになり、ランタイムがその中から適当と思うものを使用する」と述べ、
「これはプログラミングを簡略化するためだ」と付け加えた。

1個のチップ内の多様なコア間で演算タスクを分配するハードウェアスケ
ジューラを使用することにより、特定の演算タスクをより短時間で完了
できるとBautista氏は指摘する。

プログラマーたちは、キャッシュ共有技術やハードウェアスケジューリング
技術を理解したり、これに対応するためにたくさんの労力をつぎ込む必要
はない。これらのオペレーションは大抵、チップ自体によって処理される
ため表面化しないのである。

378 名前:デフォルトの名無しさん [2007/06/16(土) 16:38:55 ]
>>377
素晴らしい!!
テクノロジーの進化ってとんでもねぇなw



379 名前:デフォルトの名無しさん mailto:sage [2007/06/16(土) 22:47:24 ]
Windows出たばかりの頃の宣伝の様だが

380 名前:デフォルトの名無しさん mailto:sage [2007/06/16(土) 22:56:25 ]
まあイソテルの「プログラミングの簡略化」の範囲はアプリ屋の話で、

 コンパイラ屋ガンガレ、死ぬまでガンガレ by Intel

って漏れの耳には聞こえてるが気のせい?


381 名前:デフォルトの名無しさん mailto:sage [2007/06/16(土) 23:05:49 ]
>>380
そういうのは NetBurst や Itanic で懲りていると思いたい…

382 名前:デフォルトの名無しさん mailto:sage [2007/06/16(土) 23:42:46 ]
>380
俺にはIntel以外のコンパイラは淘汰されてしまえ
と聞こえるが

383 名前:デフォルトの名無しさん mailto:sage [2007/06/16(土) 23:54:34 ]
ARM、gcc、VC++でつかえなけりゃいみねぇー
世の中ICCが全てみたいな発想がすかん

INTELはいっつもAMDいじめて悦に浸ってる変態だし
しねってかんじだ

384 名前:デフォルトの名無しさん mailto:sage [2007/06/17(日) 00:13:12 ]
そらそうよ、Intelはパラノイアが社訓だもん

385 名前:デフォルトの名無しさん mailto:sage [2007/06/17(日) 01:16:16 ]
いよいよAMDの時代
northwood.blog60.fc2.com/blog-entry-928.html
northwood.blog60.fc2.com/blog-entry-932.html
northwood.blog60.fc2.com/blog-entry-935.html
blog.livedoor.jp/amd646464/archives/50980564.html

386 名前:デフォルトの名無しさん mailto:sage [2007/06/17(日) 01:23:55 ]
Intel社、ソフトウエアの並列化が研究開発部門の最重要課題に
www.eetimes.jp/contents/200705/19305_1_20070528174750.cfm
マルチコア・プロセッサに対する需要の高まりを受け、米Intel社はソフトウエア
の並列化を最重要課題に掲げている。その取り組みの一環として、特定用途
向けプログラミング言語や既存のプログラミング言語/アプリケーションの並列化
に関する研究に250名を投入している。「オレゴン州にある研究開発部門では、
全業務の実に約3/4をソフトウエア関連が占める」

インテルが開発ツールの新版を発売、ソフトウエアの並列化を支援
www.eetimes.jp/contents/200706/19707_1_20070605170230.cfm
コンパイラは、ベクトル化が可能な場合、SSE命令セットを利用したコードを
生成する。また、C++のテンプレート・ライブラリとして実装されているTBBを
利用すると、ソフトウエア開発者が明示的にコードを記述しなくても、マルチ
スレッド化できる。OpenMPライブラリを利用しており、実行時に利用可能な
コア数分だけスレッドを生成する。

387 名前:デフォルトの名無しさん mailto:sage [2007/06/17(日) 15:02:51 ]
AMDは甘ちゃん
IBMとIntelはプロフェッショナル

388 名前:デフォルトの名無しさん mailto:sage [2007/06/18(月) 01:10:40 ]
次世代スパコンはスカラーとベクトルの複合型に,日立/NEC/富士通の「3社連合」で開発へ
techon.nikkeibp.co.jp/article/NEWS/20070613/134173/

アーキテクチャの概要は,スカラー型プロセサからなる演算システムにアクセ
ラレータを付加し,さらにベクトル型プロセサからなる演算システムを組み合わ
せる,というもの。スカラー部とベクトル部は,共有ファイル・システムを介して
データをやり取りする。これによって様々な大規模計算シミュレーションが計算
のタイプに合わせた演算環境を選べるようになる。

ハードウエアだけでなく,ソフトウエアも同時に開発する。「制御フロントエンド」
のジョブ管理を通して,ユーザーはこれら二つのシステムの違いを意識せずに
最適な演算環境を選べるようにするという。



389 名前:デフォルトの名無しさん mailto:sage [2007/06/18(月) 06:50:59 ]
>>384
コンピュータ様って事ですね?市民。


390 名前:デフォルトの名無しさん [2007/06/18(月) 23:42:06 ]
もうすぐメニーコアがでてくるらしい。
システム設計とかどうすりゃいいんだか・・・

pc.watch.impress.co.jp/docs/2007/0611/kaigai364.htm

391 名前:デフォルトの名無しさん mailto:sage [2007/06/18(月) 23:46:07 ]
いつも通り、頭のいい人が仕組みを考えて、俺らがそれに乗っかって儲ける
で良いんじゃないかな。頭のいい人の代わりを務めようとすると大変だけど。

392 名前:デフォルトの名無しさん mailto:sage [2007/06/18(月) 23:51:36 ]
シーケンス図廃止からやってみようかな?
で、その代わりに何を使えばいい??

393 名前:デフォルトの名無しさん [2007/06/19(火) 18:18:04 ]
並列システム用のモデリングviewをUMLに策定してくれんかな。

394 名前:・∀・)っ-○◎● mailto:sage [2007/06/20(水) 00:23:28 ]
あのさー

マルチコアに限らずソフトの最適化なんて、現場レベルでボトルネック分析し
どこを重点的に並列化するか設計フェイズにフィードバックしながらやっていくもんで
日本伝統のウォーターフォールモデルじゃ、いくらお絵かきツールが便利になっても
全然役に立たんよ。

むしろUMLの本質は抽象化なんでそもそもマルチコアを意識する必要ねぇ。
逆に具体化しちゃうと、コア数の増減やパフォーマンスの見積もり違いで破綻する希ガス。

マルチスレッドは一般的にはObserverパターン、と本で得た知識をそのまま晒してみる。
ttp://www.hyuki.com/dp/cat_Observer.html

それにしても結城先生お茶目だな。

395 名前:デフォルトの名無しさん mailto:sage [2007/06/20(水) 00:28:27 ]
さてと、、、

396 名前:デフォルトの名無しさん mailto:sage [2007/06/20(水) 16:51:08 ]
Cellスレでボコボコにされて
泣く泣くこちらのスレに逃げてきた団子が
ご迷惑をおかけしております。

397 名前:・∀・)っ-○◎● mailto:sage [2007/06/20(水) 22:12:33 ]
ゲハ厨自演乙


398 名前:デフォルトの名無しさん [2007/06/21(木) 00:00:47 ]
>>396
バカかお前www
何も知らないんだなwwwww
ム板で厨認定された糞団子が帰る場所は














学歴とゲハだよwwwwwwww







399 名前:デフォルトの名無しさん mailto:sage [2007/06/21(木) 15:37:25 ]
該当するスレが見付からず、
かといってどこにかけばいいかわからないのでここで質問をします
(どこか適当なスレがあれば誘導していただければ幸いです)

今、FreeBSD 6.2のPCからPVMを起動して
Fedora 7(192.168.1.3)とVine Linux 4.2(192.168.1.4)のPCをクラスタに登録したいのですが
登録の成功をつげているのにもかかわらず
マシンには登録されていないような状況になっています

/tmp/pvml.????(????:グループID)を確認したら以下のようなメッセージが
でてきます
------------------------------
[t80040000] 06/21 15:11:35 host1 (192.168.1.2:60822) FREEBSD 3.4.5
[t80040000] 06/21 15:11:35 ready Thu Jun 21 15:11:35 2007
[t80040000] 06/21 15:14:50 netoutput() timed out sending to ryle after 14, 190.000000
[t80040000] 06/21 15:14:50  hd_dump() ref 1 t 0x80000 n "ryle" a "" ar "LINUX" dsig 0x408841
[t80040000] 06/21 15:14:50            lo "" so "" dx "" ep "" bx "" wd "" sp 1000
[t80040000] 06/21 15:14:50            sa 192.168.0.3:32790 mtu 4080 f 0x0 e 0 txq 1
[t80040000] 06/21 15:14:50            tx 2 rx 1 rtt 1.000000 id ""
[t80040000] 06/21 15:16:40 netinput() bogus pkt from 192.168.1.3:32790
------------------------------
PVMの方で勝手にタイムアウトをしているのですが
このような場合はどのようにすれば回避できるのでしょうか?

400 名前:デフォルトの名無しさん mailto:sage [2007/06/21(木) 22:38:31 ]
簡単なファイルコンバート処理(ファイル読み込み→変換→ファイル出力)を並列化したいんだけど、定番のパターンとか定石ってある?
自分で調べた感じだとProducer-Consumerパターンが使えそうなんだけど・・・。

401 名前:デフォルトの名無しさん mailto:sage [2007/06/23(土) 18:29:29 ]
UNIXのパイプ

402 名前:デフォルトの名無しさん mailto:sage [2007/06/24(日) 23:14:58 ]
フィックスターズが出している
www.shuwasystem.co.jp/cgi-bin/detail.cgi?isbn=4-7980-1462-1
は、役に立つのだろうか?
立ち読みした限りでは内容がちと薄い気がするのだが。

403 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 16:17:27 ]
>>402
それ持ってるけど、動くプログラムが書かれているだけで幸せ。
とりあえずコードを何回も書いて覚えている途中。

変な癖が付きそーだったら「違うよ」って教えてくれるとウレシイ。

404 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 20:43:30 ]
そんなレベルの奴が並列化なんかに手を出すのが間違い

405 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 21:33:51 ]
並列かなんてたいして技術いる事じゃないだろ

406 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 23:43:46 ]
そういうやつが平気でぼけぼけかますのが並列化


407 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 23:46:28 ]
科学計算レベルでの並列化と業務ソフトの並列化は同じレベルでは
語れないと思うんだが。そんな意味で入門には>>402はちょうどいい。
javaERの俺にはダグリー先生の本のほうが面白かったけど。

408 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 23:48:17 ]
>>406
一緒にするなよ



409 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 08:23:06 ]
Amazonでの評価は微妙だね。
www.amazon.co.jp/dp/4798014621


410 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 18:12:05 ]
俺は釣られないぞ

411 名前:デフォルトの名無しさん mailto:sage [2007/06/29(金) 01:44:41 ]
なんでOpenMPばっか期待されてんの?
どこにもOpenMPなんて書いてないように見えるが(本のタイトルとかに)


412 名前:デフォルトの名無しさん mailto:sage [2007/06/29(金) 01:46:42 ]
デザインパターンの本。

Javaについてはほとんどのってないので期待はずれ。

デザインパターンの本、評価は微妙。

だれもJavaって言ってないじゃん…


413 名前:デフォルトの名無しさん mailto:sage [2007/06/29(金) 13:17:14 ]
たしかに目次にも一言もOpenMPの文字はないね。。。
よく分からん書評だ。
俺は↓の本で勉強したけど分かりやすかった。くどいくらいだけど。

Win32マルチスレッドプログラミング
www.amazon.co.jp/dp/4756114040/

414 名前:デフォルトの名無しさん mailto:sage [2007/07/06(金) 09:47:57 ]
www.ebjapan.com/content/l_news/2007/07/l_news070702_0101.html
これってハードレベルで並列を実現したってこと?


415 名前:デフォルトの名無しさん mailto:sage [2007/07/06(金) 12:21:00 ]
>>414
説明読んでいたら、家政婦が私語を始めたり、殺人事件を目撃したりしてしまう展開が脳内を過ぎった。


416 名前:デフォルトの名無しさん [2007/07/07(土) 21:55:50 ]
業務レベルでの並列と、コードレベルでの並列って差があると思うのだが
対処方法ってどうなってるでしょうね?

417 名前:デフォルトの名無しさん mailto:sage [2007/07/07(土) 22:04:37 ]
>>415
FPGAのparallel random access machine/model
じゃねーのそれって?

しかし今回はそれを1個だけしか作れていないはず。
64個最大実装時(現在開発中)が現行CPUの100倍程度って事だな

まぁ、IntelとかにX86を32個とか載せた板作ってもらった方が
書きやすいと思われる。価格も現実的だし。

418 名前:デフォルトの名無しさん mailto:sage [2007/07/07(土) 22:18:17 ]
seisei.s8.xrea.com/thread/
これはどうなんだろうね?



419 名前:デフォルトの名無しさん mailto:sage [2007/07/07(土) 22:39:58 ]
>>418
うさんくさすぎねーかw

これが全部実現できるならIPAとかに公募して金もらうはず。

なんか穴があるはずだ。実用上の

420 名前:デフォルトの名無しさん mailto:sage [2007/07/07(土) 23:05:23 ]
>>418
すげぇ、胡散臭すぎて読む気にもならないよ。

421 名前:デフォルトの名無しさん mailto:sage [2007/07/07(土) 23:29:44 ]
読んでみたが、xorの計算をマルチスレッドで演算するソフトなわけね。
速度が速くなるとは書いてないようだな。

で?


422 名前:デフォルトの名無しさん mailto:sage [2007/07/09(月) 01:01:13 ]
XORをまるちすれっど?

で?

423 名前:デフォルトの名無しさん mailto:sage [2007/07/10(火) 10:41:52 ]
オーバーヘッドが少ないとか、実行時効率が良くなるとかじゃないみたいね。
分かりやすい管理方式の提案?

で? 
 
 

424 名前:デフォルトの名無しさん mailto:sage [2007/07/10(火) 11:41:21 ]
順序立てて処理する必要が無い部分はマルチスレッドで並列処理すれば蝶早く計算できる!
俺天才!!!

って事?w
URL削るともっと胡散臭いw

425 名前:デフォルトの名無しさん mailto:sage [2007/07/10(火) 15:18:46 ]
えーと自家製単純インタプリタ(command)が
並列にできるところを並列化、

という感じ?

じゃなくてこれは単なる dish の簡単な使用例か。
ttp://www2.chem.nagoya-u.ac.jp/matto/90/70Proj/dish/index.phtml


426 名前:デフォルトの名無しさん mailto:sage [2007/07/11(水) 22:20:15 ]
>>424
やばい、ドキュメントDLで金とるよ的なページもある。

427 名前:デフォルトの名無しさん mailto:sage [2007/07/11(水) 23:45:26 ]
419です。
スマン、どうやらスレ汚しをしてしまったようだ。
削除依頼してくるわ。

428 名前:デフォルトの名無しさん mailto:sage [2007/07/12(木) 00:01:42 ]
ごめん、↑は418の間違いね



429 名前:デフォルトの名無しさん mailto:sage [2007/07/12(木) 02:56:59 ]
そりゃ潔癖すぎる
気楽にやろうぜ

430 名前:デフォルトの名無しさん [2007/07/17(火) 07:17:14 ]
クロック数が違うCPUでマルチコア作ってほしい。
200MGHくらいのCPUが30個くらいついていて、2G強のCPUが一個くらいのやつ。
タスクで重いやつを2Gのやつに振るとかの処理はOSなりPG任せにする仕組みで。


無理か?

431 名前:デフォルトの名無しさん mailto:sage [2007/07/17(火) 09:33:39 ]
200MGHってのがどんなCPUか知りませんが、やってできないことではありません。
まぁ殆ど、意味はないと思いますが。

432 名前:デフォルトの名無しさん mailto:sage [2007/07/17(火) 11:49:26 ]
メガドラか

433 名前:デフォルトの名無しさん mailto:sage [2007/07/17(火) 12:32:41 ]
200メガギガヘンリー

434 名前:デフォルトの名無しさん mailto:sage [2007/07/17(火) 12:38:57 ]
200万ギザエッチ

435 名前:デフォルトの名無しさん mailto:sage [2007/07/17(火) 12:57:02 ]
200マゾガチハーレム

436 名前:デフォルトの名無しさん mailto:sage [2007/07/17(火) 21:41:58 ]
ダンゴさんのレスが望まれるところだ

437 名前:デフォルトの名無しさん mailto:sage [2007/07/18(水) 01:21:03 ]
悪趣味だな。

438 名前:・∀・)っ-○◎● mailto:sage [2007/07/18(水) 02:51:49 ]
だーんごー
だーんごー

たーっぷりー

だーんごー



439 名前:デフォルトの名無しさん mailto:sage [2007/07/18(水) 11:04:21 ]
>>438
おいこら、「つぶつぶだんご」ってフレーズが頭ん中でリピートしちまったじゃないか。

440 名前:デフォルトの名無しさん mailto:sage [2007/07/18(水) 21:12:27 ]
>438
それ、たらこだろ?

441 名前:デフォルトの名無しさん [2007/07/18(水) 23:45:04 ]
キャッシュヒット率を多少改善するくらいしかやれることなんてないだろ

442 名前:デフォルトの名無しさん mailto:sage [2007/07/18(水) 23:50:16 ]
イチローの出番だわな

443 名前:デフォルトの名無しさん mailto:sage [2007/07/19(木) 10:24:49 ]
>>430
ヘテロなマルチコアならcellがあるじゃまいか

444 名前:デフォルトの名無しさん [2007/07/19(木) 11:45:36 ]
そうじゃなくてね、クロック数の低いコアを十数個のせて低コストのプロセス
なりスレッドを割り当てして、OSなどの重い処理専用のコアというふうにわけ
れば効率よくマルチプロセス・スレッドができると思ったのよ。

>200MGH
200MHと間違えたよorz

445 名前:デフォルトの名無しさん mailto:sage [2007/07/19(木) 16:09:31 ]
>クロック数の低いコアを十数個のせて低コストのプロセスなりスレッドを割り当てして

重い処理をするコアが数パーセントの稼働率でその処理やればいいんじゃない?
あまった時間はクロックダウンして各種電源OFFしてればいいし。

ってのはともかくとして、キーボードやスイッチ、外部デバイスの監視みたいな
低速簡単タスクはPICとか使ってやってるシステムもあるよね。

446 名前:デフォルトの名無しさん mailto:sage [2007/07/19(木) 16:19:17 ]
どうやって低コストかどうかを判断するんだ。
アプリ自体にプロセス毎の振り分けフラッグでも付いてないと適切に割り当てられんし、
低コストならメインCPUでやっちゃってもすぐ終わるから問題ないとも言える。
その考え方ならCPUコア分割よりIOコストをうまく割り振ってどれだけCPUをビジーに保てるかを
考えたほうが建設的だと思う。

447 名前:デフォルトの名無しさん mailto:sage [2007/07/19(木) 21:07:21 ]
分散すれば仕事が早くなるってアホな幻想いだいてるから
間違った方向にいくんだよなぁ。

人も機械もどれだけパンクギリギリまで仕事詰め込めるかが命なのに

448 名前:デフォルトの名無しさん mailto:sage [2007/07/19(木) 22:52:24 ]
>分散すれば仕事が早くなるってアホな幻想

お前がアホなんだろw



449 名前:デフォルトの名無しさん mailto:sage [2007/07/19(木) 23:32:58 ]
無理なものは無理

450 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 00:00:15 ]
つまり馬鹿に仕事を割り振る方法を考える時間があったら
自分でやった方が速いってことだな。

451 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 00:42:36 ]
工場の単純労働者は1000人必要かもしれない
だからといって社長(+役員)は20人もいらない

452 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 00:50:41 ]
でもXeon20個搭載可能なマシンあったら
夢がひろがりんぐだろw

453 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 00:58:53 ]
>>452
それなんていう暖房機具?

454 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 01:32:05 ]
1UラックマウントのXeon*2搭載可能なサーバがあるから、10Uラックでいけるな。
暖房器具っつーか、騒音源だな。

455 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 02:00:49 ]
今なら1U3台で済むよ

QuadXeon 6個+ママン3枚でオケ

456 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 06:53:20 ]
Xeon20個っていってるのに6個って、何考えているんだ?
まさか、Xeon20個ってコア数だとおもっているのか?
おめでたいな。

457 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 09:27:02 ]
頭が4つもついてる役員は怖いです。

458 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 11:07:36 ]
バスが飽和しそうです。



459 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 23:18:00 ]
>>454-456
お前らブレードサーバも知らんのか?

6U で Xeon 20個 コア 80個ぐらいは積めるだろ。


460 名前:デフォルトの名無しさん mailto:sage [2007/07/24(火) 21:52:02 ]
japan.cnet.com/news/ent/story/0,2000056022,20353310,00.htm

461 名前:デフォルトの名無しさん mailto:sage [2007/07/25(水) 00:49:04 ]
GPL?

462 名前:デフォルトの名無しさん mailto:sage [2007/07/25(水) 00:55:38 ]
記事読んだ感じだと、例外付き GPL なんじゃないの

463 名前:デフォルトの名無しさん mailto:sage [2007/07/26(木) 00:26:11 ]
LGPLだなたしか。

でも実際これら使っても効果出る範囲狭いみたいだぞ。


464 名前:デフォルトの名無しさん [2007/08/04(土) 20:15:15 ]
タスク境界を自動で検出するTOOLないかね?

465 名前:デフォルトの名無しさん mailto:sage [2007/08/16(木) 15:32:15 ]
foobarなどで複数のエンコーダを使って処理速度を上げてるってやつがあるけど
よっぽどうまく設計しないとハードディスクへのアクセスがボトルネックとなるじゃね。

466 名前:デフォルトの名無しさん [2007/08/21(火) 09:25:35 ]
www.itmedia.co.jp/news/articles/0708/21/news021.html

467 名前:デフォルトの名無しさん mailto:sage [2007/08/21(火) 16:40:31 ]
>>465
どういう計算だよw

468 名前:デフォルトの名無しさん [2007/08/21(火) 22:27:55 ]
pc.watch.impress.co.jp/docs/2007/0821/tilera.htm



469 名前:デフォルトの名無しさん [2007/08/22(水) 13:13:48 ]
www.atmarkit.co.jp/news/200708/21/tile.html

470 名前:デフォルトの名無しさん [2007/08/23(木) 22:07:23 ]
pc.watch.impress.co.jp/docs/2007/0821/tilera.htm

471 名前:デフォルトの名無しさん [2007/08/31(金) 20:12:44 ]
Wikiペディアより
>また、Windows Vista Home Basicおよび同Home Premiumではマルチプロセッサには対応しておらず

マジか

472 名前:デフォルトの名無しさん mailto:sage [2007/08/31(金) 20:16:45 ]
>>471
そこでいうマルチプロセッサは、マルチソケットのことでマルチコアでは
ないことは理解してる?

473 名前:デフォルトの名無しさん mailto:sage [2007/08/31(金) 20:26:13 ]
一応理解している。
シングルコアをくっつけて作るデュアル環境と、ダイに複数コアをのっける
ものの違いだと認識している。


多分

474 名前:デフォルトの名無しさん mailto:sage [2007/08/31(金) 20:40:22 ]
XP HOMEもそうだったでしょ。
物理CPUに対応してるのは1個まで。
物理CPU1個ならコアが4個あっても大丈夫(のはず)

物理CPU2個はXP PROFESSIONALから。4個以上は知らない。

475 名前:デフォルトの名無しさん mailto:sage [2007/08/31(金) 22:48:30 ]
それは違うぞ。

476 名前:デフォルトの名無しさん mailto:sage [2007/08/31(金) 23:02:14 ]
じゃあどうなの

477 名前:デフォルトの名無しさん mailto:sage [2007/08/31(金) 23:03:08 ]
いや、自分でもよくわからないんだけどさ

478 名前:デフォルトの名無しさん mailto:sage [2007/09/01(土) 00:01:00 ]
>>473
ちがうよ。
マルチプロセッサってのは文字通り
マザボに CPU を複数のっけることだよ。
ハードディスクを 2 個繋げたり
メモリを 4 枚さすのと同じ。




479 名前:デフォルトの名無しさん mailto:sage [2007/09/01(土) 00:20:57 ]
www.atmarkit.co.jp/fwin2k/special/whatiswin2k_rev1/server4.html
       Windows 2000 Server Advanced Server
最大SMP CPU数    4CPU         8CPU

win64xp.impress.co.jp/change/index.htm
      Windows XP Professional Windows XP Professional x64 Edition
対応CPU数      2                   2

q.hatena.ne.jp/1185032304
1.WindowsXP HomeEdition … 1 ソケット
2.WindowsXP ProfessionalEdition … 2 ソケット
3.WindowsVista HomePremiumEdition … 1 ソケット
4.WindowsVista BusinessEdition … 2 ソケット
5.WindowsVista UltimateEdition … 2 ソケット
6.WindowsServer2003 StandardEdition … 4 ソケット

コア数は4個だろうが8個だろうが全て認識するようです

480 名前:デフォルトの名無しさん mailto:sage [2007/09/01(土) 08:45:16 ]
コアが32個あるタスクメジャー見たなwwwwwwww

481 名前:デフォルトの名無しさん [2008/01/15(火) 17:42:48 ]
並列化・並列計算のスレってこの板には多分ここくらいしかないので、
ここで質問します。

太陽系の惑星の軌道を並列計算をするときに、
時刻tでの惑星の速度と位置のデータを
他のプロセスに渡して次の時刻(t+1)の速度と位置を計算させて、
全ての惑星の分を計算し終わったら次の時刻の計算を・・・
と繰り返す処理をPVM + C言語で組んでいるのですが、
どうもデータの送受信部分のコーディングがうまくいきません。

繰り返し1回目はちゃんと結果が帰ってくるんけど、
2回目は送信はできるけど計算結果が帰ってこない、
というような状況になっております。

並列計算で繰り返し処理を行う場合は
データの送受信の処理はどのようにコーディングすればいいのでしょうか。
(作りかけのプログラムをどっかにうpしたほうがいいんですかね・・・?)

482 名前:デフォルトの名無しさん mailto:sage [2008/01/15(火) 17:56:30 ]
>>481
MPIのスレがあるぞ

483 名前:デフォルトの名無しさん [2008/01/16(水) 19:20:30 ]
>>482
そうなんですがMPI以外の話になっちゃうので
抵抗がありまして・・・

484 名前:デフォルトの名無しさん mailto:sage [2008/01/16(水) 20:30:46 ]
地球時間とか木星時間の一年周期で同期したらいいんじゃね

485 名前:デフォルトの名無しさん [2008/03/29(土) 13:31:27 ]
cygwin+gccだとどのような方法がありますか?


486 名前:デフォルトの名無しさん mailto:sage [2008/04/06(日) 22:12:28 ]
ない

487 名前:デフォルトの名無しさん mailto:sage [2008/04/07(月) 12:52:16 ]
lam-mpiならcygwinにインスコできた。
mpichもたぶんできる。

488 名前:デフォルトの名無しさん mailto:sage [2008/04/08(火) 08:42:45 ]
IntelのCt言語っててにはいるのかな?



489 名前:デフォルトの名無しさん mailto:sage [2008/04/21(月) 23:13:24 ]
「小飼弾のアルファギークに逢ってきた」っていう本に
Dave ThomasがErlangの本を書いているって書いてあったんだけど
詳細が分かる人いますか?

07年7月に出版予定とか書いてあったけど、どうもAmazonの洋書でそれらしいものがない。

490 名前:デフォルトの名無しさん mailto:sage [2008/04/21(月) 23:14:06 ]
すみません。
誤爆しました。

491 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 21:21:30 ]
128bit レジスタ を 8 コアで SSE 拡張として繋げて、
1024bit のベクトルプロセッサとして使える。

、、、とかだったら面白くなりそうなんだけどな

492 名前:デフォルトの名無しさん mailto:sage [2008/04/28(月) 13:11:09 ]
>>491
どれかのプロセスがそれをやっている間他のプロセスが割りを食いそうだからやだ。

493 名前:デフォルトの名無しさん mailto:sage [2008/04/28(月) 18:17:35 ]
>>491
逆に並列性が下がりそう

494 名前:デフォルトの名無しさん mailto:sage [2008/04/28(月) 21:44:59 ]
素朴な疑問だけど、これからはメニーコアの時代、とかいうが、
コア間で「人月の神話」と同じ問題は発生しないのかえ

495 名前:デフォルトの名無しさん mailto:sage [2008/04/29(火) 09:07:34 ]
する。

496 名前:デフォルトの名無しさん mailto:sage [2008/04/29(火) 11:53:18 ]
つーか、大昔からのマルチプロセッシングの課題が
いかにリニアにスケールさせるか、です。

497 名前:デフォルトの名無しさん mailto:sage [2008/04/29(火) 14:01:25 ]
それじゃ漠然としすぎて無意味だよ

498 名前:デフォルトの名無しさん mailto:sage [2008/04/29(火) 14:08:39 ]
大昔からリニアにスケールさせるにはどうしたらいいかって話で
結局は個別対応になるから、一般論として本当に軽い話しかできない

古い記事だけどマルチコア、マルチスレッドで
どこらへんに苦労したかっていうのは書いてあるけどほとんど一般論
www.4gamer.net/specials/capcom_x_intel/capcom_x_intel_01.shtml

EfficientC++も肝心の部分は結局言及できずにたいしたことは書いてなかった。
だから、個別の事例をまとめるしかないと思うが、そういう記述をできる人は
その筋で仕事してたりする人ぐらいだから記事としては出てこないだろうし
結局は本人の試行錯誤という。



499 名前:デフォルトの名無しさん mailto:sage [2008/04/29(火) 14:28:00 ]
>>497
知りたいことの的を絞ってくれればある程度話ができるよ。

500 名前:デフォルトの名無しさん [2008/05/10(土) 13:46:08 ]
mac osx ppc64 で tbb を使って遊んでみようと思ってます(当然シングルコアなので雰囲気だけ)

ところが、libtbb.dylibとlibtbbmalloc.dylib を入れてもリンクエラーが発生します。
自分でソースからビルドしてdylibを作り直してもダメ。
dylibの中をみてもそれらしいシンボル名がないようなんですが、どうすれば動くんでしょうか。



501 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 14:33:45 ]
おおむね一年研究してみたが、マルチコア化でいちばん厄介なのは

1.どれだけスレッドセーフなコードを簡単に作れるか
2.どれだけスレッドセーフを意識しなくてもよくできるか

の二点にかかっている、これに伴って

スレッド化が問題を引き起こすのは、作る側、使う側の間で、仕様伝達がもつれてしまったり、
一旦スレッド化すると、非スレッドセーフに戻したり、逆に非スレッドセーフに作ったコードを簡単にスレッド化できない事で
オブジェクト指向で言えば、オブジェクト間の結合がスレッドによってむやみに強められてしまう点がまずい。
スレッドセーフは、メソッドにつけられる属性の一つとして機能するが、言語機構てきに簡単には取り付けられない。
なにしろ、何につていスレッドセーフかという問題もあって厄介だ。
逆のこの点を解消すれば、むしろ色々な物(IO同期処理等)が統合できて便利だと思った。
『やりたいことの記述と、どう実装するかの記述を分離する事』が最も重要だ。

>結局は個別対応になるから、一般論として本当に軽い話
初めて見た時は不可能そうに見えたが、一般論化しないかぎり成功しない、そしてそれは不可能でもないと思った。
逆に、タスクシステムなどという事をやっているうちは全くモノにならないという点も見えてきた。
一言でいえば、いかにサクッと書けるか書き換えられるか、同期が必要なデータが明白化できるかが、そのまま並列化の性能になってしまう。
並列化はパフォーマンスを求めるために使う技術だが、パフォーマンスを求ている内は使い物になりそうにない。
VBが、GUIのコードをあっさり書けるようして、実用的にしたように、マルチコア化も同様なものが必要でスケールとかは意識しても仕方がないと思った。
概念として重要そうなのは、C#やVBのLINQやHaskell等で実装されている遅延評価が使えそうだという点か。

502 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 15:17:55 ]
CPU・・・衝突、不一致を嫌う設計
脳・・・衝突、不一致を積極的に利用

CPUの設計原理を変えずに、脳の真似をするのは難しい。

503 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 18:27:12 ]
>>501
> 逆に、タスクシステムなどという事をやっているうちは全くモノにならないという点も見えてきた。

業務用ゲーム業界に職人技的に伝えられてきたというあの「タスクシステム」?

504 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 18:51:40 ]
タスクシステムなんてこのWEB全盛時代にはもはや化石だなw

505 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 19:31:26 ]
並列化のキーワードは網羅って聞いたことがあるような。
例えばソートだと、順列(全パターン)を作ってそれが並んでいるか調べるだけでいい。

現在の手法は今までのアルゴリズムを並列化しようとしているからロックとかで問題になっているんでしょ?
アルゴリズムを根本から変えれば良いと思うけど。

506 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 20:18:15 ]
>>503
カプコンのMTフレームワークは使うかどうかはともかく、見ておく価値はあるよ。
watch.impress.co.jp/game%2Fdocs/20070131/3dlp.htm
十分とは思えないが、役に立たない理屈と違い実戦的な並列化手法の一つだから。

507 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 20:19:49 ]
>>505
量子コンピュータ時代になれば、役に立つかもなw

508 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 21:15:20 ]
>>507
ある程度コア数が大きくなったら役立ちそうだと思うけど
別に1パターン1コアに分けなくてもいいし。



509 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 21:59:00 ]
>>508
> ある程度コア数が大きくなったら役立ちそうだと思うけど

算数からやり直した方がいいと思う。

510 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 23:18:15 ]
>>508
たとえば1000の組み合わせの数を数えてみたらどうかな?
n qubitに対して、並列度が 2^n である量子コンピュータなら
2^1000程度の並列度を持たせれば、その組み合わせ数にも打ち勝てる可能性はあるが、
10個や20個のコアでなんとかなるかな?

511 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 23:58:22 ]
あーかなり勘違いしてたよ。
でも、そこに道があるような気がする。
アルゴリズムが分かりやすいし。

512 名前:デフォルトの名無しさん mailto:sage [2008/05/12(月) 07:51:09 ]
>>511
極めて単純なものだけに有効でしかないよ
総列挙を行うと、ひとつ条件分岐が増えるごとに二倍になる。倍々ゲームだからな。
宇宙の全素粒子をトランジスタにしたって追いつかないほどの並列度がすぐに必要になる。
そして、総列挙以外の方法で解けない問題はNP問題といって、楽しい研究対象だ。
量子コンピュータは、時間的な並行宇宙が倍々ゲームで増えていくことを利用して、
自分たちが感知できない別の宇宙にコンピュータを配置する、
今配置すれば、処理を何工程か経ることによって未来の並行宇宙に倍々ゲームでマシンを配置できる。
これに一斉処理をさせれば、宇宙の全素粒子の冪乗に当たるような並列度が取れるので、解けることもある。
ただし、結果を得る方法がきわめて特殊なので、結局解けないケースが多い。
それにしても一番気になるのは計算機よりも並行宇宙そのものだ。

513 名前:デフォルトの名無しさん mailto:sage [2008/05/12(月) 21:09:31 ]
量子コンピュータを神秘視しすぎだろwww

514 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 09:02:31 ]
>>513
逆に問うてみようか、並行宇宙でないとすると、ありゃ何処で計算されてるいんだ?
どうころんでも、どう解釈してもキモ過ぎだよ

515 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 09:15:37 ]
量子の状態は重ね合わせで表されるような状態である。
それは量子というものの性質そのものであって、解釈なぞどうでもよい。

キモいと言えばキモい性質ではある。

516 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 03:50:53 ]
並行宇宙ワロタ

517 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 06:37:49 ]
並行宇宙ヤバイ

518 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 19:49:58 ]
>>512マジキモイ



519 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 19:51:44 ]
2XXX年のオリコン一位

「並列宇宙」

520 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 22:01:54 ]
>>517-519 話についていけないなら泣いていい(笑)
はたしてテンソル積はどこまでも増やしてゆけるのか
量子コンピュータをみていると、現在の物理法則はどこまで正しいかどうか見ものだよ。

521 名前:デフォルトの名無しさん mailto:sage [2008/05/17(土) 01:31:05 ]
Erlangスレに進展があったよ。
どっかのいい人がホームページ作ってくれたみたい。

522 名前:デフォルトの名無しさん mailto:sage [2008/05/17(土) 03:24:15 ]
宗教の話は他でやってくれないか。

523 名前:デフォルトの名無しさん mailto:sage [2008/05/17(土) 04:33:17 ]
ミクロとマクロの視点を
ごっちゃにしているアホが騒いでいるだけ

524 名前:デフォルトの名無しさん mailto:sage [2008/05/17(土) 05:23:47 ]
>>520
量子コンピュータが量子力学の正しさを証明しても
並行宇宙解釈が主流になる事は無いと思われ

525 名前:デフォルトの名無しさん mailto:sage [2008/05/17(土) 05:33:35 ]
ここム板やで。

526 名前:デフォルトの名無しさん mailto:sage [2008/05/18(日) 14:45:50 ]
>>1
boinc環境を用意してねらーを煽る。


527 名前:デフォルトの名無しさん mailto:sage [2008/05/18(日) 19:38:01 ]
懐かしの宇宙ヤバイを思い出した。

528 名前:デフォルトの名無しさん [2008/05/29(木) 23:59:57 ]
ちょっと、細かい質問なんだが、
tbbの本38ページに書いてある、粒度ってどういう意味なんでしょうか。
本書曰く「grainsize は、プロセッサーに分配する妥当なサイズのチャンクに割当てる反復回数」とあります。

たとえば、2コアのCPUで1000回のループのを並列処理するときに、grainsizeを500にする、
4コアならgrainsizeを250にすることで、理想的にスケールするということなんでしょうか。

この本肝心なとこの訳が意味不明で困る。
ーーマルチコアで並列処理をスケールさせることをテーマにしたよいほんないでしょうか(TBBのもいい参考書だとおもいますけど。)。



529 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 00:11:11 ]
>>528
その本持ってないから意味不明で困る。

処理を細かい粒に分けて並列処理をする。粒度は粒の大きさだ。粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ。

530 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 00:16:56 ]
>この本肝心なとこの訳が意味不明で困る
文句言ってる暇があるなら原著嫁

531 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 09:09:33 ]
>>529
>粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ
環境に応じて調整している間は現実性はないと思うな、ソフトの開発は時間との戦いだ、それができないと理想論で終わってしまう。
使える並列化にするには、コードがスマートになる粒度にハードウェアを調節しないと駄目だ。
それが不可能なら、VMなりを作ってそこで吸収できるような構造にする事が不可欠。

>>530
ツマンネー事いってないで必要な情報は全部書けよ、この自己完結野郎

532 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 09:31:16 ]
>>531 の文書が変だとおもったのでちょっと修正
>粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ
環境に応じて調整している間は現実性はないと思うな。
使える並列化にするには、コードがスマートになる粒度にハードウェアを調節しないと駄目だ。
ソフトの開発は時間との戦いだ、それができないと理想論で終わってしまう。
それが不可能なら、VMなりを作ってそこで吸収できるような構造にする事が不可欠。


533 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 12:28:09 ]
調整といっても、問い合わせたプロセッサ数で分割とか、100mS分くらいに分割するとか程度だろ。その程度のことで開発は時間との戦いとか理想論とかってw

534 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 13:41:29 ]
>>533
ややこしいデッドロック問題とか、複数のマルチスレッドライブラリが組み合わさった状態とかまったく想定していないショボイ開発だけ見ているだろw
例えば、ライブラリが二つあるだけでも最優先で実行すべきコードが変化するんだぜ、囚人のジレンマって言ってな、個々ライブラリが最優先に実行してほしい物を最優先にすると、最低な結果になる事も結構あるんだぜ。

535 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 14:24:20 ]
>>534
「複数のマルチスレッドライブラリが組み合わさった状態」
になったら「ショボイ開発」って思わなきゃダメだよ

536 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 15:42:06 ]
10000行で完成する程度のコードしか組んだことないんだなw

537 名前:匿名 [2008/05/30(金) 15:45:44 ]
並列・分散処理に関しては以下のホームページが参考になります。
主要な言語に対応したツールなどの紹介もあります。

www.cspjapan.org




538 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 16:46:39 ]
>>537
宣伝でつか?
マルチポストでやるのは、あまりイメージ良くないですよ。



539 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 16:51:46 ]
>>537
ちらっと見ただけだけど、通信部分が浮いている感じがするな、もっと洗練できると思う。

540 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 17:00:24 ]
グリッドコンピューティング?には合ってる部分もあるのかもだけど
昨今のマルチコア活用方向とは全く合わんのじゃ…
大体想定環境・状況が古すぎるような…


541 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 17:06:31 ]
プロセス代数は基本だと思うし、オブジェクト間通信という考えの元でも問題はないと思う。
マルチコア活用を阻害している最大の要因はパフォーマンスではなくて
直感的に記述することや効率よく記述すること、デバッグを容易にすることが重要だという点に気付いているかが気になった。

542 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 17:11:11 ]
もうひとつあるな、現行残っているシングルスレッドモデルで記述された大量のコードを徐々に移行していくための仕組みがいる。

543 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 17:42:51 ]
>>534
想定しなくていいように作るもんだろ
それに囚人のジレンマは場違いもいいとこ

544 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 17:58:10 ]
>>532
> コードがスマートになる粒度にハードウェアを調節しないと駄目だ。

プログラマからするとソフトウェアもコードがスマートになるように作ってほしいですよね。

>>543
俺も思ったけど、Wikiみたら使い方あってるみたい。

> 囚人のジレンマ
> 個々の最適な選択が全体として最適な選択とはならない状況の例としてよく挙げられる問題。

545 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 18:01:14 ]
>>543
すべてのライブラリが自家製とかありえないだろ、ふつう

546 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 18:12:32 ]
>想定しなくていいように作るもんだろ
想定しなくていいように作る=毎回開発でスクラップアンドビルド
だが、良いのか?

547 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 21:10:39 ]
>想定しなくていいように作る=毎回開発でスクラップアンドビルド

うわっバカだ

548 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 21:58:47 ]
マルチスレッド並列化で解決すべき深刻な問題の一つだからな、保守性の無さと再利用性の低さは。



549 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 22:18:08 ]
>>537
今更CSP紹介されてもな…何十年前の話題だよ。
CSPを普通に実装するとプロセス間をデータが流れることになり、
キャッシュを越えるコア間のデータ転送が増えて、途方もなく
効率悪いと思うんだが。
その辺まで言及してくれればこのスレ的な話題になる。

550 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 08:31:32 ]
>>548
> 保守性の無さと再利用性の低さは。

STM はその辺強いのかね

551 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 13:48:09 ]
>>550
変な用語を使うのはヤメレ、シングルスレッドモデルといいたいのだろうが・・・
ちょっとでも触ればマルチスレッドを使った並列化の現状が論外な状態だと判るはず。
可能ならとっくに流行っている。

552 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 13:50:49 ]
>>549
現在のプロセッサの最大の弱点はプロセッサ相対で低速なメモリーであって
キャッシュ間の転送は、小さくはないが致命的でもない。

553 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 14:30:34 ]
>>551
アフォか。Software Transctional Memoryだろが

554 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 14:56:15 ]
>>552
一般論としてはそうだが例えばfork/joinはスティールされない限り
同じスレッドで実行することでデータ転送を減らすよう考慮されてる
スティールされるのが古いタスクからなのも同じ理由
それに比べてCSPはどうだ?

555 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:16:47 ]
>>554
>fork/joinはスティールされない限り同じスレッドで実行することでデータ転送を減らすよう考慮されてる
SMT(ハイパースレッディング)が登場してから、おかしな対処をしないと性能がでなくなって必ずしもそうなっていないよ、今は。

556 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:24:58 ]
>>555
そうか?tbbやjsr166yのfor/joinは>554で書いたようになってると理解してるが。
ソースキボン

557 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:25:21 ]
しかしまぁ、オペレーションズ・リサーチは情報系出身なら常識だろうと思うが、こういった基本すら知らない奴はどうしてくれるかなぁ
ゲーム理論や囚人のジレンマも知らないというのはどうかと思うんだ・・・

558 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:28:29 ]
>>556
Core 2 Quadマシンと、Windows Vista 買ってきて、ひとつアプリを走らせろ
そして、タスクマネージャーなり、ガジェットからCPUメーターをダウンロードして睨めっこをするんだ
そうすれば、ソースも必要ないし説明するまでもない筈。



559 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:36:48 ]
>>558
まさかProcessor affinityの話をしてるのか?

560 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:37:45 ]
>>559
謎用語出す前に、基本を勉強しとけ

561 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:43:23 ]
>>560
謎用語て…単なる煽りか?それなら消えてくれ
煽りじゃないなら>558とjork/joinのタスクスケジューリングの関係を説明してほしい

562 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:44:11 ]
ソースだせと、なぞ用語で捲し立てるのが趣味なら消えてくれ

563 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:46:20 ]
>>557
常識だと思うけど、大学卒業して10年の俺はさっぱり覚えてないw

564 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:46:37 ]
頭の悪いGKがいる、絶対いるw

565 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:56:40 ]
>>562
Processor affinityはWindowsでもLinuxでも商用UNIXでもAPIになってる
特定のプロセス/スレッドを特定のCPUに割り当てられやすくするもの。

fork/joinのスケジュールがスレッドのローカルなキューからタスクを
取ってくるのも新しいタスクをキューの先頭に入れるのも
他のスレッドからキューの後ろからスティールするのも
Processor affinityの元でスレッドが同じコア上で実行される場合に
キャッシュが効率的に使われることを目指していると俺は理解している。

さて、>555や>558について説明してもらえないかな

566 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:58:27 ]
>>565
CPUメーターみてみなよ、OSが勝手にスケジュールを調整してこちらの意向を無視している。


567 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:03:08 ]
>>566
そのアプリがSetThreadAffinityMask読んでないなけだろ

568 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:04:05 ]
>>567
単に、特定アプリに依存すると障害が多いからMSが調整しただけかと



569 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:08:58 ]
>>568
意味が分からない
SetThreadAffinityMaskを呼び出していないスレッドをOSが勝手に
スケジュールするのは当然のことだ
お前さんの言ってるアプリはSetThreadAffinityMaskを呼び出してるのか?
呼び出してないアプリでCPUメーター見ても全く意味がないんだが
Processor affinityを知らなかっただけじゃね?

570 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:10:20 ]
そっちの言っている事こそ意味不明だわw

571 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:12:50 ]
じゃあさ、>558で「ひとつアプリを走らせろ」のアプリが
SetThreadAffinityMaskを呼び出してるアプリのことかどうかだけ答えてくれ
yes/noだけでいいからさ

572 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:14:01 ]
こんなの、つまらないコード書いて、パフォーマンス確認目的でパフォーマンスカウンタ見れば一発なんだが・・・
なんでこんなややこしい話が登場するのかと・・・

573 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:14:46 ]
バカ相手にするのは疲れる

574 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:22:31 ]
>>572
ややこしい話はしていない
そのつまらないコードでSetThreadAffinityMaskを呼んだのかどうか、それだけだ。
これもyes/noだけでいいから答えてくれ

575 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:31:59 ]
SetThreadAffinityMaskじゃなくSetProcessAffinityMaskなら
タスクマネージャーから設定できる。
プロセスタブでプロセスを選んで右クリック、関係の設定でCPUを選ぶだけ

576 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 20:07:00 ]
逃げたようだな。結局Processor affinityすら知らなかっただけだけか
何が「基本を勉強しとけ」だよw
きっとfork/joinも何のことかわかってないんだろうな…

577 名前:デフォルトの名無しさん [2008/05/31(土) 20:31:28 ]
割り込んでごめんなさい。
windows 2k serverってマルチコアに対応してますか?

windows serverは全部対応してるって記事をネットで見たけど、
記事自体、いまいち信用できないんです。

578 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 20:57:52 ]
雑誌記事が信用できずに、誰の発言かもわからない
掲示板の話を信用するんですか?



579 名前:デフォルトの名無しさん [2008/05/31(土) 21:16:49 ]
>>578
どっちもどっちですが、広告だらけのブログで「対応してる。」って言われるのと比べるなら、
まだ、ここのほうが信用できます。

「ここで公式に書いてるよ!」みたいなレスがあればなぁなどと思った次第です。

580 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 21:31:15 ]
それプログラミングと関係ないだろスレ違いだしageんな

581 名前:デフォルトの名無しさん [2008/05/31(土) 22:21:36 ]
>>578
P4-2.4Cで2個見えてるから、2個までは対応してると思うよ
#手元に2コアまでしかないからそれ以上は分からんw


582 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 22:25:52 ]
初心者ですまんが
Pg作るのにマルチコアなんて気にする必要アンの?
いいところスレッド処理とか流せば
しかたねえな ってかってに動いてくれそうだけど

583 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 22:35:21 ]
そのいいところってのが難しいんじゃない?
いままでみたいな粗い粒度のスレッドの使い方じゃなくて、もっと積極的に
例えば単なるクイックソートを2〜4スレッドで並列実行して高速化しようとか、
そういうのを考えるんじゃないかなたぶん

584 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 22:35:59 ]
>>582
ここは君が来るところではないんだよ。
ここはデュアルコアならシングルコアの2倍、クアッドコアなら4倍の
パフォーマンスを目指すスレ。

今のところ有益な議論は一度もないけどな。

585 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 22:54:45 ]
Processor affinityも知らないSoftware Transactional Memoryも知らない
wait freeやlock freeの話も出ない
有益な議論のしようがないなw

586 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 22:56:05 ]
>>584
キャッシュに入るような小さな処理から頻繁にメモリアクセスが必要な処理をした際
実際のパフォーマンスを比較したものってどっかにないの?


587 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 23:03:12 ]
マルチスレッドスレと話題かぶるからなぁ

588 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 23:17:48 ]
>>582
俺も気になった。
winのapiには無いと思う。

2つのスレッドを2つのコアにわけるなら話も早いけど、
1つのスレッドを2つのコアにわけると、なんか、戻りとか処理のオーバーヘッドがでかそう。
win上で動くプログラムからそこを制御できるかも、よくわかんないし。

と、初心者は思うのでした。



589 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 23:52:50 ]
初心者だと思うなら、「winのapiには無いと思う。」なんてろくろく調べもしないで
レスするなよ。

590 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 00:07:59 ]
マルチコア対応apiはwinにはないね。未熟なOSなのかも。

591 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 00:18:47 ]
同一ソケット上のマルチコアに特化したAPIはないわな。未熟だわなwww

592 名前:デフォルトの名無しさん [2008/06/01(日) 00:19:17 ]
windows上なら、SetXXXAffinityMaskってのを使うみたいだけど、
OSに任せたほうが無難だろうな。
ビットマスクに何指定するのか、俺の古いMSDNだとわかんないし。

あとNT3.5から対応してるんだな。
これ使ってプログラム組んでれば、
別にwin 2kでもwin 2k severでもマルチコアに対応できる気がする。
(OSが認識さえできれば、で、マルチコアは2kで認識できるはず。非公式だけど。)

>>577への回答ね。マルチコア対応プログラムなら、おそらくwin2kでもおっけ。
むしろ余分な他プロセスのバックグラウンド処理が少ない分、win 2kがxpやvistaより早いと思う。

それ以外は、OSの判断だけど、多分2つCPUあるときと同じだから、win2kでも大丈夫な気がする。
こっちはあんま自信ない。

以上、>>577の自己回答でした。

593 名前:デフォルトの名無しさん [2008/06/01(日) 00:22:55 ]
>>589
嫌味な上級者は、絶対何も言わないんだよな。

さっきからずっと、むかつくレスしてんのこいつだろ?
上司でたまにいるんだよ。
知ったかして、具体的に何も言わないで、誰かが言ったら便乗するやつ。

594 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 00:27:06 ]
そりゃ、言うべきじゃない時を心得てるのが上級者というものだからなあ

595 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 00:31:12 ]
>>592
MSDN見たなら「参照」も見るといいよ

596 名前:デフォルトの名無しさん [2008/06/01(日) 00:43:55 ]
>>592
あんまり調べる気無い。
何か映像関係の高速処理組むなら別だけど予定もないし。
スレッド、プロセス関連は完全に2、3継承のクラス化しちゃってるし、
いまさらOSの判断以上の速度が出るように直す気はない。

597 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 00:44:33 ]
時代がマルチコアなのになぜ対応apiがないのか?
これはMSの怠慢ではないだろうか
高いOSライセンス代(1台につき1万〜3万)を定期的(5年程度)に払っているというのに
ひどい話だ

598 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 00:51:54 ]
>>597
マルチコア対応APIって具体的にどういうものよ?




599 名前:デフォルトの名無しさん [2008/06/01(日) 01:06:17 ]
>>597
だからwindowsにもあるって。
プロセッサを直接指定できるapiが。
やっぱNT系のカーネル作った連中は偉いわ。
おれもまだまだ2kで行く。

600 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 01:10:52 ]
マルチコアねぇ…
TPC風にProcessor/Core/Threadで表すと、Core2Quadの1/4/4はマルチコアだよな。
じゃあシングルコアXeonを4個使った4/4/8とかItaniumを64個使った64/128/256は?
後者もマルチコアならマルチコア対応APIは既にある。

601 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 01:12:08 ]
マルチダイもマルチコアに含めてるしな、、、思想的には
ていうか、やっぱまだ2kって需要あるかなー?
今新規にフリーソフト作ってるが、どこまでサポートするか悩む

602 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 01:15:22 ]
>>599
Processor affinityはDECのVMSの時代からある。
WindowsNTと作った連中は同じだけどなw

603 名前:デフォルトの名無しさん [2008/06/01(日) 01:19:14 ]
>>601
俺、フリーソフトは、2kで作って、xpで軽く動かしてテスト終わり。
2kで動いて、xpで動かなくなったことはない。
基本、Direct X関係に気をつけるだけ。


604 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 01:22:24 ]
CPUが別パッケージかオンダイかを気にするような場面には出くわしたことないなあ
キャッシュの奪い合いとか同期の頻度とかが問題になるのかな?

むしろhyper threadingが特別だったんじゃないかと思う

605 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 01:24:49 ]
Win32のSetThreadAffinityMaskはaffinity maskがDWORDで32bitしかない
64/128/256のSuperdomeはOSからは256プロセッサに見えるんだがどうするんだ?w

606 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 01:27:16 ]
hyper threadingは鬼門


607 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 01:29:44 ]
>>606
Pen4のHyper Threadingだけが鬼門? SMT全般が鬼門?
ちょっとだけPower使ったときは何もなかったけどな

608 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 02:01:39 ]
>>605
いずれSEtThreadAffinityMaskExが出来るだけよ



609 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 02:05:55 ]
>>608
いずれってかSuperdomeにWindowsが乗ってから5年以上経ってないか?
Windows乗ったSuperdome俺は見たことないけどw

610 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 02:08:16 ]
テキトウに仮想化でもしたほうが効率よさそうな気が

611 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 02:14:38 ]
>>610
それは現実的すぐるw
とりあえずタスクマネージャーはこうなる
ttp://www.microsoft.com/japan/sql/images/ssj/ki03_02_l.jpg
これで「関連の設定」は64CPU設定できるのか?
つかItaniumだから64bit Windowsか…

612 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 02:54:12 ]
Win64ではモーマンタイだた

BOOL WINAPI GetProcessAffinityMask(
__in HANDLE hProcess,
__out PDWORD_PTR lpProcessAffinityMask,
__out PDWORD_PTR lpSystemAffinityMask
);

DWORD_PTR WINAPI SetThreadAffinityMask(
__in HANDLE hThread,
__in DWORD_PTR dwThreadAffinityMask
);

613 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 03:25:02 ]
>>607
606じゃないけど、HTは面倒な存在じゃない?
普通のマルチプロセッサなら異なるプロセッサ間で同じキャッシュラインに
アクセスしない方が良いが、HTの場合は逆でしょ?
ベンチ取ってないんで、どのくらい影響があるのかは具体的には分からんが。

614 名前:デフォルトの名無しさん [2008/06/01(日) 03:36:55 ]
menndouda


615 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 03:41:14 ]
>>613
それはPower含めてSMT全般にいえるし、少しレイヤをずらすと
2(3)次キャッシュ共有のマルチコアやNUMAにもいえるんで、
そんなに特殊なことではない。

さっきWin64調べてたらこんなAPIがあった
BOOL WINAPI GetNumaNodeProcessorMask(
__in UCHAR Node,
__out PULONGLONG ProcessorMask
);

これで距離の近いノード内のプロセッサマスクを取得できる。
NUMAアーキテクチャに限定せず、SMTやキャッシュ共有のコアを
ノードと見なすことができると、細粒度並列実行で効果的なヒントを
与えられるかもしれない。

616 名前:デフォルトの名無しさん [2008/06/03(火) 13:35:38 ]
マルチコア対策としてこんなのがあります。

www.axon7.com/

また、これも参考になります。

www.cspjapan.org/









617 名前:デフォルトの名無しさん mailto:sage [2008/06/03(火) 13:45:14 ]
>>616
>537

618 名前:デフォルトの名無しさん mailto:sage [2008/06/03(火) 13:58:55 ]
マルチプロセス、マルチスレッド、マルチコア、マルチプロセッサ、SMT、メモコン共有、キャッシュ共有、演算器共有。
これが複合的に絡んだときの最適化は複雑すぎる。



619 名前:デフォルトの名無しさん mailto:sage [2008/06/03(火) 14:44:35 ]
>>617
>549

620 名前:デフォルトの名無しさん mailto:sage [2008/06/03(火) 14:47:41 ]
間違えた、>619は>616へ。

>>618
それをコンパイラで成し遂げることが前提のItaniumは不可能に挑んだようなものだな

621 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 13:51:00 ]
マルチコアは、今までのソフトウェア技術を台無しにしてくれる素晴らしい技術だよね。
これからはソフトウェアとハードウェアの境界が無くなって、
プログラムを作るのは、より一層大変になる。

622 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 14:08:33 ]
ハードとソフトが緊密に絡む領域はこれまでもあったんだけどな
無停止システムとか

623 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 14:08:49 ]
今までのマルチプロセッサ向けのソフトウェア技術の延長にあるから
台無しという事は無いよ。もう何十年も研究が続けられている分野だ。

624 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 15:54:23 ]
何十年も研究とか、無駄の極地だねwww

625 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 16:04:53 ]
ロックフリーのアルゴリズムやトランザクショナルな変数アクセスが
もっと一般化してくれば、そんなに恐れる物でもない気がするけどね

626 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 17:43:57 ]
>>621
いったい何に怯えているんだろうか

627 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 18:51:05 ]
まあそりゃ単一スレッドで速くなるほうがありがたいけどな

628 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 19:06:01 ]
荒い粒度の並列化や、ベクトルの並列処理はとっくに研究され尽くされてるけど、
その中間が非常に厄介。
しかし、これからは単一スレッドでは速くならないわけだから、それをやらないといけない。



629 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 19:53:53 ]
ループを展開する自動並列化くらいはインフラとして整備して欲しいね

630 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 23:02:40 ]
>>629
自動じゃなくてもparallel array使えばおk

631 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 23:56:43 ]
>>628
divide and conquer
work stealing
fork/join
parallel array

632 名前:デフォルトの名無しさん mailto:sage [2008/06/07(土) 23:32:29 ]
遅レスだが
ハードウェア・ソフトウェア協調設計等は組み込みでは昔からよく見られるんじゃないか?
まあ、シミュレーター等の開発統合環境が整えられているなら最適化はむずかしくないよ。
ただ工数と時間と労力が膨大に費やされていくだけで

633 名前:デフォルトの名無しさん mailto:sage [2008/06/13(金) 19:49:18 ]
組み込みの場合は、環境のプロセッサ数やプロセス数は固定されてるから、難易度は低いんじゃないかな。
PCの場合は、対象のプロセッサ数は予想できないし、同時にどんなプロセスが動くかも分からないから、難易度が高い。
というか、PCの場合は、何らかの動的最適化メカニズムが必要になるんだよね。

pc.watch.impress.co.jp/docs/2008/0613/hot554.htm
インテルはCを拡張してJITコンパイラで最適化する研究をしてるようだけど、
実用化はまだまだ先だよな。

634 名前:デフォルトの名無しさん mailto:sage [2008/07/06(日) 06:28:11 ]
1.マルチなんたらとか並列化とか、なにも考えずに作る。
2.あとは開発環境とOSがなんとかしてくれる。
3.下手なこと考えるより、そのほうが最終的に効率が良い。

こういうのが理想なんだけどなぁ…。

635 名前:デフォルトの名無しさん mailto:sage [2008/07/06(日) 09:34:03 ]
スレ民じゃないけどマルチコアネタがあったのでぺたぺたしていきます。

「Ruby 1.9は1.8より平均5倍速い」、YARV笹田氏 − @IT
ttp://www.atmarkit.co.jp/news/200709/07/yarv.html
今後のテーマは並列処理によるスケーラビリティ向上

 今後の研究テーマとして笹田氏は、並列処理への対応など
スケーラビリティに取り組みたいと話す。ただ、「Rybyの言語仕様の
枠組みでスケーラビリティを上げるのは難しい」ため、マルチコア、
マルチプロセッサといった密度の高い並列化よりも、クラスターや
グリッドのようにネットワークで接続された複数ホストによる並列化を
実現していくのがいいのではないかという。

636 名前:デフォルトの名無しさん mailto:sage [2008/07/06(日) 10:51:06 ]
>>634
それ何て第五世代

>>635
むしろマルチコア関係なくね?

637 名前:デフォルトの名無しさん mailto:sage [2008/07/06(日) 10:59:42 ]
マルチコア向けの最適化はしない方向だ、という内容だな。

638 名前:デフォルトの名無しさん mailto:sage [2008/07/06(日) 16:27:58 ]
今後もRubyのスレッドはマルチコアを使いこなすようにはしない方針ということだな



639 名前:デフォルトの名無しさん mailto:sage [2008/07/06(日) 16:42:50 ]
Rubyなんて並列化のこと何も考えてないじゃん。
書いててわくわくするとか日和ったこと言ってる言語では到底無理。

640 名前:デフォルトの名無しさん mailto:sage [2008/07/06(日) 20:49:23 ]
並列化に興味をもったRuby使いはErlangあたりに移行するのだろうか

641 名前:デフォルトの名無しさん mailto:sage [2008/07/06(日) 23:42:11 ]
アルファブロガー(笑)あたりに煽ってもらえばイッパツよ

642 名前:デフォルトの名無しさん mailto:sage [2008/07/07(月) 14:51:27 ]
jruby

643 名前:デフォルトの名無しさん mailto:sage [2008/07/12(土) 12:34:27 ]
Erlangが騒がれてるのは副作用がないのとメッセージングがあるからなの?
ほかの言語でも多少見苦しくなっても同じことはできんの?教えてエロイ人。


644 名前:デフォルトの名無しさん mailto:sage [2008/09/06(土) 10:33:33 ]
>クラスターや
>グリッドのようにネットワークで接続された複数ホストによる並列化を
>実現していくのがいいのではないかという。

ハードは明らかにマルチコアに進んでいて、
サーバも集約統合が進んでいるというのに。

Rubyみたいなソフト側が手前の都合だけで
「いいのではないか」とかいって方針だしても何の意味もないわけだが。

誰もそんなハード持ってません。
今のハードにあってません。

ってなるだけ。

645 名前:デフォルトの名無しさん mailto:sage [2008/09/06(土) 17:36:31 ]
なに、寝ぼけたレスしてるんだ?
>>644 は、Ryby という新言語について語っているんだぞ。

646 名前:デフォルトの名無しさん mailto:sage [2008/09/06(土) 19:45:47 ]
>>645
誰に言ってるの?

647 名前:デフォルトの名無しさん mailto:sage [2008/09/06(土) 20:28:00 ]
なに、寝ぼけたレスしてるんだ?
>>644 は、Ruby という言語について語っているんだぞ。


648 名前:デフォルトの名無しさん mailto:sage [2008/09/06(土) 20:50:57 ]
なんだ、キ印か。



649 名前:デフォルトの名無しさん mailto:sage [2008/09/27(土) 22:48:29 ]
>>644 って、Googleのサーバーとか、AmazonのEC2とか、分散環境が流行ってるのを知らないのか。
サーバーの集約統合が進んでるのは、既存のサーバーや負荷の低いサーバーでしょ。

650 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 17:23:48 ]
分散環境が流行ってるって…
すごい規模なんだからどっちにしても分散が必要なのは当たり前。
googleなんかは2003年の時点でこれからはマルチコアみたいなこと言ってるぞ。


651 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 17:40:39 ]
実際流行ってるんだけどなぁ。
クラウドとかいうキーワードでぐぐってみりゃわかると思うよ。
実効性はともかくね。

652 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 17:44:47 ]
クラウドが流行ってるってのはSOAが流行ってるってのと
どっこいどっこいだな。
ごく一部で当たり前になってるのと広く使われてるのとは
全然違ってて、どっちの話をしてるかがズレてるんだな。

653 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 17:49:52 ]
P2P→グリッド(言い換え)→クラウド(言い換え2)

654 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 17:50:04 ]
オフコン時代の鯖だと鯖っていえば特定の対応関係になってたのが
OOのポリモフィズムみたいな多態になっただけだ

C<->Sの関係が1:1だったのが
C<->Sの関係がN:Mになっただけだ
SOAはC<->Sの関係がN:1だったがな

たしたことない。言葉変えて変化を促そうとしている単なる言い換えだ
詐欺の一種だ

655 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 17:56:49 ]
クラウドとマルチコアって関係ないじゃん

656 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 18:12:59 ]
まあ関係はないね
ハードの保守性とソフトのスケーラビリティを考えて、
マルチコアのマシンを仮想化してクラウドにするみたいな
話は聴いた事あるけど

>>654
ハイプで成り立ってる所も大きいから、そんなもんかと

www.atmarkit.co.jp/aig/04biz/hypecycle.html

657 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 18:41:15 ]
とりあえずクラウドはスレ違いだろ
並列化の粒度が違う。クラウドは祖粒度、こっちは細粒度
ネタがないから構わんけど

658 名前:651 mailto:sage [2008/09/28(日) 18:45:37 ]
>>652
どっこいどっこいというか、いままでSOAをかついでたところが、クラウドを担ぐようになってる。
SOAのように、クラウドは流行っている。まあそういう意味だ。
この件は、これで。



659 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 18:52:32 ]
すかしっ屁こいてクライアント騙すのがクラウドなのか?

660 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 18:59:16 ]
そう思う奴はいつまでも足踏みしてればいいのさ

661 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 19:07:46 ]
>>657
×祖粒度
○粗粒度

662 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 21:04:14 ]
クラウドもSOAもわかってないやつ多すぎ。
そんなやつらがマルチコア云々なんてしょーもねー。
せいぜい単純労働者としてコキ使われてなw

663 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 21:08:22 ]
どっちもバズワードなんだから分かっているという方がおかしい

664 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 21:36:35 ]
バズワード自体がバズワードというパラノイア

665 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 21:46:40 ]
バズワードを使ってる人間はバズワードかどうかなんて気にしていないから、
一回りして結局おk

666 名前:デフォルトの名無しさん mailto:sage [2008/09/29(月) 17:24:22 ]
>>658
SOAと普及でぐぐると
・普及が進まない
・普及促進
・普及狙う
・普及を目指す
・普及を後押しする
こんなんばっかですけど?
流行ってるけど普及しない。笛吹けど踊らずw

667 名前:デフォルトの名無しさん mailto:sage [2008/09/30(火) 01:37:12 ]
クラウドはどうかと思うが、分散は物理的な話でもあるし必要なところには普及するんじゃないかな。
CPUでの並列だと限界が低いし拡張も難しいから、>>656の言うようなマルチコアマシンの仮想化で分散ってのが現実的ではないだろうか

668 名前:デフォルトの名無しさん mailto:sage [2008/09/30(火) 07:01:26 ]
つまり金融工学みたいな
もんですね



669 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:54:26 ]
「クラウド・コンピューティング」は「仮想化」以来の“乱用語大賞”
www.computerworld.jp/topics/cloud/123069.html

670 名前:644 mailto:sage [2008/10/01(水) 20:30:34 ]
644ですが普段アーキスレとかに書いている身からすると、
このスレの住人はレベルが低すぎます。
キミらが並列化について語るのはまず無理。
チップあたりの性能をあげられなくなったら、
分散処理でも同一コストで性能あげられないの。
Rubyの件はいかにもソフトしかしらない人向けの
苦しいいいわけだなあと。

671 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 20:51:50 ]
自分以外みんなバカ症候群

672 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 23:06:07 ]
ひんと: 賢い奴はこんなスレの住人なんて相手にしない

673 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 00:04:30 ]
レベルが低過ぎてどこを縦読みすれば良いのか分からないや

674 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 00:21:48 ]
アーキスレってどこ?
殴りこみかけてくる

675 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 00:59:37 ]
残念だけど、現状ではマルチコアってサーバサイドや一部の
embarrassingly parallel な処理以外では絵に描いた餅だよね。
デスクトップ機でクアッドコア以上のプロセッサが必要な
場面は思い付かない。それこそハード寄りの知識を持っていない、
スレッド周りの実装の知識も無い様なプログラマが、難しい事を
考えずに処理性能を出せる仕組みが欲しい物だね。fork/join でも
ヘテロなマルチコアでも何でも良いけど。

676 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 01:16:48 ]
後はトランザクショナルメモリと投機的実行も期待してるけど
なかなかこういうのは普及しないねえ…

677 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 01:20:49 ]
ゲーム機でやってるじゃん

678 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 02:33:49 ]
>>676
投機的実行ってRockのスカウトスレッド?
命令レベルの投機的実行と紛らわしいから用語は分けたいな
同時投機スレッド(Simultaneous Speculative Threading)とかな

トランザクショナルメモリはどうかねー
RockのHTMじゃアプリケーションレベルのトランザクション
扱うのは無理だしSTM組み合わせるとオーバーヘッドが大きすぎて
性能出ないと予想してる
つRockの出荷来年の後半とか遅れすぎだろjk



679 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 20:15:08 ]
今普及しているデュアルコアマシンみたいな感じで
6 core のマシンが一番売れ筋のマシンになったら
プログラマはどうすればいい?

680 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 21:08:30 ]
Vistaをお勧めする
あとセキュリティソフトを3つぐらい重ねがけ
これで万全

681 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 21:30:33 ]
>>674
CPUアーキテクチャについて語れ Part.12
pc11.2ch.net/test/read.cgi/jisaku/1219884494/

最近は常駐コテの意地の張り合いばかりでつまらないくなってきてるけど
アーキテクチャスレは↑
普段は名無しだが、MACオタ(翻訳)などは漏れ。
がんばって殴り込みに言ってくれや。

682 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 21:43:42 ]
>>681
なんでこのスレ来てるの?

683 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 22:18:05 ]
>>681
2chらしいスレだなw

40 名前:Socket774[sage] 投稿日:2008/08/29(金) 02:47:03 ID:Yk6PbdtE
ま、MACオタよりよっぽどマシな態度なんで、いじめるのはここまでにします

とか書かれててワロタ
お前そんなに態度悪いのかよw

684 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 22:36:01 ]
ダンゴさんそこでがんばってたのか

お似合いだなw

685 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 22:43:59 ]
せっかく収まるところに収まってるのに煽らないでくれ。頼むから。

686 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 00:45:17 ]
644みたいな状態って、自分の専門は知ってるんだけど他のことは知らなくて、自分の知らないことはたいしたことないって思ってるだけなんだよね。
というか、自分が他のことを知らないことを知らない。
だから、「このスレの住人はレベルが低すぎ」とか言っちゃう。

687 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 00:48:56 ]
でもまぁ、このスレのレベルが低いのは事実だろう。
レベル高い議論って一つでもあったか?ないよな。そういうことだ

688 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 00:53:53 ]
マルチコア用のテンプレートライブラリを活用しているという話を聞かないね
良さげなのにググっても実際に使っている例が殆ど出て来ない
C++ の人気が無いのかテンプレートが嫌われてるのか…

www.threadingbuildingblocks.org/
spc.unige.ch/mptl
sourceforge.net/projects/rpa
www.extreme.indiana.edu/hpc++/docs/overview/class-lib/PSTL/



689 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 01:26:23 ]
ライブラリの話はマルチスレッドスレがあるからなあ
このスレいらない子なんじゃ…

690 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 01:39:29 ]
>>687
「住人はレベルが低すぎ」などと書いて無用に荒らすのが一番レベル低いがな。

691 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 02:36:30 ]
>>689
要らなかったらスレが亡くなるだけだから気にしなくておk

692 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 03:39:27 ]
>>689
マルチスレッドとマルチコアでの並列化は違う。

693 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 04:03:36 ]
>>692
どう違うか語ってもらおうか

694 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 04:06:23 ]
マルチスレッドは、タイムスライスで同時に動かなくてもおけ

695 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 04:31:02 ]
マルチスレッドが並列に動かなくていいわけないだろ
マルチコア以前からマルチプロセッサは当たり前にあるんだしよぉ
本気でレベル低いなここ…

696 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 05:34:37 ]
・・・この人、シングルコアのシングルプロセッサで、CPUが同時にひとつの仕事しかできなくてもマルチスレッドは可能ってことわかってるのかな?
しかし、ほんと、自分の無知をしらずに、他人のレベル低いって言うのは恥ずかしいな。

697 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 07:28:21 ]
windowsもクラウドが標準になるんだな
japanese.engadget.com/2008/10/01/os-windows-cloud/

698 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 10:41:52 ]
>>696
・・・この人、シングルコアのシングルプロセッサで、CPUが同時にひとつの仕事しかできない時のマルチスレッドとマルチコア/マルチプロセサでのマルチスレッドじゃ状況が違うってことわかってるのかな?
しかし、ほんと、自分の無知をしらずに、他人のレベル低いって言うのは恥ずかしいな。

>>692
そもそも、マルチコアとマルチスレッドを比較するなよ。



699 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 10:53:10 ]
>>698
おいおい、状況は違うのは分かるが、プログラムは同じにしとかないと
まずいだろ。

どこかのエンコソフトみたいにCPUのコア数によって使うルーチンを切り替える
ようにするなら話は別だが。

700 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 11:50:27 ]
誰もプログラムを別にするとかなんて言ってないけど?

状況が違うと言うのはシングルコア and シングルプロセサで問題ないプログラムでも
マルチコア or マルチプロセサで問題が発生するケースがあるってだけ。

種々の要件によって、その状況によってプログラムを切り替える実装はあると思うが、
それはもっと条件を限定しないと議論できない。

701 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 12:03:57 ]
デッドロックとかレース状態とかそういう次元の事かな。
確かにシングルコアでは問題ありとしながら問題が潜在化してたものが
マルチコアにした途端に顕在化する場合はあるね。

702 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 12:37:48 ]
>>701
マルチスレッドプログラミングとしては単なるバグじゃん

703 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 12:38:00 ]
> 確かにシングルコアでは問題ありとしながら問題が潜在化してたものが
> マルチコアにした途端に顕在化する場合はあるね。

そうじゃなくて、例えばメモリに対する inc 命令の実行中に他のコア/プ
ロセサのアクセスが割り込んじゃうとかの「シングルコア and シングル
プロセサではあり得ない問題」のことだよ。

704 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 12:39:40 ]
>>703
それはクリティカルセクションを入れるのが当たり前だろ

705 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 12:40:56 ]
>そうじゃなくて、例えばメモリに対する inc 命令の実行中に他のコア/プ
>ロセサのアクセスが割り込んじゃうとかの「シングルコア and シングル
>プロセサではあり得ない問題」のことだよ。
アトミック操作でないのにロックせずに破壊した場合プログラマの責任だと思うが。



706 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 12:42:23 ]
>>703
そんなバグ埋め込んでマルチスレッドとか恥ずかしいぞ

707 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 12:43:53 ]
>>703
もうちょっとOS関連の本を読んでマルチプロセス/マルチスレッドに
ついて勉強してから書いた方がいいよ。恥かくだけだぞ今のままじゃ。

708 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 13:08:13 ]
>>698
そもそもというなら、マルチスレッドとマルチコアの話は、 >>689に言ってくださいな

「マルチスレッドが並列に動かなくていいわけないだろ」とか言っておいて逆切れせずに。



709 名前:689 mailto:sage [2008/10/03(金) 13:38:17 ]
>>708
比較なんかしてないぞ
マルチスレッドがマルチコア環境で正しく並行動作するのは当然
だからライブラリの話はマルチスレッドスレの方がそれなりに議論してて
適切だろうってことだ
マルチスレッドスレを並行動作しなくていい話題に限定したら
糞スレ確定で速攻落ちるぞw

710 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 13:44:20 ]
同じ変数を複数スレッドで更新する可能性があるなら、UP/MPに限らずバリア入れる。
更新するのが一人だけだったら、ちょっと考えてから決める。

711 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 13:44:22 ]
そういう話は、その時点でやってくださいな。
あと出しで切れるのカコワルイ

712 名前:711 mailto:sage [2008/10/03(金) 13:44:54 ]
>> 709 ね。

713 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 13:49:36 ]
>>711
どこが後出し?w

714 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 17:59:44 ]
>>704
そもそもクリティカルセクションをどう構成するかと言うレベルの話だから、
君には用はないので当分 ROM っててくれ。

>>705-706
シングルプロセサ/シングルコアならアトミック操作だから、バグじゃないよ。

マルチコア/マルチプロセサではちゃんと動かないから良くないコーディングと
言うならまだわかるが。

>>707
どこがどうおかしいかちゃんと指摘してくれ。
まさか、>>705-706 の的外れの指摘のこと言ってるのか? (w

715 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 20:19:54 ]
>>714
アホですか
RISCはロード/ストア命令とモディファイ命令を1命令で実行できない
物があるのでアトミックではない場合がある

716 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 20:20:58 ]
つーか明らかな自分のミスを認められないグラマって
必要ないな。

こういう奴がいると絶対にプログラムにバグを入れてくれる。

717 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 20:28:36 ]
そろそろダンゴさんがピシっと〆めてくれそうだ

718 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 20:32:18 ]
つかシングルコアでも他デバイスがDMAしてきたらアトミックにならんやろ

メモリにアクセスするプロセッサがひとつだけっていつの話?



719 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 20:33:29 ]
Java のでも GCC 組み込みのでも、OS ネイティブのでも良いけど、
アトミック命令ってみんな使ってるの?

720 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 20:53:25 ]
排他やると暗黙的に使われるんじゃね

721 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 20:56:23 ]
無意味な連番つけるときに AtomicInteger を使ったことはある

722 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 21:03:47 ]
AtomicReferenceFieldUpdaterは友達

723 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 21:41:05 ]
レベルの低いスレ/話題は伸びるのが速い。

724 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 21:49:12 ]
レベルの低い話題に詳しそうだな

725 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 22:04:26 ]
>>715
> RISCはロード/ストア命令とモディファイ命令を1命令で実行できない
> 物があるのでアトミックではない場合がある

そんなプロセサにメモリに対する inc 命令なんかあるのか?
あるんならそのプロセサの型名書いてくれ。

>>716
「明らかな自分のミス」ってどれのこと?
ちゃんと指摘してくれって書いてあるのに指摘できないの?

>>718
ああ、DMA はあるな。
ただ、通常の DMAC はレジスタで制御するから、メモリ上で排他なんかしないでしょ?

> メモリにアクセスするプロセッサがひとつだけっていつの話?

今でも普通にあるよ。PC しか眼中にないの?

726 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 22:07:57 ]
また前提が増えたな。

DMA無しだとさ。

727 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 22:19:48 ]
>>718見て、Windows 98で386のときのInterlockedIncrementは、
デバイスドライバ内で割り込み禁止してincを実行するって話を思い出した。
blogs.msdn.com/oldnewthing/archive/2004/05/06/127141.aspx

728 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 22:22:31 ]
>>726
また?
DMA 以外で増えた前提って何のことだ、ちゃんと書いてくれよ。



729 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 22:37:24 ]
>>725
> そんなプロセサにメモリに対する inc 命令なんかあるのか?
> あるんならそのプロセサの型名書いてくれ。
無いからバグなんだろ。

>714 の
> シングルプロセサ/シングルコアならアトミック操作だから、バグじゃないよ。
に対する返信だろう。


730 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:00:16 ]
>>728
きっと>714の「シングルプロセサ/シングルコアなら」のことだろうね

731 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:01:26 ]
>>725
> 今でも普通にあるよ。PC しか眼中にないの?

SPARC/Power/Itaniumサーバも眼中に入ってるよ

732 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:05:07 ]
>>725
> 「明らかな自分のミス」ってどれのこと?
> ちゃんと指摘してくれって書いてあるのに指摘できないの?

>714の
> シングルプロセサ/シングルコアならアトミック操作だから、バグじゃないよ。
のことだろうね

733 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:23:14 ]
Itaniumなんてもうフェードアウトだろw

734 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:27:20 ]
>>733
FNHではバリバリですよ
FはSPARCに注力した方がいいと思うけど東証決まってるからなあ

735 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:31:27 ]
なんか、自分のミスはスルー、この反応みると本当に気づいてないようだ。だから自分はノーミスだと思っている。
前提をあとからつけて、人の意見を間違っているという。
まわりが全員レベル低いんじゃなくて、君ひとりがまわりの会話についていけてないんだってば。

736 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:42:48 ]
>>729, >>732
> 無いからバグなんだろ。

「メモリに対する inc 命令持たないプロセサだとメモリのインクリメントは必然的に
複数命令になるからアトミックじゃないだろ?」って言ってるの?

ならすまん、inc 命令の話してる時にその命令持たないプロセサまで考慮して話せと
言う奴がいることまでは想定できなかったよ。

世の中には自力ではメモリのインクリメント自体ができないプロセサもあったりする
からそこから前提におけということかな? (w

>>730
>>703 にわざわざ「シングルコア and シングルプロセサでは」って書いてますが。

>>731
> SPARC/Power/Itaniumサーバも眼中に入ってるよ

で、それしか知らないと思ってていいのか?
なら、もう少し見聞広めた方がいいんじゃね? としか言えないけど。

>>735
「ミス」とか「間違っている」とか威勢のいいこと書きながら具体的な内容が全く
ないのが、ちょっと笑える。


737 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:43:57 ]
指摘されてもスルーなのが笑える

738 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:44:39 ]
これはひどい。
いくらなんでも釣りだろ?



739 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:52:04 ]
itaniumはもう終わりだろwww




と5年間言われ続けて、無事生存中

740 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:58:00 ]
>>725
incはアトミックじゃない。
でもそのためにバスアービトレーションを考慮したtest and set系が別にちゃんとあるんだよ。
おまえさんはコンパイラがincに落とすのを当然と考えた上でincがバス制御しない事を忘れてる。


741 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:03:13 ]
>>736
> >>703 にわざわざ「シングルコア and シングルプロセサでは」って書いてますが。

その前提を持ち出してるのが大間違いの元なんだよ。
マルチスレッドプログラミング全般としてはそんな前提はないわけ。
君にとってはシングルプロセッサかつシングルコアがデフォで
マルチプロセッサ/マルチコアが特殊なのかもしれないが、
マルチスレッドプログラミング全般としてはシングルプロセッサかつ
シングルコアはマルチプロセッサ/マルチコアの特殊ケースでしかない。
マルチプロセッサ/マルチコアでちゃんと動かないようなのはただのバグ。

742 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:07:03 ]
というか、このスレ全体がひどい。
まず、議論になってない。
そして、議論以前に半分以上の書き込みが用語を並べてみているだけで技術的に意味の通る文章になっていない。
コンピュータ用語に語彙の偏った人口無脳がはき出したような文面の書き込みばかりで流れがない。
今時マルチスレッド、マルチコア、分散処理の区別もつけられない人がこんなにいるなんて信じられない。
日本のプログラマってこんなレベル低いんだ…こりゃ将来が危ぶまれるわ。

743 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:10:15 ]
>>742
だってここ2chだし

744 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:14:50 ]
>>742
たしかに、この発言とかひどいよね
「マルチスレッドが並列に動かなくていいわけないだろ」

745 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:18:26 ]
>>744
どうひどいか語ってもらおうか

746 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:20:49 ]
>>742
「このスレ全体がひどい。」とか「議論になってない。」とか威勢のいいこと書きながら具体的な内容が全く
ないのが、ちょっと笑える。

747 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:21:03 ]
今このPC、 AthlonXP 1500+ で 53プロセス 562スレッド 動いてるぜー

748 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:21:33 ]
>>745
マルチスレッドは並列に動かなくてもいい。



749 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:23:52 ]
マルチスレットは、タイムスライスでもいいから、並列に同時に動く必要はない。

750 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:30:07 ]
GreenThread

751 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:38:13 ]
>>748-749
並列に「動かさなくてもいい」ならそうだが
「動かない」ってのはダメだろ
つか確かに議論になってないな
コンテキスト整理するからちょっと待ってろ



752 名前:742 mailto:sage [2008/10/04(土) 00:38:53 ]
そもそも「同時に動く」ってのはどういう意味でいってるつもりなんだ?
意味わからん。
たとえば
・レジスタやメモリに結果を書くのを同時といってる?
・実行ユニットで演算されるのを同時といってる?
・前後を入れ替えても意味が変わらない処理を同時だといってる?
もう少し頭の中で整理してかいてよ。
タイムスライスってどういう意味でいってるの?
コンテキスト情報をスワップすることがよくいわれる時分割の本質的な意味でしょ?
コンテキスト情報が複数ハード上にあるのがマルチプロセッサだったりマルチコアだったり
ハードウエアマルチスレッディングがスレッドレベルで並列であることの本質なわけだけど。
CPUが実行ユニットで同時に計算しているとか同時にメモリに結果を書くとか関係ないよね?
このスレで議論している連中は用語をならべているだけで、その中身についてはよくわかってない気がする。
回路設計が本業の漏れからみてもまず基礎がひどいと思いました。

753 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:39:04 ]
>>737
どこがスルー?
具体的に指摘しなよ。

>>740
> incはアトミックじゃない。

DMA の話? それ以外にシングルコア/シングルプロセサを前提としてあるなら、具体的に
書いてくれ。

> でもそのためにバスアービトレーションを考慮したtest and set系が別にちゃんとあるんだよ。

そう言う命令がないプロセサもあるから、ちゃんと前提つけないとクレームつけられるよ。(w

> おまえさんはコンパイラがincに落とすのを当然と考えた

人の心まで読めるの? 上級エスパーさんにはかなわないな。

>>741
前提つけたら、そんな前提が間違ってると来たか...。
そこまでしてレスしたいの?
まあ、どっちにしろそう言う文句は >>696 辺りにつけてくれ。

754 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:41:31 ]
>>752
> このスレで議論している連中は用語をならべているだけで、その中身については
> よくわかってない気がする。

自己紹介乙。

755 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:42:44 ]
結局、そこで議論にならなくなってるわけでね。

756 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:47:57 ]
そろそろ753はコテハンつけて欲しい

757 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:50:19 ]
>753は>703なんだよな?
だが>753は>696じゃないのか?
俺流れが見えてねぇw

758 名前:デフォルトの名無しさん [2008/10/04(土) 01:04:29 ]
元々このスレはハードウェア主体でマルチコア化が進んでいるせいで、
ソフトウェアを並列化しないといけなくなったのに不満を持った
アンチマルチコア派wがたてたスレだからね。本当はソフト屋さんの
ためのスレッドなんだけど、有意義な話がなかなかでない。

回路屋が何かとソフト屋を馬鹿にしているようだけど、せっかく
マルチコアの石があっても、ソフトウェア側の理論がないと意味がなく、
またソフト屋はソフト屋の理屈があるのでそこら辺勘違いしないように
お願いします。

並列化といっても必ずしもバスアービタがどうとかそういう回路よりの
話だけでなく、並列型言語とかプロセス代数とか形式手法とかそういう話を
期待ているんだけど、やっぱり並列化に対するソフトウェア技術者の
意識は弱く、そういう話をができる人はあまりいないみたいだね。
(俺も話ができない一人だが、そういう人の出現を待ってこのスレ読んでます)



759 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/10/04(土) 01:12:53 ]
だんごやさんだよ。
色んな意味でマルチスレッドだよ。

760 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 01:16:34 ]
> 並列型言語とかプロセス代数とか形式手法とか

ここ強調すると住人総入れ替えじゃないか?w
もし次スレ立てるならスレタイに【Π計算】って入れようぜ

761 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/10/04(土) 01:20:36 ]
Π革命

762 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 01:21:23 ]
>>757
> >753は>703なんだよな?

あたり。

> だが>753は>696じゃないのか?

>>696 じゃなくて、>>698

> 俺流れが見えてねぇw

簡単に言うと、「シングルコアでシングルプロセサ」と「マルチコアもしくは
マルチプロセサ」で、状況が違う例としてメモリに対する inc 命令を取り上げ
たら、inc 命令ないプロセサでは状況が違うとか (当たり前だ)、そもそも
「シングルコアでシングルプロセサ」なんて前提がおかしいとか言う奴が出て
きて騒いでるだけ。

# 正直 DMA のこと忘れてたのは事実。
# DMAC とメモリーを排他制御したことないので、すっかり忘れてた。

まあ、流れを追う価値はないから、安心してくれ。(w

763 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 01:24:51 ]
△ やっぱり並列化に対するソフトウェア技術者の意識は弱く
○ ソフトウェアベンダの合理的経営判断に基づいた技術者・コード屋に対する適切な仕事配分の結果

764 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 01:28:36 ]
Cilk とか UPC とか?

765 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 01:33:11 ]
>>762
> 簡単に言うと、「シングルコアでシングルプロセサ」と「マルチコアもしくは
> マルチプロセサ」で、状況が違う例

その状況の違いは本来不要だったんだよ
どっちもマルチスレッドスレの対象になってるんだから
発端は

>>689
> ライブラリの話はマルチスレッドスレがあるからなあ
> このスレいらない子なんじゃ…

>>692
> マルチスレッドとマルチコアでの並列化は違う。

なんだから、マルチスレッドスレでは扱わないがこのスレ(マルチコアスレ)
の対象になる違いが話題になるべきだったんだ
マルチスレッドスレが「シングルコアでシングルプロセサ」の話題限定なら
外れてないがそんなこたーないわけ

766 名前:レトリック君 mailto:sage [2008/10/04(土) 01:35:48 ]
以前からあった並列計算機以上のことはできない罠

767 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 01:36:41 ]
>>764
C++なら>688、Javaならjsr166yのfork/joinやParallelArray、C#ならTPLとか?

768 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 01:41:26 ]
OpenMP, MPI



769 名前:742 mailto:sage [2008/10/04(土) 01:43:47 ]
>>758
まあ、回路屋といっても計算機のアーキテクチャとかあんまり関係ないんだけど。

それとは関係なしに、ハードウエア主体で進んでいるマルチコアも、
シングルコアでは容易に性能があげられないから仕方なしにそういう方向に進んでいるわけで、
CPUを設計する側が最初からマルチコアをやりたかったわけじゃないということが
このスレを読み返すと前提から大分抜け落ちているように見える。

ハード系だからいうわけじゃないが、ハードの性能があがらないとソフトで新しい技術を継続して出していく
ことはできない。個人的にはマルチコアは好きではないが、
ハードの性能が上がった部分の大半はソフト開発の生産性の向上に消費されてる今の時代にマッチしてないし。

770 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 01:49:43 ]
一方グーグルはマルチプロセスを使った(クロームで)

771 名前:デフォルトの名無しさん [2008/10/04(土) 01:57:42 ]
> それとは関係なしに、ハードウエア主体で進んでいるマルチコアも、
> シングルコアでは容易に性能があげられないから仕方なしにそういう方向に進んでいるわけで、
仕方ないのはいいけど、マルチコアにした後にどうやって使うか回路屋
まったくノーアイデアでしょ。ソフト屋としてはめちゃくちゃケツ
ふかされている感がたっぷりなんですが...。

> CPUを設計する側が最初からマルチコアをやりたかったわけじゃないということが
> このスレを読み返すと前提から大分抜け落ちているように見える。
こういう風に好意的(というか同情的?)に思うソフト屋は少ないんじゃないの?
だって勝手に回路屋がこれからはマルチコアの時代だよねっ!て勝手に言っているんだもん。
仕方なくやっているんだったら、もうちょっとネガティブな感じでアピールして欲しい。

> ハード系だからいうわけじゃないが、ハードの性能があがらないとソフトで新しい技術を継続して出していく
> ことはできない。個人的にはマルチコアは好きではないが、
> ハードの性能が上がった部分の大半はソフト開発の生産性の向上に消費されてる今の時代にマッチしてないし。
これは結局お互いさまという当たり前の話になるので、まあ言い分としては
理解できます。

772 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 02:06:23 ]
今までの時代がソフトウェア屋さんに優し過ぎたって事なんじゃないの

773 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 02:12:01 ]
優しかった時代なんてない

774 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 02:16:27 ]
布団で寝てても数ヶ月したらクロックが高いプロセッサが出てくるなんて
夢の様な時代だったじゃない。

775 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 02:17:46 ]
相対的にはこの15年くらいはそれ以前より優しかったと言える
でなけりゃJavaがメインストリームになることはなかったはず


776 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 02:41:50 ]
>>771
>回路屋
>まったくノーアイデアでしょ。

ノーアイディアっつー事も無いんじゃない?

あまり詳しくないけど、、、
Intel >> TBB
Sun >> JSR166y, Fortress
IBM >> X10

サーバサイドなら仮想化とか Map/Reduce とかもあるし、
マルチプロセッサの歴史が長いから、そもそもスケールする
アプリも多いよ。

777 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 03:47:55 ]
PCIバスもバスマスタになるからメモリ書き込むよ

778 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/10/04(土) 03:57:30 ]
Pentium 4で3GHz到達したくらいまでが天国だったろ?



779 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 05:11:09 ]
MapReduceはサーバーサイドじゃないけどね。

780 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 07:42:59 ]
>>765
> その状況の違いは本来不要だったんだよ

え゛っ、今更そんな言い訳ですか...。

だったら、RISC がどうのこうのとか言ってた奴はまんまバカじゃん。
まあ、実際バカだと思うけど。(w

て言うか、マルチコアスレだからこそ、シングルプロセサ and シン
グルコアとの違いを書いただけで、常識的なことだから普通に流され
ると思っていたんだが...。

781 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 11:49:44 ]
>>780
今更って…>709でも同じように書いてるんだけど
言い訳とか後出し(>711)とか意味わかんないし
話が>689から始まったのを分かってないのか?

> て言うか、マルチコアスレだからこそ、シングルプロセサ and シン
> グルコアとの違いを書いただけで

繰り返しになるが、マルチスレッドスレがシングルコアスレなら
それが違いになるが、そんなこたーないわけ
この話続けてもかみ合いそうもないから俺はもう逃げるよ

782 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 15:34:42 ]
この板の連中もたいしたことねーな

783 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 15:39:07 ]
>>779
わざわざ説明しなくても良いと思ったんだけど、必要だった?

784 名前:デフォルトの名無しさん [2008/10/04(土) 16:18:04 ]
なんか不思議だよね。CPUのクロックは別にまだ上げられるだろ。
消費電力考えたら、マルチコアにいくのがいいよね〜っていうだけで。

で、マルチコアのプログラム支援が言語レベルであれば理想的だが、
なくてもそこそこやれる(やれてる)でしょ?コア数が100とか
1000とかになってくると、言語レベルの支援がないと厳しく
なってくるかもしれんが。

何がいいたいか、自分でもわからn

785 名前:デフォルトの名無しさん [2008/10/04(土) 16:53:06 ]
あげられないからマルチコアになったんだよ。

786 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 17:39:15 ]
クロックは上げられるけど、投資対効果が期待出来るスピードで
クロックを上げ続けるのは無理。それより余ったトランジスタで
コアを増やした方が取り敢えず嬉しい。

787 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 17:49:33 ]
マルチコアの方が使っててスカスカに軽く感じるじゃん?
当面はそれでいいんじゃないかと思う。

で、ユーザーがマルチコアの潜在能力を活かしてプログラム
全体の速度を上げられないかと言い出したらそういうプログラム
を作ればいいが、そうするとシングルコアと同じく多数のプログラム
は同時に動かしにくくなる。

788 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 18:35:45 ]
どうせみんな8つくらい同時にプログラム動かすよね。
じゃあ、クライアントアプリなら、なんも考えなくてもいいんじゃないか



789 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 18:42:25 ]
8つくらい立ち上げてても、ほとんどのプログラムは待機状態だと思う

790 名前:>>780 mailto:sage [2008/10/04(土) 18:46:34 ]
>>781
>>692 マルチスレッドとマルチコアでの並列化は違う。
>>692 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>709 比較なんかしてないぞ

「違う」と書きながら、指摘されたら「比較してない」って言い張るわけですね。
比較もしてないのになんで「違う」なんて断言できるのか俺には謎だが。

まあ、「逃げる」とか書いてるぐらいだから、流石にもうでてこないだろう。
普通に考えても、恥ずかしくて出てこれないと思うけど。(w

791 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 19:18:44 ]
>>790
>692と>709は別人ね。

792 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 19:54:15 ]
マルチコアに対応と言っても並列化したいのはほんの一部分だし、
スレッドプールとタスクキューを作れば何とかなりそうな気が…

793 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 20:00:29 ]
つまり「ミニOS」みたいな構造にしてCPUにさせる仕事を細かく分解し
やらせる仕事は片っ端からキューに叩き込んで行き仕事を終えたコア
が次の仕事を取りに来る、とか

794 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 20:13:07 ]
並列化したい部分なんてのは単純に並列化すればいいだけで何の問題もなく、
特に並列化したいわけでもない普通の部分をいかに並列化してパフォーマンスアップに繋げようかってのが難しいんじゃない?

795 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 20:40:47 ]
>>790
>>692の中のアンカー読めるか?>>692>>689へのレスだぞ
そして>>709の名前欄読めるか?>>709>>689だぞ
>>692>>689=709は別人、流れはこうだろう

>>689 このスレいらない子なんじゃ…
>>692 マルチスレッドとマルチコアでの並列化は違う。
>>698 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>708=692 マルチスレッドとマルチコアの話は、 >>689に言ってくださいな
>>709=689 比較なんかしてないぞ

比較して違うと言ったのは>>692
比較してないと言ったのは>>689

> 比較もしてないのになんで「違う」なんて断言できるのか俺には謎だが。

謎なのはお前の読解力だw

796 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 20:50:19 ]
長文ウゼ(´Α`)

797 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 20:50:26 ]
よくしらんがコンカレントCとかadaとかか?

798 名前:>>780 mailto:sage [2008/10/04(土) 21:11:32 ]
>>795
まあレス番素直に読めばそうだな。

そうすると、>>708 は話の流れに関係なく唐突に「比較なんかしてないぞ」と
喚きだすちょっと危ない人になるけど、それでいいんだよね。(w



799 名前:>>780 mailto:sage [2008/10/04(土) 21:13:34 ]
すまん、レス番間違えた。

そうすると、>>709 は話の流れに関係なく唐突に「比較なんかしてないぞ」と
喚きだすちょっと危ない人になるけど、それでいいんだよね。(w

800 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/10/04(土) 21:34:04 ]
>>784
パイプラインを細分化してもレイテンシが大きくなりすぎて効率が上がらないし
配線間隔が狭くなりすぎてリーク電流を抑えるのに神経使う時代が到来した今
シングルコアでクロックをひたすら上げるアプローチなんてどこもやらないよ。
強いて言えばPOWER6くらいか。

5年で5〜10倍なんてペースで進化する時代はもう終わった。

コア数分プロセス立ち上げて並列処理するのはダサい利用手段と思うかも知れないが
一番有効な手段だったりする。

801 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 21:37:24 ]
>>799
> そうすると、>>709 は話の流れに関係なく唐突に

もう一回書くぞw

>>698 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>708=692 マルチスレッドとマルチコアの話は、 >>689に言ってくださいな
>>709=689 比較なんかしてないぞ

AがBに「比較するな」と言い、BがそれはCに言えと言い、
それでCが「比較してない」ってのは「話の流れに関係なく」でも
「唐突に」でもないだろ

>>709=689 (俺は)比較なんかしてないぞ

の方がよかったかもしれんけどな
突っ込むなら比較して違うと書いたくせにCに振ったB(>>708=692)だろ

802 名前:>>780 mailto:sage [2008/10/04(土) 22:23:09 ]
だったら、おまえら二人で相談でも何でもして解決してくれよ。

俺は、>>692 に「比較するのはおかしい」と指摘しただけで、
お前ら二人が別人かどうかなんてわからんのだし。

803 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 22:48:07 ]
>>802
> お前ら二人が別人かどうかなんてわからんのだし。

誤読しといて開き直るなよw

804 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 00:01:55 ]
ここ住人は行った人結構いそうだな
ttp://d.hatena.ne.jp/potasiumch/20080827#1219824560

805 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 00:59:13 ]
>一般企業での並列化は遅々として進んでいない。某 Ad○be 社に
>並列化コンサルティングに行ったところ、「○○処理の部分はプログラマが
>だいぶ前に死んだのでそれ以降誰も触っていない・触れない」「え、リコンパイル? 
>そんなことしたらもう動かなくなったりしないかなあ」などと言われた。

>(だからあの会社の製品はあんなに重いのだろうか?)

ワロタと同時にゾッとした

806 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 01:03:11 ]
シングルコアとクロック数の話で 「周波数と消費電力が2乗の関係」
ということが論じられていない件について

807 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 01:05:48 ]
ああ、CPUなんて1Hzでいいよ

808 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 01:07:59 ]
>>806
fは1乗

CMOSデジタル回路の消費電力

P = Na×C×V^2×f + Nt×Il×V

P:消費電力
Na:動作ノード数
Nt:全ノード数
C:ノード容量
V:電源電圧
f:周波数
Il:ノード当たりのリーク電流



809 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/10/05(日) 01:33:10 ]
>>806
同じアーキテクチャで同一電圧での話なら2乗だけど
ある程度以上はクロックを上げるのに電圧盛らないといけないので3乗になるんじゃなかったっけ

810 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 01:57:03 ]
>>806
ここはソフトウェアの板だから、そっち方面の話題の需要は無いと思われ

811 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 02:22:54 ]
ソフトオンリーの人がハードを含む話をすると悲惨たからな。
>>50->>57あたりにソフトウエアの板のマルチコアCPUに対する理解度があらわれているよ。

812 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 02:24:48 ]
ソフトウエア板住人の

813 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 03:28:52 ]
生活に直結していないから不要な知識なんじゃないの。
多分 >>803 みたいな話がむしろ当然な世界でしょ。
食い扶持に影響する様になったらガッと動くけど、
手を抜ける所は手を抜くのも仕事では重要だし、
コア数が一桁のうちは今のままでも困らないかと。
秘伝のソースを書き換えたりアーキテクチャを一から
変更したりするとテストだ互換性だと色々面倒だし。

814 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 03:30:01 ]
スマソ。レス番間違えた。

× >>803
◎ >>805

815 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 04:24:03 ]
レンダラーとかゲームの思考エンジンとか、並列処理に向いてるソフトウェアでも
売り物じゃないオープンソースのは並列化されていない事が殆どだね。やっぱり
一手間加えるのがマンドクサイのかな。

816 名前:デフォルトの名無しさん [2008/10/05(日) 04:44:56 ]
>>800

> コア数分プロセス立ち上げて並列処理するのはダサい利用手段と思うかも知れないが
> 一番有効な手段だったりする。

いやだから、そんなことは当たり前であって。2個とか4個とかなら、その
CPUをフルに活用するようなプログラム作れるかもしれないが。

100個とか1000個とかになったときには言語レベルで支援がないと
きつくなるのじゃないかな?っていう話。まぁ100個とかになる前に、
バスネックになると思うが。

817 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 05:05:58 ]
100 CPU 越えのマシンは既にあるよ。
1 socket で 64 並列の CPU もあるし。

818 名前:>>780 mailto:sage [2008/10/05(日) 10:06:49 ]
>>803
おまえらが別人かどうかもわからんのに誤読とか言われても知らんがな。
にちゃん初心者か?



819 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 11:26:23 ]
>>816
なるほろ
確かに、これから先コア数がガンガン増えていったとして
デクストップアプリケーション、例えばExcelなんかが
その性能に比例して進化していけるのか
今までのアプローチでそれが可能なのか
不安が残るな

820 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 16:06:29 ]
今のスペックでそこそこ動いているものを挙げたって仕方ないだろ。
コア数が増えるならそれに適応したシステムになるのは当然。
コア数が増えて初めて恩恵を得るようなものを作っていかないといけない。


821 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 17:31:58 ]
マシンがすでにあることなど関係ない

822 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 17:33:14 ]
>>811
どうみてもまじめにつっこむとことちゃうだろ

823 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 18:08:55 ]
>>818
くやしいのうwwwwwくやしいのうwwwwww
「レス番素直に読めば」別人ってわかるだろうがw開き直んなw
もう一回書いてやるよ。こぴぺだけどな

>>692の中のアンカー読めるか?>>692>>689へのレスだぞ
そして>>709の名前欄読めるか?>>709>>689だぞ
>>692>>689=709は別人、流れはこうだろう

>>689 このスレいらない子なんじゃ…
>>692 マルチスレッドとマルチコアでの並列化は違う。
>>698 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>708=692 マルチスレッドとマルチコアの話は、 >>689に言ってくださいな
>>709=689 比較なんかしてないぞ

比較して違うと言ったのは>>692
比較してないと言ったのは>>689

> 比較もしてないのになんで「違う」なんて断言できるのか俺には謎だが。

謎なのはお前の読解力だw
謎なのはお前の読解力だw
謎なのはお前の読解力だw
謎なのはお前の読解力だw
謎なのはお前の読解力だw

824 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 18:17:26 ]
オマイ等そろそろ他所でやれよな。
2ch だからって何書いても良いという訳じゃないんだぜ。

825 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 18:50:17 ]
ああそろそろ規制議論板に報告して芋掘りしてもらう頃合いだな

826 名前:>>780 mailto:sage [2008/10/05(日) 21:00:25 ]
>>823
> 別人ってわかるだろうが

そもそもお前が誰かもわからんのに、何を言ってるんだろうこの人。(w

827 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 21:47:07 ]
>>826
そうだね、君の読解力じゃ無理だよねw
笑えるよなぁ、コテハン付けて勝利宣言(>790)のつもりが墓穴だもんなwww
そのコテハンそろそろ捨てた方がいいんじゃないの?他の人に迷惑だしさ
普通に考えても、恥ずかしくて出てこれないと思うけど。(w

828 名前:デフォルトの名無しさん [2008/10/05(日) 22:09:02 ]
私のために争うのはやめて!
てのはさておき、いい加減にしたらどうなんだ。

元の話でいえば、シングルコアのCPU上のマルチスレッドプログラム
が、マルチコアのCPU上で動作しなくなることなんて、バグじゃなく
ても当然ありうる。タイムスライス限定とかいうなよ?自分の
知ってる範囲だけがマルチスレッドじゃないのだから。

優先度に基づいたマルチスレッドもあるし、そういう環境で無駄な
排他を排除することは当然ありうる。マルチスレッドじゃないが、
割り込み禁止で排他する場合も、マルチコアじゃぁ別のCPUで
割り込みハンドラが動くこともある。



829 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 22:13:16 ]
最初からシングルコアっていうかその環境専用に作ってるならバグじゃないし
マルチコアは想定外と最初から言ってないなら普通はバグと判断される
それだけのこと

830 名前:デフォルトの名無しさん [2008/10/05(日) 22:19:23 ]
>>829
何をいいたいのかわからんが。そのプログラムがどんな
システム向けに作られたかしだいでしょ。最初から
「マルチコアを想定して作ることを求められたプログラム」
ならバグであるし、そうでないならバグではない。

30年前のシングルコアしかなかった時代のプログラム
は全部バグっているというのかい?

831 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 22:19:45 ]
折角の週末を無駄にして、君たちは一体何と戦っているんだい?

832 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 22:33:00 ]
>>830
俺は>829に同意。
デフォでマルチプロセッサをサポートしてるのが当然な環境が今は多い。
PCでもWindowsNTWSは最初から2プロセッサをサポートしてたよな。
動作環境にNTが含まれていたら、対象外と明示していない限り、
マルチプロセッサ/マルチコアで動かなければそれはバグ。
前提の環境がマルチプロセッサを含まないことが明白な場合は別。

833 名前:デフォルトの名無しさん [2008/10/05(日) 22:39:15 ]
>>832
だから、なんのプログラムに対してバグっているといっているのだ?
仮にあなたが発注元で要求仕様に「マルチコアでも動作すること」
という条件を含めていなかったら、それはバグではなくて仕様。

その変のフリーでころがってるプログラムがマルチコアで動作しな
いとしたら、それは*あなたが*バグであるかどうかを判断する
立場にはないよ。作者がマルチコアに対応するつもりでプログラム
作っているなら*作者*はバグであるというかもしれないし、
シングルコアのみに対応するつもりなら、*作者*は仕様だと
いうだろう。

前提が不明なのだよ。

834 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 22:52:05 ]
それはない。逆。
このソフトはマルチコア環境では動作しません。
とうたっていない限り、バグ。

835 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 22:55:17 ]
>>833
仮に動作環境がWindows2000やXPだったら、「マルチコアで動作しない」
と書いてない限り、動かなかったらバグだよ。
OSがサポートしている環境ではマルチコアもその範囲内だから。
それは明白だよ。不明じゃない。
はっきり書いてない場合にマルチコアで動いて当然の環境があるんだよ。
作者がマルチコアを想定してなくて動かなかったなら、コードを直すか
ドキュメントの動作環境を直すかのどちらかは必要だろう。
つまりコードのバグか、ドキュメントのバグかのどちらかになる。

836 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 22:58:00 ]
極端な話、3GHz以上のCPUでは動きませんと明記していないかぎり、
3.2GHzだろうが5GHzだろうが暗黙の了解でソフトは動いて当然。
動かなかったらバグだろ。それと同じだよ。

837 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 01:31:30 ]
特殊なソフトじゃない限り、「シングルコアのCPUじゃないと動きません」なんて、許されんな。

838 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 02:40:38 ]
『動く』と書いてあるのに動かないのはバグ。
書いてなくて動かないなら、動かなくてもおk



839 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 02:51:16 ]
『動かない』と書いてないのに動かないのはバグ。
書いてあって動かないなら、動かなくてもおk

840 名前:デフォルトの名無しさん [2008/10/06(月) 03:01:12 ]
>>835
Windozeとか、べつにタイムスライスしかないのだから、ドライバで
ないかぎりマルチスレッドプログラムは、普通にマルチコアでも動く
だろ。何をいってるんだ?

841 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 03:07:14 ]
>>840
上のほう読んでよ。アトミック操作を適切に行っていないプログラムは、
マルチコアで動かないけどシングルコアでマルチスレッドなら動くって眉唾なこと言っている奴がいたんだ。

842 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 03:56:07 ]
>>838
そう思ってるのは開発側だけだな。

843 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 04:13:35 ]
そういや昔、マルチスレッドのプログラムがちゃんと動くかどうかテストするのに
マルチプロセッサのPC組み立てたっけ。
90MHzのPentiumでDaytonaだった。

844 名前:は@携帯 ◆cplnFO9T0I [2008/10/06(月) 09:53:26 ]
高速なCPUで動かないソフトといったらWindows95だろ
たかだかK6-2の350MHzでコケるってどんだけだよと

845 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 10:29:44 ]
コア数が増えてoccam復権しねぇかなぁ

846 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 11:09:06 ]
>>843
マヌケだなw

847 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 15:08:16 ]
>>840-841
二人とも0点

848 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 16:37:47 ]
一般的なソフトウェア開発の観点では、プロセッサもしくはランタイム環境の、主にメモリモデルに起因する問題が多い




849 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 21:15:49 ]
>>864
理解できない時は素直に認めた方がいいぞ。

850 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 21:22:16 ]
スルーパス出ました

851 名前:>>780 mailto:sage [2008/10/06(月) 22:02:03 ]
>>827
>>826


852 名前:デフォルトの名無しさん mailto:sage [2008/10/19(日) 13:24:40 ]
このスレ絶望的にレベルが低いですね。

853 名前:デフォルトの名無しさん mailto:sage [2008/10/19(日) 13:33:32 ]
今日はそうみたいだな。

854 名前:デフォルトの名無しさん mailto:sage [2008/10/19(日) 13:36:45 ]
ダンゴさんが最近発言していないからな






[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<215KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef