06/01/23 22:00:41
>>111
話の流れがわからん
113:デフォルトの名無しさん
06/01/23 22:01:05
>>103
NeoMagic の MiMagic6 なんかがその路線で、16x16ピクセルの画像を
対象とした演算なんかを1命令でできる演算ユニットを積んでます。
中～大規模SIMDってのも、応用範囲は限られるものの確かに面白い。
けれどもクロック上げて水で冷やしてガンガンパワー使えるなら不要な
手法なのかなという気もしないでもない・・・
小さいモノの中ではダイナミック・リコンフィギュアラブルLSIとかが
そういう思想のもののような気がするけど違うかもしれない。
114:デフォルトの名無しさん
06/01/23 22:06:50
>>112
つまり、10個のコアがある場合に10個演算する場合は、10個スレッドを立ち上げて、
10個同時に演算して、演算が終われば元のスレッドに戻せば、10倍の速度で演算できるのでは？
って事。
115:デフォルトの名無しさん
06/01/23 22:14:20
>>114
しかしバス幅とバスクロックの壁は、非情なまでにも分厚かった
116:デフォルトの名無しさん
06/01/23 22:15:56
>>114
それふつうにマルチコアの利点
今後はどの点が並列処理できるかという設計レベルの重要性がますわけだ
今まではそのCPUにあわせてどうすれば少ない時間で処理できるかの最適化をする
という点だったからね
JavaのコンカレントAPIみたいなのが普及せんときついかもね
117:デフォルトの名無しさん
06/01/23 22:19:09
>>114
俺が言いたいのは、SIMDは局所的な並列で、マルチスレッドはもっと大域的ってこと。
MMXは隣接ピクセル間の並列性、マルチスレッドはブロックごとに区切るような
（マルチレンダリング）用途でしょう。俺なら同時に使うけどね。どっちかが
肩代わりするもんじゃない。
118:デフォルトの名無しさん
06/01/23 22:54:48
関連スレ追加
ｽﾚﾘﾝｸ(tech板)
119:デフォルトの名無しさん
06/01/24 01:34:42
>>117
スレッドのというか処理の粒度の問題って解くべき問題との関係が深すぎるからこのスレのタイトルだと混乱するかもしれない。
120:デフォルトの名無しさん
06/01/24 02:24:55
スレッドとマルチコアは何の関係もないだろ。
121:デフォルトの名無しさん
06/01/24 03:39:30
マルチプロセッサ(SMT含)を想定してのマルチスレッドプログラミングと全く同じだもんな。
プロセッサ間の通信速度や、外部(メモリ)との通信速度が違う、というだけで。
122:デフォルトの名無しさん
06/01/24 04:37:07
>>109
つまり技術的にはインドに負けることが前提なわけですな。
123:デフォルトの名無しさん
06/01/24 11:46:28
マルチコアのマルチスレッドって、通常のマルチプロセッサに比べて
注意するところあんの？ ハイパースレッドプロセッサだったら
スピンロック問題とか言うのがあった気はするけど。
124:デフォルトの名無しさん
06/01/24 12:57:29
>>86
自作板のあれは、多くの場合、負け惜しみです。
体感速度が云々と言ってる人達は、遅いCPUをdualにしています。
本当にCPU速度が必要な人達は、
マルチスレッドで動くアプリを使っていて、
ユーザの操作のためにCPUが丸々1個アイドルで待機しているのでレスポンスが良い
なんてことにはならないのです。
125:デフォルトの名無しさん
06/01/24 12:59:39
>>102
ゲームはCPUを他のスレッドに譲るという概念がないから。
ビジーウェイトとか平気でやるからな、ゲームプログラマは。
126:デフォルトの名無しさん
06/01/24 13:00:32
>>107
並列演算を行った上で、
さらに、
マルチスレッドですよ。
127:デフォルトの名無しさん
06/01/24 13:58:16
できるやつは新しいのが出てきてもいい物を作る
できないやつは昔からの作り方にこだわり進歩しない
ゲーム製作スレのオブジェクト指向いらねという話と似てる
128:デフォルトの名無しさん
06/01/24 14:03:03
>>125
そんなアホはさすがに居ない。
、、と思いたいが、居る所には居るのか。
129:デフォルトの名無しさん
06/01/24 14:41:26
>>127
君みたいなのをみるとイライラする。
みんなマルチコア、マルチコアいっているけど、はっきりいって現状、中身がないって
いっているつもりなんだけど。マルチコアの性能を生かした設計というのは難しいし、
まだそれは誰も解決していない。それを簡単だというならそれをちゃんとわかるように
それをどうやって解決したか書いてくれ。ここはそれを解決するためにみんなで考えま
しょうっていうスレだ。
マルチコアをマンセーするのとその技術をマスターするのは、天と地ほど差があるよ。
マンセーするだけでマスターした気になっているのは中身が無い。
もうちょっと真剣に技術に対して考えてくれ。
130:デフォルトの名無しさん
06/01/24 15:03:11
>>129
>はっきりいって現状、中身がないって
>いっているつもりなんだけど。
これって「一般人の使うデスクトップに関しては」って事かな。
範囲を限定しないと、議論にならないと思われ。
131:129
06/01/24 15:06:14
>>130
最初から使い道がはっきりしているHPCやサーバ用途を除いては、です。
適確なつっこみスンマソン。
132:デフォルトの名無しさん
06/01/24 15:11:56
>>125
ジャンルにもよるが、ゲームってのは譲り合いの最たる分野だよ。
処理落ちと戦うアプリが他にどれほどあると思う。ただ他のプロセス
のことを考えるのはPCやらんとわかりにくいね。
133:デフォルトの名無しさん
06/01/24 15:23:10
あと、ユーザの立場からデュアルコアまではメリットがあるといのも了解事項?
デュアルコアのメリットはスループットとレスポンスタイムを両立出来る事。
裏で重い処理を走らせていても（要スループット）、表の処理のレイテンシを
少なく出来る（要レスポンスタイム）。裏の処理の例としては、ダウンロード、
スパムフィルタリング、エンコード、ウィルススキャン等。表の処理の例としては
GUI 描画等。今時のウェブブラウザとかは既にマルチスレッド化されているし。
その上で、プログラマの立場から、メニー／マルチコアのメリットを最大限に
活かせる様な設計とは何かという事だよね?
134:127
06/01/24 15:36:32
>>129
PCがまた売れるようになってきた原因がいわゆるTVつきでキャプチャとか出来るパソコンなわけだが
これらはデュアルコアの恩恵が非常に大きい
コンシューマレベルでも十分恩恵受けてると思う
それにゲームでもマルチスレッドを使うことによって、プログラムがより簡単になるとかあるんだよ
とりあえず4コアまでならコンシューマレベルでもかなり恩恵は出るとおもうけど
8コア以降は俺はしらね
135:デフォルトの名無しさん
06/01/24 16:14:17
>>134
>プログラムがより簡単になるとかあるんだよ
例えば?
ネットワーク回りを別スレッドにするとか、そういうの?
136:デフォルトの名無しさん
06/01/24 16:41:52
>>135
そういうこと
サウンド回りにしてもね
シンプルになるよ
137:デフォルトの名無しさん
06/01/24 16:45:51
>>136
その辺はシングルプロセッサでも別スレッドだべ？
138:デフォルトの名無しさん
06/01/24 16:46:55
サウンドやネットワーク周りをメインスレッドで動かすのはちっと
考えられん。
139:138
06/01/24 16:49:06
昔のゲーム機でサウンドをVSyncで処理している事例はあるにはあったけどね
140:デフォルトの名無しさん
06/01/24 17:41:23
>>137
だね
BGMにしろ通常圧縮フォーマットからそれをPCMデータへ展開、キューに突っ込む
キューから取り出してデバイスへ転送
の2スレッド構造にすれば非常にシンプル
効果音にしても別スレッドでキューからのコマンドを下に転送支持とか
まぁマルチコアになって楽できるべ
>>139
つーか割り込み使ってる時点で別スレッドと同じような動きだろう
141:デフォルトの名無しさん
06/01/24 17:43:26
やっぱり、プログラム板的にはマルチコアだからって何ら特別なことは
なく、マルチスレッドでプログラムを書けばよい、でOK？
142:デフォルトの名無しさん
06/01/24 17:53:46
>>140
＞の2スレッド構造にすれば非常にシンプル
分けると同期が逆に面倒な気がする。読み込む部分が
ネットワークからのストリーミングだったらおっしゃるように
二段構えになるけど、それはネットワークのレスポンスが
タイミング違いすぎるから。
＞つーか割り込み使ってる時点で別スレッドと同じ
ぜんぜん違う。サウンドプログラムは中でループ回す
構造にできない。サウンドプログラムもイベント駆動型
にする必要ある。
とはいえ大違いでも、大差ないと言えば大差ないが。
143:デフォルトの名無しさん
06/01/24 17:54:32
>>141
それじゃあ話がおわっちまうが確かにその通りじゃね
144:デフォルトの名無しさん
06/01/24 18:05:43
>>142
だから同期のライブラリが充実している高級言語が有利なんだよ
そもそもスレッドだってループするように作ってなくていいわけで
145:デフォルトの名無しさん
06/01/24 18:26:39
>>144
高級言語という話の流れはどこから？
＞そもそもスレッドだってループするように作ってなくていい
ループしないってことは割り込みみたいに毎度毎度スレッドを
生成するのか？ そんな馬鹿なことしてるとは思えないから
一度生まれたスレッドを殺さずに使い続けるのは何かしら中で
ループしてるってことだろ？
146:デフォルトの名無しさん
06/01/24 18:30:12
>>145
スレッドプールとかあるし、ユーザーは意識させないよ
高級言語ってのは上のほうででてたJavaとか.NETとかそういうレベルの話
GCの大幅な速度上昇とふくめて有利に働くことが多い
Cとかでシングルスレッドでガリガリにチューニングしたアプリより
マルチスレッド使って適当にのほほんと書くアプリのほうが早いとか
わりと普通だからな
147:デフォルトの名無しさん
06/01/24 18:35:55
んな細かいことはどーでもいいから、
読み書き速くするとか、読み書き中にゲーム続行できるようにしといてくれ。
148:デフォルトの名無しさん
06/01/24 18:43:20
そりゃプロセッサが複数あればそうだろう。依存関係のない部分
は簡単に並列化できるからね。
あと、スレッド内でループしない構造にするメリットってある？
記述は明らかにイベント駆動より簡単なのに。
149:デフォルトの名無しさん
06/01/24 18:46:15
>>147
ごめん、難しいんだ（笑） まあ、非同期読み込みは
サポートするようにはしてるよ。でもこの辺はマルチ
プロセッサでなくても恩恵受けるところだね。一方が
極端に遅いデバイスを扱う場合は特に。
150:デフォルトの名無しさん
06/01/24 18:47:18
>>148
スレッド数をスレッドプールでコントロールする場合ループさせないほうがいい
151:デフォルトの名無しさん
06/01/24 18:51:41
スレッドプールってサーバなんかのトランザクション処理以外にも使うんだ?
どんな用途で使ってるの?
152:デフォルトの名無しさん
06/01/24 18:56:57
スレッドプールはイベント駆動との中間みたいなもんか。
中で滞るものがあってもある程度緩衝材になるってのが
シングルスレッドの純なイベント駆動に対するメリット？
同時に資源の消費しすぎを抑えられるってことね。
153:デフォルトの名無しさん
06/01/24 19:00:38
イベントディスパッチの代わりにプールからスレッドを起動するのか。何か重そうな。
154:デフォルトの名無しさん
06/01/24 19:11:53
例えば、Winsock2系で(非標準だけど)最速といわれているIOCPは
スレッドプールを利用した仕組みだよ。
155:デフォルトの名無しさん
06/01/24 19:17:25
>>151
プールに既にあるから起動しなくて良い。ので高速。
現状のシングルスレッドでのイベントディスパッチャが、
スレッド数１のスレッドプールに相当します。
例えば10,000程度の物をアレコレ処理するとき、
10,000個スレッドを作らずに、論理CPU数x2程度の
スレッドに効率よく処理を分散できるとか。
156:デフォルトの名無しさん
06/01/24 19:23:45
ふぅん、面白そうだね。ちょっと調べて実装してみたいな。
ｻﾝｸｽ。
157:デフォルトの名無しさん
06/01/24 19:45:30
とはいえ話にあったBGMにはスレッドプールは向かないんじゃね？
詰まっていて鳴らせませんじゃすまないし。
158:デフォルトの名無しさん
06/01/24 19:54:09
元々リニアにスケールする処理→スレッドプール
特殊な処理をメインスレッドから外出ししたい→普通にスレッド作る
...なんじゃないの。
159:デフォルトの名無しさん
06/01/24 20:09:39
スレッドプールはシングルスレッドでもいいんだけどマルチプロセッサ
に不可分散させたい時に便利だってことかー？
160:デフォルトの名無しさん
06/01/24 20:14:23
簡単に別スレッド使える構文が欲しい。C++では何度も導入の
意見が出て却下され続けてるそうだが、
make_thread for(i=0; i<100; i++){
hogrhoge....;
}
って書いたら勝手にスレッド作ってメインは続行、for内は
独立したスレッドで動き出すみなたいな。
CreateThreadしたりオブジェクト作ったりﾏﾝﾄﾞｸｾ
161:デフォルトの名無しさん
06/01/24 20:18:40
現状のsmpのままだとメモリのボトルネックがもっとひどい事にならない？
コア数が増えるとクロスバースイッチとか導入するＰＣも出るのかな？
162:デフォルトの名無しさん
06/01/24 20:21:31
>>159
シングルコア･シングルプロセッサの場合でも、
とあるスレッドがI/Oで待たされてる間に他のスレッドで
他の処理ができる（かもしれない）、という普通のマルチ
スレッドの利点も提供される。
イベントやトランザクションを処理するのに用いる。
スレッドは、1粒度の処理を行ったらプールに戻って
次に利用されるまでイベント待ちなどで待機する。
ずーっと続くセッションみたいなものの処理には無意味。
普通は>>155の「論理CPU数x2」とかよりもっと多くのスレッドを使う。
163:デフォルトの名無しさん
06/01/24 20:22:31
>>160
スレッド生成クラスとラムダで事足りるからじゃないの？
make_thread終了の同期とる方法をOSから隠蔽する方が面倒くさそうだし。
164:デフォルトの名無しさん
06/01/24 20:33:48
＞スレッド生成クラスとラムダ
それなあに？
165:デフォルトの名無しさん
06/01/24 20:36:15
どっちかっていうと閉包欲しいよ閉包。
ちょっとスレッドとかにも便利だよ。
166:デフォルトの名無しさん
06/01/24 20:50:57
make_thread foo();
ってやったら別スレッドで関数起動してくれるのが欲しい。
167:デフォルトの名無しさん
06/01/24 20:52:28
URLﾘﾝｸ(216.55.183.63)
168:デフォルトの名無しさん
06/01/24 20:55:31
BGMの補充に関してはいわゆるブロッキングキューでいい
充填する側はキューサイズがいっぱいだとキューがあくまで待つ
そして取り出す側はキューが取り出せる状態になるまで待つ
取り出す側が待つようだと音が途切れてるので意味はないけど、
充填する側をキューサイズでコントロールできるとバッファのサイズを
コントロールしたり自前でリングバッファ持ったり待機させたりとか
面倒なことはしないですむ
ロジックだけに集中できるってことだーね
こういうのをJavaとかは用意してる
ほかにもカウントダウンラッチとかサイケリックバリアとか優先度つきキューとかもある
もうロック処理も優先順位つけたり細かく動けるようになったし
使い方は難しいがロックフリーでスレッドセーフのアトミックもある
ソフトに限らずハードも異なるクロックでキュー使うの普通だし
そういう考え方は必要だと思う
おいしいところは真似しないとな
169:デフォルトの名無しさん
06/01/24 20:59:42
で、まあ、今話題になっているような内容は
マルチコアとは直接関係無く
普通にマルチスレッド、或いはマルチプロセッサに関する話題でして。
↓以下ループ
170:デフォルトの名無しさん
06/01/24 21:33:12
一々、茶々入れんと気が済まんのか。御主は。
171:デフォルトの名無しさん
06/01/24 21:45:26
普通にマルチスレッドの話でいいんでないの？
スレの名前も並列化だけだし。
マルチコアが普及することによって・・・というだけでしょ。
172:デフォルトの名無しさん
06/01/24 21:52:45
あっちよりこっちが賑わってるのはスレタイの勝利ですか
173:デフォルトの名無しさん
06/01/24 21:58:02
>>172
あっちってOpenMPスレ？
174:デフォルトの名無しさん
06/01/24 22:14:53
マルチスレッドって名前付いてるスレ
175:デフォルトの名無しさん
06/01/24 22:25:37
まあ、賑わってるって言ったって、住人の顔ぶれは
ほとんど変わらないと思うけどな。
176:デフォルトの名無しさん
06/01/24 22:31:25
あっちはC＋Win32ベースでしかも基本的なところから先に進んでない
単純な排他制御だけではお話になりませぬ
ロジックとしてどういうのがいいかという話のレベルまでいってないんだよな
>>1とかみてもこっちのほうが広い目というかもっと上位の話題にみえる
マルチコアを生かすのに簡単なのがマルチスレッドってだけで
マルチスレッド以外で現実的な並列プログラミングの方法があれば・・・というところだろう
177:デフォルトの名無しさん
06/01/24 23:14:45
このスレッドの場合は極端な事を言い出しても、
まだまだ使い古されて無い技術だから叩きづらいんだよ
だから好き勝手に色々な事が言える
178:デフォルトの名無しさん
06/01/24 23:16:55
>>164
多分、どっかの誰かが作ったスクリプト言語だったと思う
179:デフォルトの名無しさん
06/01/24 23:19:21
まあ結局、並列化を効率よくやろうとすると、自前でスクリプト言語を作るか、
現時点で存在するスクリプト言語に頼るかの、二者択一になってくるんだよな
180:デフォルトの名無しさん
06/01/24 23:20:46
あるいは、同期機能を駆使してC++で作るとか・・・
181:デフォルトの名無しさん
06/01/24 23:23:25
でも、自前でスクリプト言語を作ったりすると、
わざわざマルチスレッドにする必然性が、
高速化以外には全く無くなったりする罠。ｗ
182:デフォルトの名無しさん
06/01/24 23:28:21
Javaもまあ、スクリプト言語の一種といえば一種か
183:デフォルトの名無しさん
06/01/24 23:36:41
>>160
一カ所のメモリーに対する多重アクセスを防ぐのが難しくなるからかと
184:デフォルトの名無しさん
06/01/24 23:36:58
>>178
Boost か何かのライブラリの機能でしょ。
185:デフォルトの名無しさん
06/01/24 23:38:03
>>179
スクリプト言語は、GC という並列化と相性が悪い物を抱え込む事になる。
186:デフォルトの名無しさん
06/01/24 23:38:23
何でマルチコアの話で「スクリプト言語」がでてくるんだ？
187:デフォルトの名無しさん
06/01/24 23:40:51
気にしちゃダメ
188:デフォルトの名無しさん
06/01/24 23:44:35
>>186
スレッドの管理が面倒だからかと
面倒な処理は、誰かが勝手にやってくれる方が楽だからな
189:デフォルトの名無しさん
06/01/25 00:15:33
>>160
Javaならすぐかけるのにね
190:デフォルトの名無しさん
06/01/25 00:31:21
そろそろC++も言語にスレッドを組み込んでしまって、何らかの
シンタックスシュガーが欲しいところ。
191:デフォルトの名無しさん
06/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:デフォルトの名無しさん
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パターンが使えそうなんだけど・・・。
401:デフォルトの名無しさん
07/06/23 18:29:29
UNIXのパイプ
402:デフォルトの名無しさん
07/06/24 23:14:58
フィックスターズが出している
URLﾘﾝｸ(www.shuwasystem.co.jp)
は、役に立つのだろうか？
立ち読みした限りでは内容がちと薄い気がするのだが。
403:デフォルトの名無しさん
07/06/26 16:17:27
>>402
それ持ってるけど、動くプログラムが書かれているだけで幸せ。
とりあえずコードを何回も書いて覚えている途中。
変な癖が付きそーだったら「違うよ」って教えてくれるとウレシイ。
404:デフォルトの名無しさん
07/06/26 20:43:30
そんなレベルの奴が並列化なんかに手を出すのが間違い
405:デフォルトの名無しさん
07/06/26 21:33:51
並列かなんてたいして技術いる事じゃないだろ
406:デフォルトの名無しさん
07/06/26 23:43:46
そういうやつが平気でぼけぼけかますのが並列化
407:デフォルトの名無しさん
07/06/26 23:46:28
科学計算レベルでの並列化と業務ソフトの並列化は同じレベルでは
語れないと思うんだが。そんな意味で入門には>>402はちょうどいい。
javaERの俺にはﾀﾞｸﾞﾘｰ先生の本のほうが面白かったけど。
408:デフォルトの名無しさん
07/06/26 23:48:17
>>406
一緒にするなよ
409:デフォルトの名無しさん
07/06/27 08:23:06
Amazonでの評価は微妙だね。
URLﾘﾝｸ(www.amazon.co.jp)
410:デフォルトの名無しさん
07/06/27 18:12:05
俺は釣られないぞ
411:デフォルトの名無しさん
07/06/29 01:44:41
なんでOpenMPばっか期待されてんの？
どこにもOpenMPなんて書いてないように見えるが（本のタイトルとかに）
412:デフォルトの名無しさん
07/06/29 01:46:42
デザインパターンの本。
↓
Javaについてはほとんどのってないので期待はずれ。
↓
デザインパターンの本、評価は微妙。
だれもJavaって言ってないじゃん…
413:デフォルトの名無しさん
07/06/29 13:17:14
たしかに目次にも一言もOpenMPの文字はないね。。。
よく分からん書評だ。
俺は↓の本で勉強したけど分かりやすかった。くどいくらいだけど。
Win32マルチスレッドプログラミング
URLﾘﾝｸ(www.amazon.co.jp)
414:デフォルトの名無しさん
07/07/06 09:47:57
URLﾘﾝｸ(www.ebjapan.com)
これってハードレベルで並列を実現したってこと？
415:デフォルトの名無しさん
07/07/06 12:21:00
>>414
説明読んでいたら、家政婦が私語を始めたり、殺人事件を目撃したりしてしまう展開が脳内を過ぎった。
416:デフォルトの名無しさん
07/07/07 21:55:50
業務レベルでの並列と、コードレベルでの並列って差があると思うのだが
対処方法ってどうなってるでしょうね？
417:デフォルトの名無しさん
07/07/07 22:04:37
>>415
FPGAのparallel random access machine/model
じゃねーのそれって？
しかし今回はそれを1個だけしか作れていないはず。
64個最大実装時（現在開発中）が現行CPUの100倍程度って事だな
まぁ、IntelとかにX86を32個とか載せた板作ってもらった方が
書きやすいと思われる。価格も現実的だし。
418:デフォルトの名無しさん
07/07/07 22:18:17
URLﾘﾝｸ(seisei.s8.xrea.com)
これはどうなんだろうね？
419:デフォルトの名無しさん
07/07/07 22:39:58
>>418
うさんくさすぎねーかw
これが全部実現できるならIPAとかに公募して金もらうはず。
なんか穴があるはずだ。実用上の
420:デフォルトの名無しさん
07/07/07 23:05:23
>>418
すげぇ、胡散臭すぎて読む気にもならないよ。
421:デフォルトの名無しさん
07/07/07 23:29:44
読んでみたが、xorの計算をマルチスレッドで演算するソフトなわけね。
速度が速くなるとは書いてないようだな。
で？
422:デフォルトの名無しさん
07/07/09 01:01:13
XORをまるちすれっど？
で？
423:デフォルトの名無しさん
07/07/10 10:41:52
オーバーヘッドが少ないとか、実行時効率が良くなるとかじゃないみたいね。
分かりやすい管理方式の提案？
で？
424:デフォルトの名無しさん
07/07/10 11:41:21
順序立てて処理する必要が無い部分はマルチスレッドで並列処理すれば蝶早く計算できる！
俺天才！！！
って事？ｗ
URL削るともっと胡散臭いｗ
425:デフォルトの名無しさん
07/07/10 15:18:46
えーと自家製単純インタプリタ(command)が
並列にできるところを並列化、
という感じ？
じゃなくてこれは単なる dish の簡単な使用例か。
URLﾘﾝｸ(www2.chem.nagoya-u.ac.jp)
426:デフォルトの名無しさん
07/07/11 22:20:15
>>424
やばい、ドキュメントDLで金とるよ的なページもある。
427:デフォルトの名無しさん
07/07/11 23:45:26
419です。
スマン、どうやらスレ汚しをしてしまったようだ。
削除依頼してくるわ。
428:デフォルトの名無しさん
07/07/12 00:01:42
ごめん、↑は418の間違いね
429:デフォルトの名無しさん
07/07/12 02:56:59
そりゃ潔癖すぎる
気楽にやろうぜ
430:デフォルトの名無しさん
07/07/17 07:17:14
クロック数が違うCPUでマルチコア作ってほしい。
200MGHくらいのCPUが30個くらいついていて、2G強のCPUが一個くらいのやつ。
タスクで重いやつを2Gのやつに振るとかの処理はOSなりPG任せにする仕組みで。
無理か？
431:デフォルトの名無しさん
07/07/17 09:33:39
200MGHってのがどんなCPUか知りませんが、やってできないことではありません。
まぁ殆ど、意味はないと思いますが。
432:デフォルトの名無しさん
07/07/17 11:49:26
メガドラか
433:デフォルトの名無しさん
07/07/17 12:32:41
200メガギガヘンリー
434:デフォルトの名無しさん
07/07/17 12:38:57
200万ギザエッチ
435:デフォルトの名無しさん
07/07/17 12:57:02
200マゾガチハーレム
436:デフォルトの名無しさん
07/07/17 21:41:58
ダンゴさんのレスが望まれるところだ
437:デフォルトの名無しさん
07/07/18 01:21:03
悪趣味だな。
438:・∀・）っ-○◎●
07/07/18 02:51:49
だーんごー
だーんごー
たーっぷりー
だーんごー
439:デフォルトの名無しさん
07/07/18 11:04:21
>>438
おいこら、「つぶつぶだんご」ってフレーズが頭ん中でリピートしちまったじゃないか。
440:デフォルトの名無しさん
07/07/18 21:12:27
>438
それ、たらこだろ？
441:デフォルトの名無しさん
07/07/18 23:45:04
キャッシュヒット率を多少改善するくらいしかやれることなんてないだろ
442:デフォルトの名無しさん
07/07/18 23:50:16
イチローの出番だわな
443:デフォルトの名無しさん
07/07/19 10:24:49
>>430
ヘテロなマルチコアならcellがあるじゃまいか
444:デフォルトの名無しさん
07/07/19 11:45:36
そうじゃなくてね、クロック数の低いコアを十数個のせて低コストのプロセス
なりスレッドを割り当てして、OSなどの重い処理専用のコアというふうにわけ
れば効率よくマルチプロセス・スレッドができると思ったのよ。
>200MGH
200MHと間違えたよorz
445:デフォルトの名無しさん
07/07/19 16:09:31
＞クロック数の低いコアを十数個のせて低コストのプロセスなりスレッドを割り当てして
重い処理をするコアが数パーセントの稼働率でその処理やればいいんじゃない？
あまった時間はクロックダウンして各種電源OFFしてればいいし。
ってのはともかくとして、キーボードやスイッチ、外部デバイスの監視みたいな
低速簡単タスクはPICとか使ってやってるシステムもあるよね。
446:デフォルトの名無しさん
07/07/19 16:19:17
どうやって低コストかどうかを判断するんだ。
アプリ自体にプロセス毎の振り分けフラッグでも付いてないと適切に割り当てられんし、
低コストならメインCPUでやっちゃってもすぐ終わるから問題ないとも言える。
その考え方ならCPUコア分割よりIOコストをうまく割り振ってどれだけCPUをビジーに保てるかを
考えたほうが建設的だと思う。
447:デフォルトの名無しさん
07/07/19 21:07:21
分散すれば仕事が早くなるってアホな幻想いだいてるから
間違った方向にいくんだよなぁ。
人も機械もどれだけパンクギリギリまで仕事詰め込めるかが命なのに
448:デフォルトの名無しさん
07/07/19 22:52:24
>分散すれば仕事が早くなるってアホな幻想
お前がアホなんだろｗ
449:デフォルトの名無しさん
07/07/19 23:32:58
無理なものは無理
450:デフォルトの名無しさん
07/07/20 00:00:15
つまり馬鹿に仕事を割り振る方法を考える時間があったら
自分でやった方が速いってことだな。
451:デフォルトの名無しさん
07/07/20 00:42:36
工場の単純労働者は1000人必要かもしれない
だからといって社長（＋役員）は20人もいらない
452:デフォルトの名無しさん
07/07/20 00:50:41
でもXeon20個搭載可能なマシンあったら
夢がひろがりんぐだろw
453:デフォルトの名無しさん
07/07/20 00:58:53
>>452
それなんていう暖房機具？
454:デフォルトの名無しさん
07/07/20 01:32:05
1UラックマウントのXeon*2搭載可能なサーバがあるから、10Uラックでいけるな。
暖房器具っつーか、騒音源だな。
455:デフォルトの名無しさん
07/07/20 02:00:49
今なら１U3台で済むよ
QuadXeon 6個＋ﾏﾏﾝ3枚でｵｹ
456:デフォルトの名無しさん
07/07/20 06:53:20
Xeon20個っていってるのに6個って、何考えているんだ?
まさか、Xeon20個ってコア数だとおもっているのか?
おめでたいな。
457:デフォルトの名無しさん
07/07/20 09:27:02
頭が4つもついてる役員は怖いです。
458:デフォルトの名無しさん
07/07/20 11:07:36
バスが飽和しそうです。
459:デフォルトの名無しさん
07/07/20 23:18:00
>>454-456
お前らブレードサーバも知らんのか？
6U で Xeon 20個 コア 80個ぐらいは積めるだろ。
460:デフォルトの名無しさん
07/07/24 21:52:02
URLﾘﾝｸ(japan.cnet.com)
461:デフォルトの名無しさん
07/07/25 00:49:04
GPL？
462:デフォルトの名無しさん
07/07/25 00:55:38
記事読んだ感じだと、例外付き GPL なんじゃないの
463:デフォルトの名無しさん
07/07/26 00:26:11
LGPLだなたしか。
でも実際これら使っても効果出る範囲狭いみたいだぞ。
464:デフォルトの名無しさん
07/08/04 20:15:15
タスク境界を自動で検出するTOOLないかね？
465:デフォルトの名無しさん
07/08/16 15:32:15
foobarなどで複数のエンコーダを使って処理速度を上げてるってやつがあるけど
よっぽどうまく設計しないとハードディスクへのアクセスがボトルネックとなるじゃね。
466:デフォルトの名無しさん
07/08/21 09:25:35
URLﾘﾝｸ(www.itmedia.co.jp)
467:デフォルトの名無しさん
07/08/21 16:40:31
>>465
どういう計算だよｗ
468:デフォルトの名無しさん
07/08/21 22:27:55
URLﾘﾝｸ(pc.watch.impress.co.jp)
469:デフォルトの名無しさん
07/08/22 13:13:48
URLﾘﾝｸ(www.atmarkit.co.jp)
470:デフォルトの名無しさん
07/08/23 22:07:23
URLﾘﾝｸ(pc.watch.impress.co.jp)
471:デフォルトの名無しさん
07/08/31 20:12:44
Wikiﾍﾟﾃﾞｨｱより
>また、Windows Vista Home Basicおよび同Home Premiumではマルチプロセッサには対応しておらず
マジか
472:デフォルトの名無しさん
07/08/31 20:16:45
>>471
そこでいうマルチプロセッサは、マルチソケットのことでマルチコアでは
ないことは理解してる？
473:デフォルトの名無しさん
07/08/31 20:26:13
一応理解している。
シングルコアをくっつけて作るデュアル環境と、ダイに複数コアをのっける
ものの違いだと認識している。
多分
474:デフォルトの名無しさん
07/08/31 20:40:22
XP HOMEもそうだったでしょ。
物理CPUに対応してるのは１個まで。
物理CPU１個ならコアが４個あっても大丈夫（のはず）
物理CPU２個はXP PROFESSIONALから。４個以上は知らない。
475:デフォルトの名無しさん
07/08/31 22:48:30
それは違うぞ。
476:デフォルトの名無しさん
07/08/31 23:02:14
じゃあどうなの
477:デフォルトの名無しさん
07/08/31 23:03:08
いや、自分でもよくわからないんだけどさ
478:デフォルトの名無しさん
07/09/01 00:01:00
>>473
ちがうよ。
マルチプロセッサってのは文字通り
マザボに CPU を複数のっけることだよ。
ハードディスクを 2 個繋げたり
メモリを 4 枚さすのと同じ。
479:デフォルトの名無しさん
07/09/01 00:20:57
URLﾘﾝｸ(www.atmarkit.co.jp)
Windows 2000 Server Advanced Server
最大SMP CPU数 4CPU 8CPU
URLﾘﾝｸ(win64xp.impress.co.jp)
Windows XP Professional Windows XP Professional x64 Edition
対応CPU数 2 2
URLﾘﾝｸ(q.hatena.ne.jp)
1.WindowsXP HomeEdition … 1 ソケット
2.WindowsXP ProfessionalEdition … 2 ソケット
3.WindowsVista HomePremiumEdition … 1 ソケット
4.WindowsVista BusinessEdition … 2 ソケット
5.WindowsVista UltimateEdition … 2 ソケット
6.WindowsServer2003 StandardEdition … 4 ソケット
コア数は４個だろうが８個だろうが全て認識するようです
480:デフォルトの名無しさん
07/09/01 08:45:16
コアが32個あるタスクメジャー見たなｗｗｗｗｗｗｗｗ
481:デフォルトの名無しさん
08/01/15 17:42:48
並列化・並列計算のスレってこの板には多分ここくらいしかないので、
ここで質問します。
太陽系の惑星の軌道を並列計算をするときに、
時刻tでの惑星の速度と位置のデータを
他のプロセスに渡して次の時刻(t+1)の速度と位置を計算させて、
全ての惑星の分を計算し終わったら次の時刻の計算を・・・
と繰り返す処理をPVM ＋ C言語で組んでいるのですが、
どうもデータの送受信部分のコーディングがうまくいきません。
繰り返し1回目はちゃんと結果が帰ってくるんけど、
2回目は送信はできるけど計算結果が帰ってこない、
というような状況になっております。
並列計算で繰り返し処理を行う場合は
データの送受信の処理はどのようにコーディングすればいいのでしょうか。
(作りかけのプログラムをどっかにうpしたほうがいいんですかね・・・？)
482:デフォルトの名無しさん
08/01/15 17:56:30
>>481
MPIのスレがあるぞ
483:デフォルトの名無しさん
08/01/16 19:20:30
>>482
そうなんですがMPI以外の話になっちゃうので
抵抗がありまして・・・
484:デフォルトの名無しさん
08/01/16 20:30:46
地球時間とか木星時間の一年周期で同期したらいいんじゃね
485:デフォルトの名無しさん
08/03/29 13:31:27
cygwin+gccだとどのような方法がありますか？
486:デフォルトの名無しさん
08/04/06 22:12:28
ない
487:デフォルトの名無しさん
08/04/07 12:52:16
lam-mpiならcygwinにインスコできた。
mpichもたぶんできる。
488:デフォルトの名無しさん
08/04/08 08:42:45
IntelのCt言語っててにはいるのかな？
489:デフォルトの名無しさん
08/04/21 23:13:24
「小飼弾のアルファギークに逢ってきた」っていう本に
Dave ThomasがErlangの本を書いているって書いてあったんだけど
詳細が分かる人いますか？
07年7月に出版予定とか書いてあったけど、どうもAmazonの洋書でそれらしいものがない。
490:デフォルトの名無しさん
08/04/21 23:14:06
すみません。
誤爆しました。
491:デフォルトの名無しさん
08/04/27 21:21:30
128bit レジスタ を 8 コアで SSE 拡張として繋げて、
1024bit のベクトルプロセッサとして使える。
、、、とかだったら面白くなりそうなんだけどな
492:デフォルトの名無しさん
08/04/28 13:11:09
>>491
どれかのプロセスがそれをやっている間他のプロセスが割りを食いそうだからやだ。
493:デフォルトの名無しさん
08/04/28 18:17:35
>>491
逆に並列性が下がりそう
494:デフォルトの名無しさん
08/04/28 21:44:59
素朴な疑問だけど、これからはメニーコアの時代、とかいうが、
コア間で「人月の神話」と同じ問題は発生しないのかえ
495:デフォルトの名無しさん
08/04/29 09:07:34
する。
496:デフォルトの名無しさん
08/04/29 11:53:18
つーか、大昔からのマルチプロセッシングの課題が
いかにリニアにスケールさせるか、です。
497:デフォルトの名無しさん
08/04/29 14:01:25
それじゃ漠然としすぎて無意味だよ
498:デフォルトの名無しさん
08/04/29 14:08:39
大昔からリニアにスケールさせるにはどうしたらいいかって話で
結局は個別対応になるから、一般論として本当に軽い話しかできない
古い記事だけどマルチコア、マルチスレッドで
どこらへんに苦労したかっていうのは書いてあるけどほとんど一般論
URLﾘﾝｸ(www.4gamer.net)
ＥｆｆｉｃｉｅｎｔC++も肝心の部分は結局言及できずにたいしたことは書いてなかった。
だから、個別の事例をまとめるしかないと思うが、そういう記述をできる人は
その筋で仕事してたりする人ぐらいだから記事としては出てこないだろうし
結局は本人の試行錯誤という。
499:デフォルトの名無しさん
08/04/29 14:28:00
>>497
知りたいことの的を絞ってくれればある程度話ができるよ。
500:デフォルトの名無しさん
08/05/10 13:46:08
mac osx ppc64 で tbb を使って遊んでみようと思ってます（当然シングルコアなので雰囲気だけ）
ところが、libtbb.dylibとlibtbbmalloc.dylib を入れてもリンクエラーが発生します。
自分でソースからビルドしてdylibを作り直してもダメ。
dylibの中をみてもそれらしいシンボル名がないようなんですが、どうすれば動くんでしょうか。
501:デフォルトの名無しさん
08/05/10 14:33:45
おおむね一年研究してみたが、マルチコア化でいちばん厄介なのは
1.どれだけスレッドセーフなコードを簡単に作れるか
2.どれだけスレッドセーフを意識しなくてもよくできるか
の二点にかかっている、これに伴って
スレッド化が問題を引き起こすのは、作る側、使う側の間で、仕様伝達がもつれてしまったり、
一旦スレッド化すると、非スレッドセーフに戻したり、逆に非スレッドセーフに作ったコードを簡単にスレッド化できない事で
オブジェクト指向で言えば、オブジェクト間の結合がスレッドによってむやみに強められてしまう点がまずい。
スレッドセーフは、メソッドにつけられる属性の一つとして機能するが、言語機構てきに簡単には取り付けられない。
なにしろ、何につていスレッドセーフかという問題もあって厄介だ。
逆のこの点を解消すれば、むしろ色々な物(IO同期処理等)が統合できて便利だと思った。
『やりたいことの記述と、どう実装するかの記述を分離する事』が最も重要だ。
>結局は個別対応になるから、一般論として本当に軽い話
初めて見た時は不可能そうに見えたが、一般論化しないかぎり成功しない、そしてそれは不可能でもないと思った。
逆に、タスクシステムなどという事をやっているうちは全くモノにならないという点も見えてきた。
一言でいえば、いかにサクッと書けるか書き換えられるか、同期が必要なデータが明白化できるかが、そのまま並列化の性能になってしまう。
並列化はパフォーマンスを求めるために使う技術だが、パフォーマンスを求ている内は使い物になりそうにない。
VBが、GUIのコードをあっさり書けるようして、実用的にしたように、マルチコア化も同様なものが必要でスケールとかは意識しても仕方がないと思った。
概念として重要そうなのは、C#やVBのLINQやHaskell等で実装されている遅延評価が使えそうだという点か。
502:デフォルトの名無しさん
08/05/10 15:17:55
CPU・・・衝突、不一致を嫌う設計
脳・・・衝突、不一致を積極的に利用
CPUの設計原理を変えずに、脳の真似をするのは難しい。
503:デフォルトの名無しさん
08/05/10 18:27:12
>>501
> 逆に、タスクシステムなどという事をやっているうちは全くモノにならないという点も見えてきた。
業務用ゲーム業界に職人技的に伝えられてきたというあの「タスクシステム」？
504:デフォルトの名無しさん
08/05/10 18:51:40
タスクシステムなんてこのＷＥＢ全盛時代にはもはや化石だなｗ
505:デフォルトの名無しさん
08/05/10 19:31:26
並列化のキーワードは網羅って聞いたことがあるような。
例えばソートだと、順列(全パターン)を作ってそれが並んでいるか調べるだけでいい。
現在の手法は今までのアルゴリズムを並列化しようとしているからロックとかで問題になっているんでしょ？
アルゴリズムを根本から変えれば良いと思うけど。
506:デフォルトの名無しさん
08/05/10 20:18:15
>>503
カプコンのMTフレームワークは使うかどうかはともかく、見ておく価値はあるよ。
URLﾘﾝｸ(watch.impress.co.jp)
十分とは思えないが、役に立たない理屈と違い実戦的な並列化手法の一つだから。
507:デフォルトの名無しさん
08/05/10 20:19:49
>>505
量子コンピュータ時代になれば、役に立つかもなw
508:デフォルトの名無しさん
08/05/10 21:15:20
>>507
ある程度コア数が大きくなったら役立ちそうだと思うけど
別に1パターン1コアに分けなくてもいいし。
509:デフォルトの名無しさん
08/05/10 21:59:00
>>508
> ある程度コア数が大きくなったら役立ちそうだと思うけど
算数からやり直した方がいいと思う。
510:デフォルトの名無しさん
08/05/10 23:18:15
>>508
たとえば1000の組み合わせの数を数えてみたらどうかな？
n qubitに対して、並列度が 2^n である量子コンピュータなら
2^1000程度の並列度を持たせれば、その組み合わせ数にも打ち勝てる可能性はあるが、
10個や20個のコアでなんとかなるかな？
511:デフォルトの名無しさん
08/05/10 23:58:22
あーかなり勘違いしてたよ。
でも、そこに道があるような気がする。
アルゴリズムが分かりやすいし。
512:デフォルトの名無しさん
08/05/12 07:51:09
>>511
極めて単純なものだけに有効でしかないよ
総列挙を行うと、ひとつ条件分岐が増えるごとに二倍になる。倍々ゲームだからな。
宇宙の全素粒子をトランジスタにしたって追いつかないほどの並列度がすぐに必要になる。
そして、総列挙以外の方法で解けない問題はNP問題といって、楽しい研究対象だ。
量子コンピュータは、時間的な並行宇宙が倍々ゲームで増えていくことを利用して、
自分たちが感知できない別の宇宙にコンピュータを配置する、
今配置すれば、処理を何工程か経ることによって未来の並行宇宙に倍々ゲームでマシンを配置できる。
これに一斉処理をさせれば、宇宙の全素粒子の冪乗に当たるような並列度が取れるので、解けることもある。
ただし、結果を得る方法がきわめて特殊なので、結局解けないケースが多い。
それにしても一番気になるのは計算機よりも並行宇宙そのものだ。
513:デフォルトの名無しさん
08/05/12 21:09:31
量子コンピュータを神秘視しすぎだろwww
514:デフォルトの名無しさん
08/05/13 09:02:31
>>513
逆に問うてみようか、並行宇宙でないとすると、ありゃ何処で計算されてるいんだ？
どうころんでも、どう解釈してもキモ過ぎだよ
515:デフォルトの名無しさん
08/05/13 09:15:37
量子の状態は重ね合わせで表されるような状態である。
それは量子というものの性質そのものであって、解釈なぞどうでもよい。
キモいと言えばキモい性質ではある。
516:デフォルトの名無しさん
08/05/14 03:50:53
並行宇宙ﾜﾛﾀ
517:デフォルトの名無しさん
08/05/16 06:37:49
並行宇宙ヤバイ
518:デフォルトの名無しさん
08/05/16 19:49:58
>>512マジキモイ
519:デフォルトの名無しさん
08/05/16 19:51:44
2XXX年のオリコン一位
「並列宇宙」
520:デフォルトの名無しさん
08/05/16 22:01:54
>>517-519 話についていけないなら泣いていい(笑)
はたしてテンソル積はどこまでも増やしてゆけるのか
量子コンピュータをみていると、現在の物理法則はどこまで正しいかどうか見ものだよ。
521:デフォルトの名無しさん
08/05/17 01:31:05
Erlangスレに進展があったよ。
どっかのいい人がホームページ作ってくれたみたい。
522:デフォルトの名無しさん
08/05/17 03:24:15
宗教の話は他でやってくれないか。
523:デフォルトの名無しさん
08/05/17 04:33:17
ミクロとマクロの視点を
ごっちゃにしているアホが騒いでいるだけ
524:デフォルトの名無しさん
08/05/17 05:23:47
>>520
量子コンピュータが量子力学の正しさを証明しても
並行宇宙解釈が主流になる事は無いと思われ
525:デフォルトの名無しさん
08/05/17 05:33:35
ここム板やで。
526:デフォルトの名無しさん
08/05/18 14:45:50
>>1
boinc環境を用意してねらーを煽る。
527:デフォルトの名無しさん
08/05/18 19:38:01
懐かしの宇宙ヤバイを思い出した。
528:デフォルトの名無しさん
08/05/29 23:59:57
ちょっと、細かい質問なんだが、
tbbの本３８ページに書いてある、粒度ってどういう意味なんでしょうか。
本書曰く「grainsize は、プロセッサーに分配する妥当なサイズのチャンクに割当てる反復回数」とあります。
たとえば、2コアのＣＰＵで１０００回のループのを並列処理するときに、grainsizeを５００にする、
４コアならgrainsizeを２５０にすることで、理想的にスケールするということなんでしょうか。
この本肝心なとこの訳が意味不明で困る。
ーーマルチコアで並列処理をスケールさせることをテーマにしたよいほんないでしょうか（TBBのもいい参考書だとおもいますけど。）。
529:デフォルトの名無しさん
08/05/30 00:11:11
>>528
その本持ってないから意味不明で困る。
処理を細かい粒に分けて並列処理をする。粒度は粒の大きさだ。粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ。
530:デフォルトの名無しさん
08/05/30 00:16:56
>この本肝心なとこの訳が意味不明で困る
文句言ってる暇があるなら原著嫁
531:デフォルトの名無しさん
08/05/30 09:09:33
>>529
>粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ
環境に応じて調整している間は現実性はないと思うな、ソフトの開発は時間との戦いだ、それができないと理想論で終わってしまう。
使える並列化にするには、コードがスマートになる粒度にハードウェアを調節しないと駄目だ。
それが不可能なら、VMなりを作ってそこで吸収できるような構造にする事が不可欠。
>>530
ツマンネー事いってないで必要な情報は全部書けよ、この自己完結野郎
532:デフォルトの名無しさん
08/05/30 09:31:16
>>531 の文書が変だとおもったのでちょっと修正
>粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ
環境に応じて調整している間は現実性はないと思うな。
使える並列化にするには、コードがスマートになる粒度にハードウェアを調節しないと駄目だ。
ソフトの開発は時間との戦いだ、それができないと理想論で終わってしまう。
それが不可能なら、VMなりを作ってそこで吸収できるような構造にする事が不可欠。
533:デフォルトの名無しさん
08/05/30 12:28:09
調整といっても、問い合わせたプロセッサ数で分割とか、100mS分くらいに分割するとか程度だろ。その程度のことで開発は時間との戦いとか理想論とかってｗ
534:デフォルトの名無しさん
08/05/30 13:41:29
>>533
ややこしいデッドロック問題とか、複数のマルチスレッドライブラリが組み合わさった状態とかまったく想定していないショボイ開発だけ見ているだろw
例えば、ライブラリが二つあるだけでも最優先で実行すべきコードが変化するんだぜ、囚人のジレンマって言ってな、個々ライブラリが最優先に実行してほしい物を最優先にすると、最低な結果になる事も結構あるんだぜ。
535:デフォルトの名無しさん
08/05/30 14:24:20
>>534
「複数のマルチスレッドライブラリが組み合わさった状態」
になったら「ショボイ開発」って思わなきゃダメだよ
536:デフォルトの名無しさん
08/05/30 15:42:06
10000行で完成する程度のコードしか組んだことないんだなw