【マルチコア】並列化 ..
192:デフォルトの名無しさん
06/01/25 02:00:13
スレッドの話はスレ違いだろ。スレッドだけにスレ違いw
193:デフォルトの名無しさん
06/01/25 06:15:51
>>191
へ〜、Javaだと仮想関数をそんな風に作れるんだ・・・
194:デフォルトの名無しさん
06/01/25 09:46:54
マルチコア時代もJavaで決まり！！！
ドントネット死滅ケテーイ（禿藁嘲笑）
195:デフォルトの名無しさん
06/01/25 11:01:49
>>191
記述は楽なんだけど、外側のローカル変数を受け継いで欲しい。
中の処理にパラメータはどうやって渡すのがお行儀いいの？
>>193
仮想関数？
196:デフォルトの名無しさん
06/01/25 12:24:58
>>195
受け継ぐだろ。finalにするだけで。
final必要にしたのは、リークが見つかりにくくなるからとSUN社員のブログか何かに書いてあった。
ぜんぜん並列と関係ないな…。
197:デフォルトの名無しさん
06/01/25 12:54:27
final宣言されたローカル変う右派コンストラクタでコピーされて渡されてる
そもそもfinalは変更が不可能なのでお手軽に変数を渡すわけにはいかないよ
普通にクラス作ればいいだけだけどね
198:デフォルトの名無しさん
06/01/25 12:58:30
>>191
>>160の例はそういうことじゃなくて、i=0からi=99までの初期状態を持つ
100個のスレッドの生成と実行と待ち合わせが簡易な構文でできればなー、
という話なのでは？
そうじゃないならCでも関数一個定義するだけだからそう面倒じゃないし、
このスレ的に迫力ないし。
>>196
ホント？Javaっていつのまにかクロージャが使えるように成ってたんだ。
世の中には信じられないようなことが起きているなあ。
199:デフォルトの名無しさん
06/01/25 13:42:21
Javaのそれをクロージャと呼ぶと、変な人が湧いてくるよ。
200:デフォルトの名無しさん
06/01/25 15:58:45
>>133
お前はスレッドの優先度を設定しないアホプログラマか。
201:デフォルトの名無しさん
06/01/25 16:55:05
Win32限定なら、QueueUserWorkItem()一発かな。
自動的にスレッドプールを作って関数を実行してくれる。
202:デフォルトの名無しさん
06/01/25 19:01:32
>>198
匿名内部クラスでぐぐれ
203:デフォルトの名無しさん
06/01/25 23:28:05
マルチスレッドなんて時代遅れ。
これからはマルチコア。これだね。
204:デフォルトの名無しさん
06/01/26 00:12:15
>>199
コンパイラ・スクリプトエンジン相談室によく出没するあいつらか？
205:デフォルトの名無しさん
06/01/26 00:13:24
Lispこそがすべての起源。
Lispを知らずしてプログラミングを語るべからず。
206:デフォルトの名無しさん
06/01/26 01:06:43
>>200
いや、プライオリティの問題もあるが、それだけじゃない。
207:デフォルトの名無しさん
06/01/26 03:25:18
マルチコアだと重いタスクを裏に回せるのがメリットかね。
シングルコアで重いタスクを裏に回しても、裏のタスクの
進行が遅くなるか表のタスクが足を引っ張られることが
多い。
マルチコアなら重いタスク専門に１コア割り振れるから
表はノーペナルティ（に近い速度）で動ける。
まあ重いったって基本的にはI/Oとメモリを大量に使う
処理ぐらいしかないんだけどな。
208:デフォルトの名無しさん
06/01/26 03:36:50
×マルチコアなら
〇マルチプロセッサ(HTT含)なら
209:デフォルトの名無しさん
06/01/26 08:43:17
で、結局、バス幅とバスクロックの壁はどうにかなりますか？
210:デフォルトの名無しさん
06/01/26 09:03:54
>>206
いくらプライオリティが低くても、
一旦CPUを割り当てられたら、割り込みがかかるまで、一定時間はCPUを占有する、
という問題はあるけれど、ユーザのインタラクティブな操作は割り込みをかけるので問題なし。
211:デフォルトの名無しさん
06/01/26 09:07:08
スループットを犠牲にしてでもレスポンスを良くしたければ、
CPUの割り当て時間を短くしてしまうのも手ですよ。
たとえばWindowsの場合は、HALによっては変更をサポートしてる。
ちなみにデフォルト値がWindows2000の場合、
マルチプロセッサだとシングルプロセッサの1.5倍の時間に設定される。
WindowsXPの場合、シングルプロセッサでも、マルチプロセッサと同じ時間に設定される。
WindowsXPがモッサリな原因の1つが、1.5倍に設定されたことだよ。
212:デフォルトの名無しさん
06/01/26 13:16:58
>>211
アフィニティを下げたら各コアのキャッシュが汚れるから、デュアルコア時のメリット薄いんじゃないかな。
シェアードキャッシュなら良いんだろうけど、普通 L1 はシェアしないでしょ。
213:デフォルトの名無しさん
06/01/26 14:46:16
インテルのデュアルって肩並べて爆熱してるだけのツインプロセッサじゃないのか？
214:デフォルトの名無しさん
06/01/26 15:46:58
IntelCoreしらんのか
215:デフォルトの名無しさん
06/01/26 17:54:54
しらんがな
216:デフォルトの名無しさん
06/01/26 18:13:20
>211から>212へ行く話の流れがわからない。
>212は何に関するaffinityのことを言っているの？
CPUの割り当て時間との関係は？
217:デフォルトの名無しさん
06/01/26 23:50:22
Windows では Thread Affinity って言葉は使わないのかな。
と思ったが、>>211 は CPU Quantum の事を言っていたのか...
ｽﾏｿ。勘違いしてた。
218:デフォルトの名無しさん
06/01/27 22:22:57
Windowsでアフィニティと言えば、
プロセスやスレッドを特定のCPUだけにしか割り当てないようにアプリがOSにお願いすることだよね。
219:デフォルトの名無しさん
06/01/28 05:00:41
それは UNIX で Processor Bind と呼んでる機能かな。
220:デフォルトの名無しさん
06/01/29 18:42:42
名前を前例に倣わんのはMSの悪いところ。とはいえスレッド関連は
NTのほうがUNIXより早いんかね？
221:デフォルトの名無しさん
06/01/29 22:15:40
お前ら並列プログラミングを語る前にLispについて学べ
222:デフォルトの名無しさん
06/01/29 22:23:30
>>221
なんで？いまの並列化言語は論理型のほうがすすんでないか?
223:デフォルトの名無しさん
06/01/29 22:43:33
Lispを知らずしてプログラミング言語を語るべからず
ム板にいながらこんな常識すら知らないとは・・・
224:デフォルトの名無しさん
06/01/29 22:46:33
>>223
各所で Lisp を貶めるのは止めてくれ
225:デフォルトの名無しさん
06/01/29 22:57:15
>>223
おまえみたいなのがいるからLisp使いがバカにされる
226:デフォルトの名無しさん
06/01/29 23:23:26
>>223はこういう念仏を唱えるだけのアホウがいる、という話かと思ったら
アホウ当人だったのか。
こいつ、どうせLispスレじゃ何にもレスしてないよ。
以前もRuby使えないくせにあちこちのスレにRuby万歳突撃やってた基地外がいたが、
同一人物かもしれん。
227:デフォルトの名無しさん
06/02/02 19:13:07
そんなことしてるのがリアルに居るとは信じられんが、ｶﾅｼｽ
228:デフォルトの名無しさん
06/02/02 23:35:39
正直なところ、Lisp知らん奴が語ってるのって、幼稚なんだよね。
本質でない、些細な部分に無駄に労力を費やしてるって感じ。
議論も設計もコーディングもスマートにやれるのがLisp、
これを学ばない手はないね。
229:デフォルトの名無しさん
06/02/02 23:41:51
>>228
>>224
230:デフォルトの名無しさん
06/02/03 03:19:53
Lispって何でもありすぎる。あれならマシン語で
プログラミングしてるのと代わらんような。
適度に制限されたフレームを提供するのが言語の大事な役割
というキガス。
231:デフォルトの名無しさん
06/02/03 04:00:13
>>230
>適度に制限されたフレーム
こういうのは時間とともに綻びが生じて来るから、新しいパラダイムが来たら
無理矢理建て増しするハメになるよ。既定のフレームに沿わなくてはいけない
環境では、未知の問題への適応能力も自ずと低下してしまうから、Lisp の
出自を考えると受け入れられないだろうね。
とは言っても、Lisp は元祖超高級言語なわけで、マシン語と比較する物では
無いでしょう。適度な強制が好きなあなたには Python をお勧めします。
あ、それから…、
ここは並列化のスレなんで、言語の善し悪しの話は完璧にスレ違いです。
お引き取りください。
232:デフォルトの名無しさん
06/02/03 04:49:07
俺はlisp知らんけど、
もし本当にlispが並列処理向きだったとして
現状のlispインタプリタは、マルチスレッドで並列処理してるのか？
仮にマルチスレッド動作しているとしても
並列可能な処理数はかなり大幅に増減すると思うのだが(for_eachとかあったよな？)
全部並列にやろうとするのか？スレッド数も増減させて。
まあ、スレッドプールとか使ってうまくやっているのかも知れないが。
233:デフォルトの名無しさん
06/02/03 04:57:20
>>232
>もし本当にlispが並列処理向きだったとして
Common Lisp の事なら、そもそも ANSI 規格では並列化は考慮されていない。
フリーの実装に限って言えば、マルチスレッドのコンパイラは少ない。
並列／分散処理の研究に Lisp が使われてたりはあったと思う。
234:デフォルトの名無しさん
06/02/03 05:03:49
並列化言語の側も盛り上がってないし、今の並列処理の枠組みは pthread とかに
依存しているんで、今後も C とか Java でどうするかって話が主流なんじゃないかな。
関数型言語にもちっと頑張って欲しい所。
235:デフォルトの名無しさん
06/02/03 09:51:27
どの言語がいいだの悪いだのはモノ作れるようになってから語れ
('A`)
236:デフォルトの名無しさん
06/02/03 09:57:14
自分で言語を作るのは、手間がかかるんだよ。ｗ
続きは「コンパイラ・スクリプトエンジン」のスレッドでやらないか？
237:デフォルトの名無しさん
06/02/03 21:26:44
別に実装の話まで入り込む必要は無いんだけど、並列化を支援する言語のフィーチャーに
どんな物があるのかは興味がある。
238:デフォルトの名無しさん
06/02/04 00:05:15
>>237
そういう話題は、「マルチスレッドプログラミング相談室」で。
239:デフォルトの名無しさん
06/02/04 05:24:48
あっちは実践、こっちは理論や研究レベルってことで、こっちでもいいんじゃない？
並列化の支援というか、上にもあったと思うけど、
関数型言語なんかはプログラマが並列化なんか気にせずに並列化できたりする、理屈の上では。
これなんか実際に、後から何スレッドで動かすか指定するみたい。
URLﾘﾝｸ(www.haskell.org)
240:デフォルトの名無しさん
06/02/04 05:28:19
と思ったら普通にプログラムの方でも指定するみたいだな。
並列に出来るからって勝手に全部並列化したらオーバーヘッドの方が大きくなっちまうか。
241:デフォルトの名無しさん
06/02/04 13:27:34
ウザいLisp厨のせいで折角のふいんきが台無しだな
242:デフォルトの名無しさん
06/02/11 19:50:33
スレ頓挫か？
243:デフォルトの名無しさん
06/02/11 20:06:40
なんかネタがねぇ。だれかネタ提供してくれ。
URLﾘﾝｸ(www.coins-project.org)
そうそう、こういうのを最近みつけた。
日本のコンパイラ界の重鎮、中田育男先生とか、その他にも
Javassistの千葉滋先生とかオールスターメンバーっぽい。
SIMDによる自動並列化や、自動的に普通のコードをOpenMPに
変換してくれたりするらしい。関連した論文もたくさんでて
いるみたい。
個人的には大学で研究やっている先生方が、どの程度の実用的な
コンパイラがつくれるか注目している。マイクロソフトやインテル
なんかとも張り合えると思っているんでだけど、期待しすぎ？
244:デフォルトの名無しさん
06/02/11 20:12:43
たまにはageとく
245:デフォルトの名無しさん
06/02/11 21:05:00
-‐-
__ 〃 ヽ
ヽ＼ ノﾉﾉ）ﾍ)､!〉
(0_)! (┃┃〈ﾘ はわわ〜マルチが245ゲットですぅ〜〜
Vﾚﾘ､" lﾌ／
( ￣￣￣《目
| ＝＝＝《目
|＿＿| ‖
∠|_|_|_|_ゝ ‖ ∧＿_∧
|__|_| ‖ ┝・∀・┥ﾄﾗﾗｰも2ｹﾞｯﾄ。
| | | ‖ （ ）
|__|__| ‖ |〓 | 〓|
| ＼＼ 皿皿 （＿_） ＿_）.
246:デフォルトの名無しさん
06/02/12 10:34:53
トララーがﾜｶﾝﾈ
247:デフォルトの名無しさん
06/02/12 23:55:41
OSがプリエンプティブであればマルチコアかどうかは
さほど問題ではないと思うのだがどうか。
248:デフォルトの名無しさん
06/02/13 00:18:59
>>247
それは必要条件であって十分条件じゃない。
そもそも何に対して問題無いって言ってる訳さ?
スケジューラがプリエンプティブに出来ていたら、カーネルが
ジャイアントロックしても問題無い?
大体、マルチコアつっても色々ある訳だが、どのマルチコアを
指して問題無いって言ってるんだ?
非対称コアなのか対称なのか、キャッシュは共有されている
のかいないのか、スレッディングはあるのか無いのか、それは
SMT なのか CGMT なのか FGMT なのか??
NUMA なマルチプロセッサとマルチコアじゃ最適化ポイントが
全然違うんだぜ。
それに、マルチコアは OS だけの問題じゃ無い。コンパイラは
CPU の実装を理解して最適化を掛けているのか、アプリは
MT でスケールするように作られているのか???
ネタ振りとしてはこれくらいで良いか?
249:デフォルトの名無しさん
06/02/13 10:57:19
シングルスレッド最強
250:デフォルトの名無しさん
06/02/13 20:52:13
シングルスレッドで作って、適当にexecすればいいじゃん。
何を悩んでいるのかわからない。
251:デフォルトの名無しさん
06/02/13 20:58:46
もう面倒くさいよ。
252:デフォルトの名無しさん
06/02/14 15:41:09
おわりか
253:デフォルトの名無しさん
06/02/23 13:09:55
URLﾘﾝｸ(japan.cnet.com)
Cell向けにOctopilerツールが発表されるらしい。
どういう形で支援するか謎だ。そのあたりの情報が外部にも出してもらえると、
今後のマルチコア向けアプリケーションの開発に少しは参考になりそう。
聞きかじりなんだけど、Cellってバス予約という機能があって、コアごとに
あらかじめ必要なバス帯域をキープできて、一度に複数のバスアクセスが
集中しないようにできているみたいだね。バス帯域の問題はどうにかして
欲しいけど、PCでは同様の解決方法は難しいかな？
仕事でCellとか触れる人はいいね。自分は関係ない職種だから触れません。
254:デフォルトの名無しさん
06/02/23 13:48:56
マルチコアでマルチスレッド処理が平気でできれば、これから食いぶちがありますあ？
255:デフォルトの名無しさん
06/02/23 14:21:45
なにやっても食っていける。重要なのは仕事取る（就職含む）対人スキル。
プログラミングはそれからだ。
とはいえ、金出す側の鼻が利く場合に備えて腕は磨いとけ
256:デフォルトの名無しさん
06/02/23 14:56:45
ドカタ乙
257:デフォルトの名無しさん
06/03/04 22:34:53
特に意味はないが、保守っとく。
ちょっと古いけど、Timed Calculus of Communicating Systems つーのを調査中。
258:デフォルトの名無しさん
06/03/06 22:39:39
保守
259:デフォルトの名無しさん
06/03/06 23:37:03
>>257
googleで検索したけど、TCCSって何ですか？TimedがつかないCCSなら
たくさん説明があるんですが、似たものもしくは同じものなんですかね。
Calculusいうぐらいだからπ計算とかの親戚の計算モデルっぽいのは
わかるんですが。
ここを読んでいる人でプロセス代数とかやってる人っています？
260:デフォルトの名無しさん
06/03/07 08:21:54
そりゃCCSなら説明がたくさんあるだろうな・・・
261:デフォルトの名無しさん
06/03/12 02:13:05
>>253
OpenMPのpragmaを流用するみたい
262:http://www.vector.co.jp/soft/win95/util/se072729.html
06/03/18 22:08:36
TextSS のWindowsXP(Professional)64bit対応化おながいします
もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
そういや64bitにネイティブ対応している２ｃｈブラウザてありましたっけ？
263:デフォルトの名無しさん
06/03/18 22:23:01
>>261
そうなんですか。できることは限定されているような気がしますが、
普通にCellに最適化されたプログラムを書くより大分楽にはなり
そうですね。
264:デフォルトの名無しさん
06/03/22 23:49:32
URLﾘﾝｸ(it.nikkei.co.jp)
やっぱり開発が難しいそうですよ。新しいノウハウが必要らしい。予想通りだ。
マルチコアはいいけどソフトウェアの負担は大きい。
265:デフォルトの名無しさん
06/03/23 00:22:34
86とか汎用の石のマルチコアが難しいというのと
Cellが難しいというのとはたぶん難しい場所が違う
CellはPS2の延長と考えればすっきりするしその程度
266:デフォルトの名無しさん
06/03/23 00:25:24
>>265
それが新しいノウハウだろｗ
PS2 のころから Vu0 マイクロコード動かしてた連中にとっては、今までの延長だろうけど
267:デフォルトの名無しさん
06/03/23 01:12:40
８６系ってＣＰＵの思想があれだから、マルチコア化を困難にさせてるんだよな・・・
268:デフォルトの名無しさん
06/03/23 01:20:43
↑
こういう知ったかがわくのはどうにかならないのか？
269:デフォルトの名無しさん
06/03/23 01:22:39
>>267
思想がアレなのはiApx432だろ。
270:デフォルトの名無しさん
06/03/23 01:24:49
レジスタが専業化されてるってやつだろ？
今でこそ区別無く使えるようになったけど、それでもニーモニック汚過ぎ。
271:デフォルトの名無しさん
06/03/23 10:15:02
uOp fusion のコストが高すぎるといってるのか？
俺には的外れに思えるが。
272:デフォルトの名無しさん
06/03/24 05:57:20
↑
こういう知ったかがわくのはどうにかならないのか？
273:デフォルトの名無しさん
06/03/24 11:57:44
267が論旨を明確にすればいいだけの話。
274:デフォルトの名無しさん
06/03/24 17:50:04
デコーダが複雑になるから、メニイコアでかつ個々のコアの
処理速度も上げるってのがやりにくいんじゃない？
という意味だと漏れは思う。
275:デフォルトの名無しさん
06/03/24 22:46:44
つまりメタセコイアは生きた化石だということか。
276:デフォルトの名無しさん
06/05/14 23:36:57
鯖側は、簡単というか今まで通りでよいが、
クライアント側は大変だな。
277:デフォルトの名無しさん
06/05/14 23:54:33
そうでもない
278:デフォルトの名無しさん
06/09/10 14:07:50
ho
279:デフォルトの名無しさん
06/09/10 20:48:00
>>276
2-4 並列くらいでいいんだから余裕じゃ。
大変って言ってる奴が居たら、それは「ﾏﾝﾄﾞｸｾ」って意味か、「もっと金寄越せ」って
意味かのどちらか。
280:デフォルトの名無しさん
06/09/15 00:56:12
Objective-C + Cocoa なソースで OpenMP って使えるの??
281:デフォルトの名無しさん
06/09/30 23:13:10
Cilkってどう？
282:デフォルトの名無しさん
06/09/30 23:34:11
ｲｿﾃﾙが発表した４コアってプログラミング的にはどうなん？
性能を活かせるコンパイラってあるの？
283:デフォルトの名無しさん
06/10/01 00:38:46
80コアか・・・
機械的に最適化できる方法あるのかな？
URLﾘﾝｸ(techon.nikkeibp.co.jp)
284:デフォルトの名無しさん
06/10/03 09:41:30
まぁ数年間は OpenMP 使ってチマチマ並列化するのが手っ取り早いだろーね。
でも 80 コアの時代には言語レベルで並列化/分散処理をサポートした
新しい言語が主流になってると思う。
そうじゃないとプログラミングがしんどくなるね。
285:デフォルトの名無しさん
06/10/08 15:44:34
そこまでしてx86である必要がないような。
286:デフォルトの名無しさん
06/10/08 19:56:41
互換性が重要だからね。
x86系は（PC/AT互換機が業界標準になったおかげで）業界標準になったから過去の互換性切れないんだよ。
287:デフォルトの名無しさん
06/10/08 22:54:13
ソースレベルで保持運用されてるUNIXなら、CPUの互換性なんて関係無いのにね。
288:デフォルトの名無しさん
06/10/08 23:29:37
そういうわけに行かない業界と素人と過去の遺産の都合を考えろってこと。
カーネルやドライバ部分なんかはCPU変わったらほぼ完全に書き直しだろうし。
CPUごとに使用するコンパイラ＆ミドルウェアが変わることで開発やサポートのコストは跳ね上がる。
(商用ソフトがほとんどの場合ライセンス上の理由でソースコード公開できないことくらいは分かってると思うけど)
289:288
06/10/08 23:32:09
×公開
○開示
だな。まぁ公開も商用である限りまず望めないだろうね。
290:デフォルトの名無しさん
06/10/09 00:12:55
倒産したソフト会社のプログラム使ってるわけでもあるまいて
その会社がコンパイルし直せば済む事をチマチマとw
291:デフォルトの名無しさん
06/10/09 00:29:27
>>290
ユーザーが増えないから売れそうもないので対応しない
バイナリが流通しないから新しいアーキテクチャのユーザが増えない
以下繰り返し
この悪循環が始まるだけなんでそういう事を言われても困る。
292:デフォルトの名無しさん
06/10/10 01:06:52
「対応しないと売れない」の間違いじゃね？
つか、対応せずに済むというのはユーザー側の思考で、本来なら企業のビジネスチャンスのためにも積極的にハードウェアアーキテクチャを変更するべきなんだよ。
儲かるのはマイクロソフトだけ。っていう図式が何を意味しているかしっかりと考えてみろ。
293:デフォルトの名無しさん
06/10/12 15:26:01
OpenMPは全然性能が出ないとか書いてあるページがあるけど、どうなのかなあ。
適切に大きな粒度でやれば、スケールしないはずが無いと思うんだけど・・・
294:デフォルトの名無しさん
06/10/12 21:35:46
>>293
それは使い方間違ってるだけだろ。
俺が反論してやるからURLｷﾎﾞｿ
295:デフォルトの名無しさん
06/11/18 02:08:28
そいつの考え方がおかしいんじゃねーのかどこか知らんが
296:デフォルトの名無しさん
06/11/26 14:08:24
>>290
コンパイルできれば、そしてできたバイナリが予想通りの挙動を示してくれればいいんだけどね。
297:デフォルトの名無しさん
06/11/26 14:41:15
挙動不審
298:デフォルトの名無しさん
06/11/26 22:38:34
マルチコアって何で難しいの？同期処理も必要なの以外はvolatille宣言しとけばいいんじゃないの？
あるいはSETI@homeみたいに部分に分けて処理させるのはどうなの？
あとマルチコアって確率論とか統計学とかいるの？（学問ではなにが関係するの？）
というか今までもスパコンはほとんどマルチコアだと思うけどあれはなんで問題なく高速化できてるの？
299:デフォルトの名無しさん
06/11/26 22:45:47
volatile最強宣言ｋｔｋｒ
300:デフォルトの名無しさん
06/11/26 22:53:22
> マルチコアって何で難しいの？同期処理も必要なの以外はvolatille宣言しとけばいいんじゃないの？
釣りですか？
> あとマルチコアって確率論とか統計学とかいるの？（学問ではなにが関係するの？）
プロセス代数という数学。プロセス代数にはSP、π計算、CCSなどがある。
> というか今までもスパコンはほとんどマルチコアだと思うけどあれはなんで問題なく高速化できてるの？
分散処理の研究が進んでいるのと、それ様のプラットフォーム(MPIとか)が
整備されているから。何も考えずに無為にやっているけど大丈夫なわけでない。
301:デフォルトの名無しさん
06/11/26 22:54:32
訂正
> プロセス代数という数学。プロセス代数にはSP、π計算、CCSなどがある。
↓
> プロセス代数という数学。プロセス代数にはCSP、π計算、CCSなどがある。
302:デフォルトの名無しさん
06/11/26 23:10:00
ヘテロ環境での最適配置戦略とか
reconfigurableなLSIを活用するとか
学者さんは嫌いそうだが必要になりそう
303:デフォルトの名無しさん
06/12/20 00:38:23
おお、こんなスレが。
並列プログラム用のライブラリを作成しています。（C++/Unix用）
URLﾘﾝｸ(pards.sourceforge.jp)
よろしければ御意見下さい。
>>166 の人のお望みの通り、SPAWN(foo());とすると関数fooを並列に実行します。
スレッドじゃなくてプロセスだけど。
プロセス間の通信、同期はSync<int> a;のように宣言した変数に対して、
a.write(1), a.read() のようにすることで行います。readはwriteが終わるまで
ブロックします。
実用的な例として、bzip2の並列化も行っています。
詳しくは上記URLをご参照下さい。宣伝失礼致しました。
304:デフォルトの名無しさん
06/12/20 00:53:18
sureddo版を作る気はないのかえ？
305:303
06/12/20 01:14:41
スレッド版？ >>304
スレッドはデフォルトで全メモリ領域をシェアするので、デバッグ困難なバグの
温床になっているという主張なのですよ > このライブラリ
グローバル変数触るだけでMT-unsafeになるので、スレッドを使った
既存のプログラムの並列化は難しいのですが、プロセスはメモリ空間を
分けるので、そんなことは無いと。
もちろんその分オーバヘッドはあるのですが、最近のOSなら我慢できる範囲では
無いかと思います。
# とか言いながらスレッド版作ったりして
306:デフォルトの名無しさん
06/12/20 02:09:16
なるほろ。
コードはそのままで、
デバッグ中は別プロセス、リリース時はスレッドで実行できるとかだと
超カッコＥかもしれませんな。
ぬー、でもあんまり差が出ない気がしてきた。
307:デフォルトの名無しさん
06/12/20 18:23:59
>>303
ネットワーク越しあり？
308:デフォルトの名無しさん
06/12/20 23:21:00
あら、すごいと思ったけど、やはりその筋の研究をされている方ですか。
実際にどれだけパフォーマンスに差がでるかわからないけど、
スレッド版を用意してくれると実際に使う人がベンチマークが取れて
プロセス版かスレッド版かどちらかを選択するか判断できていいですな。
> スレッドはデフォルトで全メモリ領域をシェアするので、デバッグ困難なバグの
> 温床になっているという主張なのですよ > このライブラリ
さすがに含蓄のあるお言葉ですな。
309:303
06/12/20 23:28:00
>>307
いや、SMPだけを対象にしてます。
MPC++/SCoreとか、ネットワークで接続されたコンピュータを
SMPに見せるのもあるけど、あそこまで作るのは大変っすよ(^^;
310:デフォルトの名無しさん
06/12/21 19:53:02
JAVAってマルチCPUやマルチコアでも恩恵が無いって
昔は言ってたが今は変わったのか？
311:デフォルトの名無しさん
06/12/21 20:09:14
>>310
JAVAはマルチスレッドにしても速度は上がらんよ。
312:デフォルトの名無しさん
06/12/21 22:00:09
>>310
速度を気にするならJAVAは問題外
313:デフォルトの名無しさん
06/12/21 23:29:59
てっきり >>194 みたいなことが書いてあるから…
.netは対応？済みらしいがマルチコア環境じゃないから試せない。
314:デフォルトの名無しさん
06/12/22 00:01:18
マルチスレッドは速度を向上させるのが目的ではないと思うがなあ
315:デフォルトの名無しさん
06/12/22 00:09:25
サーバ的に言えばスループットを多重化に影響されず一定とするためのものだわな。
XMLのパースとその他みたいなパイプライン？は既にやってるとこもあるみたいだけど。
316:デフォルトの名無しさん
06/12/22 00:10:31
>>310-313
AP レイヤで使うのに十分なくらいならスケールするがな。
マルチノード、マルチインスタンスにはした方が良いけど、
かなりの大規模ノードじゃなければ十分。
317:デフォルトの名無しさん
06/12/22 04:56:33
>>285
x86である必要があってx86なのではなく、
数が出ているx86のコストパフォーマンスが優れているからx86なのだと思う。
318:デフォルトの名無しさん
06/12/22 05:05:09
>>314
何が目的なのか、ハッキリ言ってよ。
>>316
クライアントが同時に複数いる状況で性能を要求されるサーバならば、
2コアとか4コアくらいなら、
同期する必要のない部分と同期する必要がある部分に分けるだけで、
十分だったりするしね。
>>315
XMLのパースなんかは、他のスレッドと同期する必要がない処理なので、
パイプラインにするよりも、普通にスレッドプーリングでいいでしょう。
319:デフォルトの名無しさん
06/12/22 12:35:22
>>310
他の言語と同じように恩恵はあるよ。
恩恵がないのは遥か昔の green thread の頃かな。
320:デフォルトの名無しさん
07/02/14 06:21:12
Intel，80コアでTFLOPSを実現する浮動小数点演算プロセッサ開発
URLﾘﾝｸ(www.4gamer.net)
321:デフォルトの名無しさん
07/03/06 16:26:58
トイレで大きい方をして席に戻ってきたら、周りの席の同僚女3人に大笑いされた。
職場の女がニコニコしながら、
「上司の○○さんが呼んでいたので『地球の平和を守りにいってます！』と答えておきましたよ〜」
死にたい気持ちになった。
322:デフォルトの名無しさん
07/03/06 16:32:41
へたくそなコピペじゃねーぞ！
あまりにショックなので、こんな過疎スレに書き込んでいる。
今夜は一人で飲みたい。
323:デフォルトの名無しさん
07/03/06 16:38:00
↓あまりに悔しいから、お前のあだ名は「ウンコマン」にしてやる！
324:デフォルトの名無しさん
07/03/06 16:47:30
オッス、オラうんこまん！
地球防衛隊員ってのをやってるんだ。よろしくな！
325:デフォルトの名無しさん
07/03/06 16:57:41
>>324
恥ずかしい自演乙
326:デフォルトの名無しさん
07/03/07 01:42:39
>>321
なんじゃそのFFやらDQの発売日翌日に遅刻した予備校生の言い訳みたいなのは。
327:デフォルトの名無しさん
07/03/13 14:25:23
それより昼に仏跳麺を食った後に目薬を買おうとミドリ薬品に寄ったら会社の山下
さん（結構かわいい）がレジで支払いしてるトコだった。そのレジ台に置いてあったの
がイチジク浣腸の１０個入りパッケージ。もう裕子ちゃんがお尻にイチジク浣腸を入
れてるのを想像して今も勃起しっぱなし。このことは会社の同僚にはだまってる。
噂を流したら俺だってわかるし山下さんもかわいそうだから。
328:デフォルトの名無しさん
07/03/20 01:14:45
動画エンコってマルチスレッド化するより単純にコアの数だけ時間か容量で等分して
それぞれエンコさせたファイルをつなぎ合わせた方が速そうな気がするけど、結局は>>106,115,209なの？
329:デフォルトの名無しさん
07/03/20 22:13:18
linuxでやれ。
330:デフォルトの名無しさん
07/03/21 15:28:42
やってみる価値は非常にありそうだな。
331:デフォルトの名無しさん
07/03/21 16:43:18
つなぎ目ってどうするんだろう
mpegでいうIフレームにすればいいだけ？
332:デフォルトの名無しさん
07/03/21 20:02:48
>>331
たぶんそうなんじゃない。
動画は前の画像の圧縮して解凍したものを使うから
ある程度の時間の動画をひとつのスレッドにしたほうが
効果ある上に作るのがとても楽だね。
333:デフォルトの名無しさん
07/03/21 21:17:47
キャッシュ効率が下がるんじゃない？
334:デフォルトの名無しさん
07/03/21 21:47:44
下がるだろうね。
キャッシュ重視で1枚の画像を複数のスレッドでMPEG圧縮する。
手間かける余裕があるかどうか。
CPUのマルチコア化を一般ユーザが使うようになるころは
メモリとかHDDの性能はどうなるのかしら。
335:デフォルトの名無しさん
07/03/21 22:43:12
エンコードに必要なワーキングセットをＮとすると
総キャッシュ量/Nより多いスレッド数でやると効率下がるだけやね
・・・そこまでやるか？
336:デフォルトの名無しさん
07/03/22 03:49:20
ここだと一般論を装った妄想でお茶を濁されがちだから
Core2限定の専用スレ立てていい？
337:デフォルトの名無しさん
07/03/22 11:25:18
ダンゴ様の許可があればいい
338:デフォルトの名無しさん
07/03/22 14:28:33
>>336
Xeonは除外?
339:デフォルトの名無しさん
07/03/23 02:25:42
>>336
どんな話がどう濁されているのか具体的に。
そもそも過疎ってるんだしスレを良い方向に変えていくのも一つ。
>>338
XeonもCore2ファミリじゃね?
340:デフォルトの名無しさん
07/03/23 02:55:13
初期のXeonもCore2だっけ?
341:デフォルトの名無しさん
07/03/23 03:15:39
ダンゴ的にはどうよ？
342:デフォルトの名無しさん
07/03/29 00:56:14
結局は高クロックのシングルコアが速い？
343:デフォルトの名無しさん
07/03/29 04:29:47
それができないからthe free lunch is overなのでは？
344:デフォルトの名無しさん
07/03/29 20:44:06
Core2は使うレジスタ数を減らせば速いとかどっかで見たんですが
どういうことでしょうか
Pen3やNetBurst系とは逆？
345:デフォルトの名無しさん
07/03/30 00:00:33
この質問はダンゴじゃないとマトモに返答できないと見た
346:・∀・）っ-○◎●
07/03/30 01:52:36
.
347:デフォルトの名無しさん
07/03/30 03:33:19
32bitモード、つまり
増えたレジスタを活かさないモードなら速い、ということなら
皆知ってるけどね。
348:デフォルトの名無しさん
07/03/30 22:22:50
人間活動 → スカラ
自然現象 → ベクトル
中途半端 → 今のCMP全般
349:デフォルトの名無しさん
07/04/03 09:13:21
＿＿＿_
／⌒ ⌒＼ ﾎｼﾞﾎｼﾞ
／（ ●） （●）＼
／::::::⌒（__人__）⌒::::: ＼ ＜で？
| ｍj |ー'´ |
＼ 〈＿_ﾉ ／
ノ ﾉ
350:デフォルトの名無しさん
07/04/03 19:26:14
おちんぽ
351:デフォルトの名無しさん
07/04/13 21:20:44
結局、下手に最適化せずに、単純なバイナリで、プロセッサに条件予測させた方が速いってことか。
352:デフォルトの名無しさん
07/04/15 03:08:29
既出かもしれんけど
URLﾘﾝｸ(cag.csail.mit.edu)
353:デフォルトの名無しさん
07/05/06 00:35:15
JCSPの話はここでいいのか？
354:デフォルトの名無しさん
07/05/06 02:41:23
良いんじゃない。
Java 固有の質問だったら Java のスレでやった方が良いかもしれないけどね。
355:デフォルトの名無しさん
07/06/03 02:01:31
保守
356:デフォルトの名無しさん
07/06/03 15:31:56
逐次処理を並列処理に分割する手法で代表的なものって何？
357:デフォルトの名無しさん
07/06/03 15:33:02
OpenMP とか関数型言語で書き直すとか？
358:デフォルトの名無しさん
07/06/03 15:41:12
>>356
OpenMP、pthread、MPI 辺りですかね。
# SMP 環境でわざわざ MPI する人も少ないかもしれませんが。
ちなみに性能的には MPI > pthread > OpenMP、
お手軽さでは OpenMP > pthread > MPI の順でしょうか。
359:デフォルトの名無しさん
07/06/03 16:43:38
>>358
>ちなみに性能的には MPI > pthread > OpenMP、
ええっ!? SMP環境でMPIってpthreadより性能いいの?
360:デフォルトの名無しさん
07/06/03 17:47:44
OpenMP、pthread、MPI ってどこにあるの？
361:デフォルトの名無しさん
07/06/03 18:15:19
一番星を右に進んだ所、虹の彼方に
362:デフォルトの名無しさん
07/06/04 19:05:59
ジョブを並列に分割する際に、何に注目して並列化すればよいのでしょう？
データですか？タスクですか？
363:デフォルトの名無しさん
07/06/04 19:20:07
適材適所。
364:デフォルトの名無しさん
07/06/04 19:22:08
栄枯盛衰
365:デフォルトの名無しさん
07/06/06 00:22:34
>>359
MPIは複数の計算ノード（例えばPCとか）を高速な通信回線で接続した
HPCクラスタ用ですね。
pthreadは共有メモリシステムじゃないと使えないので、CPUの数を増や
してもいくつかの理由（メモリアクセスの集中やキャッシュコヒーレンシ
維持のためのオーバーヘッド増加）のために、システム全体の性能はある
程度で飽和してします。大体 CPU 8〜16 個くらいが限界でしょうか。
クラスタシステムではCPUだけではなくメモリも分散配置しているので、
うまく仕事を複数のノードに配分するようにプログラムを作ることがで
きれば、もっとCPUを増やしてもシステム性能を向上させることができ
ます。
# でもそのソフトを作ったりデバッグするのが大変なので、MPIは暇な
# 学生が使える教育機関でしか人気が無いような気がする…。
366:デフォルトの名無しさん
07/06/06 13:37:00
>>365
MPIが性能を十分に発揮するのは「高速な通信回線で接続したHPCクラスタ」での話ですよね
>>358
># SMP 環境でわざわざ MPI する人も少ないかもしれませんが。
>
>ちなみに性能的には MPI > pthread > OpenMP、
>お手軽さでは OpenMP > pthread > MPI の順でしょうか。
「SMP 環境でわざわざ MPI」してpthreadより性能を発揮する場面ってあるんでしょうか?
あるいは下から2行目の「MPI」っつてるのは「高速な通信回線で接続したHPCクラスタ」が前提と読むべきなんですかね?
367:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/06/07 23:03:08
>>367
>SMPだけどNUMAなアーキテクチャ
これは定義矛盾
Opteron は NUMA
NUMA への最適化は最近のカーネルなら大抵入ってるよ
369:デフォルトの名無しさん
07/06/07 23:13:02
>>367
もまいはこれよめ
URLﾘﾝｸ(www.amd.com)
370:デフォルトの名無しさん
07/06/15 00:05:56
これってどう？
URLﾘﾝｸ(www.rbbtoday.com)
371:デフォルトの名無しさん
07/06/15 00:10:53
機械語レベルで、並列化すんだろな
能書きは本当か知らんけど発想はありだな
372:デフォルトの名無しさん
07/06/15 00:13:22
>>370
URLﾘﾝｸ(www.nec.co.jp)
これのことか？
373:デフォルトの名無しさん
07/06/15 06:55:05
何を並列化するかによるわな。
マンデルブロ集合の計算とか、完全に並列化できるものなら、そらN台でN倍に
なるだろうけど、そんな簡単な用途は極めてまれなわけで。
宣伝の一人歩きだろう。
374:デフォルトの名無しさん
07/06/15 07:46:05
＞極めてまれ
そうでもない。
処理はシンプルでも大量に捌かないといけない場合はままある。
#尤も、そういうケースは並列化の自動化も難しいが。
375:デフォルトの名無しさん
07/06/16 01:44:51
んなこたあねえべさ。
むしろ順次処理じゃないといけない場面の方が少ないんじゃねぇかな？
376:デフォルトの名無しさん
07/06/16 02:10:48
画像処理とオンライン系のトランザクションは並列化に向いてる処理が多いって
よくいわれるよね。××ルータ、××フィルタ、××サーバと名前に付くアプリは
並列化してナンボな物が多い。
デスクトップアプリは 4 コアもあれば十分だと思うけど。
377:デフォルトの名無しさん
07/06/16 11:53:25
大規模マルチコアプロセッサの発売に向け準備を進めるインテル
URLﾘﾝｸ(japan.cnet.com)
IntelのTera-Scale Computing Research Program担当共同ディレクタ
ーJerry Bautista氏によると、現在、Intelの研究者らは、コンピュータ
メーカーやソフトウェア開発者らが、大量のコアを搭載するマルチコア
チップにより簡単に適応できるようにするため、それらのチップの複雑
な機能性を意識させないための手段を模索しているという。
異種マルチコアチップ内のすべてのコアを外骨格のようなもので覆い、
それらすべてのコアを複数の従来型x86コア、あるいは1個の大きなコア
に見立てる。Bautista氏は、「それは、いわば1つのリソース貯蔵庫のよ
うになり、ランタイムがその中から適当と思うものを使用する」と述べ、
「これはプログラミングを簡略化するためだ」と付け加えた。
1個のチップ内の多様なコア間で演算タスクを分配するハードウェアスケ
ジューラを使用することにより、特定の演算タスクをより短時間で完了
できるとBautista氏は指摘する。
プログラマーたちは、キャッシュ共有技術やハードウェアスケジューリング
技術を理解したり、これに対応するためにたくさんの労力をつぎ込む必要
はない。これらのオペレーションは大抵、チップ自体によって処理される
ため表面化しないのである。
378:デフォルトの名無しさん
07/06/16 16:38:55
>>377
素晴らしい！！
テクノロジーの進化ってとんでもねぇなｗ
379:デフォルトの名無しさん
07/06/16 22:47:24
Windows出たばかりの頃の宣伝の様だが
380:デフォルトの名無しさん
07/06/16 22:56:25
まあイソテルの「プログラミングの簡略化」の範囲はアプリ屋の話で、
コンパイラ屋ガンガレ、死ぬまでガンガレ by Intel
って漏れの耳には聞こえてるが気のせい？
381:デフォルトの名無しさん
07/06/16 23:05:49
>>380
そういうのは NetBurst や Itanic で懲りていると思いたい…
382:デフォルトの名無しさん
07/06/16 23:42:46
>380
俺にはIntel以外のコンパイラは淘汰されてしまえ
と聞こえるが
383:デフォルトの名無しさん
07/06/16 23:54:34
ARM、gcc、VC++でつかえなけりゃいみねぇー
世の中ICCが全てみたいな発想がすかん
INTELはいっつもAMDいじめて悦に浸ってる変態だし
しねってかんじだ
384:デフォルトの名無しさん
07/06/17 00:13:12
そらそうよ、Intelはパラノイアが社訓だもん
385:デフォルトの名無しさん
07/06/17 01:16:16
いよいよAMDの時代
URLﾘﾝｸ(northwood.blog60.fc2.com)
URLﾘﾝｸ(northwood.blog60.fc2.com)
URLﾘﾝｸ(northwood.blog60.fc2.com)
URLﾘﾝｸ(blog.livedoor.jp)
386:デフォルトの名無しさん
07/06/17 01:23:55
Intel社、ソフトウエアの並列化が研究開発部門の最重要課題に
URLﾘﾝｸ(www.eetimes.jp)
マルチコア・プロセッサに対する需要の高まりを受け、米Intel社はソフトウエア
の並列化を最重要課題に掲げている。その取り組みの一環として、特定用途
向けプログラミング言語や既存のプログラミング言語/アプリケーションの並列化
に関する研究に250名を投入している。「オレゴン州にある研究開発部門では、
全業務の実に約3/4をソフトウエア関連が占める」
インテルが開発ツールの新版を発売、ソフトウエアの並列化を支援
URLﾘﾝｸ(www.eetimes.jp)
コンパイラは、ベクトル化が可能な場合、SSE命令セットを利用したコードを
生成する。また、C++のテンプレート・ライブラリとして実装されているTBBを
利用すると、ソフトウエア開発者が明示的にコードを記述しなくても、マルチ
スレッド化できる。OpenMPライブラリを利用しており、実行時に利用可能な
コア数分だけスレッドを生成する。
387:デフォルトの名無しさん
07/06/17 15:02:51
AMDは甘ちゃん
IBMとIntelはプロフェッショナル
388:デフォルトの名無しさん
07/06/18 01:10:40
次世代スパコンはスカラーとベクトルの複合型に，日立/NEC/富士通の「3社連合」で開発へ
URLﾘﾝｸ(techon.nikkeibp.co.jp)
アーキテクチャの概要は，スカラー型プロセサからなる演算システムにアクセ
ラレータを付加し，さらにベクトル型プロセサからなる演算システムを組み合わ
せる，というもの。スカラー部とベクトル部は，共有ファイル・システムを介して
データをやり取りする。これによって様々な大規模計算シミュレーションが計算
のタイプに合わせた演算環境を選べるようになる。
ハードウエアだけでなく，ソフトウエアも同時に開発する。「制御フロントエンド」
のジョブ管理を通して，ユーザーはこれら二つのシステムの違いを意識せずに
最適な演算環境を選べるようにするという。
389:デフォルトの名無しさん
07/06/18 06:50:59
>>384
コンピュータ様って事ですね？市民。
390:デフォルトの名無しさん
07/06/18 23:42:06
もうすぐメニーコアがでてくるらしい。
システム設計とかどうすりゃいいんだか・・・
URLﾘﾝｸ(pc.watch.impress.co.jp)
391:デフォルトの名無しさん
07/06/18 23:46:07
いつも通り、頭のいい人が仕組みを考えて、俺らがそれに乗っかって儲ける
で良いんじゃないかな。頭のいい人の代わりを務めようとすると大変だけど。
392:デフォルトの名無しさん
07/06/18 23:51:36
シーケンス図廃止からやってみようかな？
で、その代わりに何を使えばいい？？
393:デフォルトの名無しさん
07/06/19 18:18:04
並列システム用のモデリングviewをUMLに策定してくれんかな。
394:・∀・）っ-○◎●
07/06/20 00:23:28
あのさー
マルチコアに限らずソフトの最適化なんて、現場レベルでボトルネック分析し
どこを重点的に並列化するか設計フェイズにフィードバックしながらやっていくもんで
日本伝統のウォーターフォールモデルじゃ、いくらお絵かきツールが便利になっても
全然役に立たんよ。
むしろUMLの本質は抽象化なんでそもそもマルチコアを意識する必要ねぇ。
逆に具体化しちゃうと、コア数の増減やパフォーマンスの見積もり違いで破綻する希ガス。
マルチスレッドは一般的にはObserverパターン、と本で得た知識をそのまま晒してみる。
URLﾘﾝｸ(www.hyuki.com)
それにしても結城先生お茶目だな。
395:デフォルトの名無しさん
07/06/20 00:28:27
さてと、、、
396:デフォルトの名無しさん
07/06/20 16:51:08
Cellスレでボコボコにされて
泣く泣くこちらのスレに逃げてきた団子が
ご迷惑をおかけしております。
397:・∀・）っ-○◎●
07/06/20 22:12:33
ゲハ厨自演乙
398:デフォルトの名無しさん
07/06/21 00:00:47
>>396
バカかお前ｗｗｗ
何も知らないんだなｗｗｗｗｗ
ム板で厨認定された糞団子が帰る場所は
学歴とゲハだよｗｗｗｗｗｗｗｗ
399:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/06/21 22:38:31
簡単なファイルコンバート処理(ファイル読み込み→変換→ファイル出力)を並列化したいんだけど、定番のパターンとか定石ってある？
自分で調べた感じだとProducer-Consumerパターンが使えそうなんだけど・・・。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5385日前に更新/215 KB
担当:undef