トップページ⇒tech
987コメント322KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2006/01/18(水) 08:31:11
最近のCPUはマルチコアが技術トレンドになっています。

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

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

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

【関連スレ】
OpenMPプログラミング
http://pc8.2ch.net/test/read.cgi/tech/1102483474/l50
0002デフォルトの名無しさん2006/01/18(水) 08:38:30
乙
ネタ的には面白そうなネタだと思う
0003デフォルトの名無しさん2006/01/18(水) 08:42:20
マルチコアの場合、メモリーとのアクセスはどうなってるの？
バス幅やバスクロックは変わらないようにも思えるけれど・・・

マルチなバスがあって、マルチにメモリーにアクセスしてるとか？
0004デフォルトの名無しさん2006/01/18(水) 08:46:11
関連

マルチスレッドプログラミング相談室 その４
http://pc8.2ch.net/test/read.cgi/tech/1130984585/
0005デフォルトの名無しさん2006/01/18(水) 08:49:54
>>3
コアが複数になってもメモリへのアクセスは変わらないので、
今まで以上にメモリ帯域やバスがネックになりそうな感じ。

コアが複数でもI/Oの数（メモリやハードディスク、グラフィ
ックカード等）は変わらないので、それをどうするのか？
というのは問題ですよね。
0006デフォルトの名無しさん2006/01/18(水) 08:53:48
そのうち、それぞれのハードにバスキャッシュが乗るんじゃね？ｗ
バス同士のデータのやりとりで、アクセスロックが発生しかねんが。
0007デフォルトの名無しさん2006/01/18(水) 08:54:15
>>3
各社各様。当然クロスバーにしている所もある。
0008デフォルトの名無しさん2006/01/18(水) 11:43:21
マルチコアの特定のCPUにチューニングするとかしない限り、
従来のマルチプロセッサ向けのマルチスレッド化との違いは、
ないと思われ。

ということで、終了。
0009デフォルトの名無しさん2006/01/18(水) 11:51:57
コア間の転送スピードが速いとかキャッシュの共有が可能とか
わりとマルチプロセッサとは違う動作する

マルチプロセスだとうまみはないが、マルチスレッドによる最適化は
こっちのほうが影響を受けやすい
0010デフォルトの名無しさん2006/01/18(水) 14:54:58
シングルコアだとcopy on writeが有効だけど、メニーコアだとすぱっとcopyしてしまったほうがコア間の依存関係を断ち切れて、かえって効率が上がる、と言う話を聞いたことがある。
こういう、従来の高速化手法をひっくり返すようなものって他にどんなのがあるの?
0011デフォルトの名無しさん2006/01/18(水) 16:46:51
CoWってどのCoW？
0012デフォルトの名無しさん2006/01/18(水) 17:42:46
ライブドア全力で逝った人は自業自得としか言いようが無いね。
今年は少し負けてるけど、我慢してずーっと東１銘柄だけ取引してたから
良かったよ。

新興はもうだめだな。しばらくは様子見しよう。
0013デフォルトの名無しさん2006/01/18(水) 17:43:21
↑
はげしく誤爆。すまそ。
0014デフォルトの名無しさん2006/01/18(水) 17:51:33
>>12
今年で負けてるってどんな銘柄買ってんの？
下手なのはいいけど、人の不幸見て喜ばないように。
0015デフォルトの名無しさん2006/01/18(水) 18:03:08
昔の同僚がやってる会社の株を持ってるぜ。買わされたようなもんだが。
0016デフォルトの名無しさん2006/01/18(水) 18:19:38
京都の漬物ｳﾏｰ
0017122006/01/18(水) 18:30:27
>>14

昨日今日の市場暴落劇知らないのか？
今年はまだ半月しか経ってないから犠牲者多数出てるよ。
職場で昨日から青ざめてる上司とか今日いきなり欠勤した人
とかいない？
0018デフォルトの名無しさん2006/01/18(水) 18:40:23
>>12
知ってていっているんだけど。今日は完全にブラマンだよね。
去年の年末は稼がせてもらったけど、最近はノーポジ。
底で口をあけて待っているところ。

というかスレ違いだ。
0019デフォルトの名無しさん2006/01/18(水) 18:40:33
ライブドアか・・・今なら貝かな？ｗ
0020デフォルトの名無しさん2006/01/18(水) 18:42:00
ﾜﾛｽ
メガデモ、マルチコアときて次は株スレ@ムが立つか？
0021デフォルトの名無しさん2006/01/18(水) 19:17:13
効率なんて人間に考えさせてるようじゃだめ。
人間は人間にとって作りやすく分かりやすい
ようにプログラムを作って、あとは全自動で
それを効率よく動かすようなシステムを作る
べきだ。

人間に最適化をやらせるとろくなことはない。
そんなもんはC言語で散々やられてわかっって
るだろう? 無理にポインタ使って効率よく
作ったプログラムは読みづらいばかりか後の
コンパイラでは最適化の邪魔になったじゃないか。
0022デフォルトの名無しさん2006/01/18(水) 19:20:22
未来のコンパイラのために今のプログラムを劣化させるべきだというのかい？
しかも未来のコンパイラがどんな最適化をしてくれるのかもわからないというのに
0023デフォルトの名無しさん2006/01/18(水) 19:31:05
あったあった。
ttp://pcweb.mycom.co.jp/news/2005/12/19/046.html
こういうのがほんとに普遍的に作用してくれるなら楽だろうね。

ただ、こういうのを使ったとしてもハード側とソフト側の両方に対して見識が深くないと
有意な高速化はできないだろうなあ。
どうやっても複数コアでは高速化できない類のプログラムってのも存在するはずだし。
0024デフォルトの名無しさん2006/01/18(水) 19:46:56
>>23
やっぱり理想は自動並列化だよね。特に自動並列化コンパイラ
には期待だけど、マイクロソフトなんかは今になってやっと
OpenMPを実装したから、普及は思っているより先になりような
予感はする。

ところですまないんですが、浅はかな質問をさせてください。

並列化の割合を上げるには、タスクをアトミックな単位で
分割して並列実行するのがよろしいのかと思います。
おそらくもっともアトミックかつすでに自動的な並列化である
CPU内部のスーパースカラの本数を増やすとか同時実行できる
命令の種類を増やすために実行ユニットを増やすといった
方法はなぜとられないんでしょうか。多分、CPUメーカーの
人とかは解っててやっているんでしょうが。
0025デフォルトの名無しさん2006/01/18(水) 19:58:58
>>24
たぶん
＞並列化の割合を上げるには、タスクをアトミックな単位で
＞分割して並列実行するのがよろしいのかと思います。

これが間違いだからじゃない？
既存のタスクを自動的に分割しても並列度はあまり上がらない。
0026デフォルトの名無しさん2006/01/18(水) 20:15:01
そこでいよいよ並列化プログラムを書きやすいと言われている関数型言語の出番か？
0027デフォルトの名無しさん2006/01/18(水) 21:20:17
>>26
そうなの？ポインタあったら教えて。

(純粋な)関数型言語ではモナドなんかを使わないと状態が
扱えないから、ふたつのスレッドで変数を共有したりとか
できないから、何らかの工夫がないと普通のスレッドみた
いなことはできないよ。まあ、そのままだと状態が扱え
ないから資源の競合なんかは絶対発生しないけど、殆どの
場合それじゃだめでしょ。

確かに何となく自動並列化みたいなのはできそうな気も
するけど、気がするだけでよくわかんないな。
0028デフォルトの名無しさん2006/01/19(木) 00:05:07
関数型で並列か。そろそろ Erlang の時代が来るかな。

>>24
>CPU内部のスーパースカラの本数を増やすとか同時実行できる
>命令の種類を増やすために実行ユニットを増やすといった
>方法はなぜとられないんでしょうか。

過去、どんなに頑張っても４並列くらいまでしかいかなかったから。
0029デフォルトの名無しさん2006/01/19(木) 00:20:01
Erlang
→http://www.kmonos.net/alang/etc/erlang.php#process1
スレッド間のやりとりにはメッセージ通信で実現するみたいですね。

思ったんですが、確かにタスク間のやりとりは共有メモリみたいな
ものでなくて、メッセージ通信の方がスマートな感じがします。
この手のメッセージを行うライブラリにはMPIがあるようですが、
これは完全に独立したプロセス間の通信ですよね。フリーで気軽
につかえるスレッド間通信のライブラリって誰かしらない？

組み込みではμTRONがOSはメッセージボックスつーのがあって
タスク間の通信ができるのですが、Windowsってそういう仕組み
がないですよね。一応SendMessageとかのAPIはスレッドセーフに
なっているけど機能不足だし。
0030デフォルトの名無しさん2006/01/19(木) 00:39:57
関連スレ

数百のコアプロセッサ用新言語「Baker」
http://pc8.2ch.net/test/read.cgi/tech/1110031339/

日本発、次世代言語：　織田信長
http://pc8.2ch.net/test/read.cgi/tech/1047230229/
0031デフォルトの名無しさん2006/01/19(木) 00:44:50
>>27
関数型言語では、変数代入でなく束縛（再束縛禁止）が普通なので、
式の前のほうと後ろのほうに依存がなく、
処理系が勝手にバラバラのスレッドで実行できる。
副作用なしなので当然スレッド間の干渉はない。

とよく知らんけど妄想。
0032デフォルトの名無しさん2006/01/19(木) 01:01:21
副作用なしっていう制約下でマットウにプログラムかけるやつがどれくらいるのか
という問題はある
0033デフォルトの名無しさん2006/01/19(木) 01:01:38
>>29
Javaが5.0になってからマルチスレッド回りの処理が大幅にパワーアップしたけど
これもマルチコアを見据えてのことなのかなぁとおもった

JavaやC#とか高級言語はどんどんこの辺は容易になって来るでしょうね
逆にC++とかはガリガリかけるけど、つらいものが
0034デフォルトの名無しさん2006/01/19(木) 01:08:49
>>33
C言語も重い腰を上げて言語レベルでの並列処理を(C++0xとかで)
サポートしようという動きもあるみたい。今まで言語で並列処理
を何でサポートしなかったんだというのはあるけど。
0035デフォルトの名無しさん2006/01/19(木) 02:09:16
トータルの処理コストは 1.5 倍になるが、完全に並列化出来るから、
実行時間は 2 スレッド時で 0.75 倍みたいな世界が来るのかしら。
0036デフォルトの名無しさん2006/01/19(木) 02:36:54
C++はBetter Cだからなぁ。正直あんなつぎはぎの言語仕様
ぜんぜん使いたくない。JavaとかC#のほうがよほど洗練され
ていると思う。ヘッダファイルとかローテクすぎ。
0037デフォルトの名無しさん2006/01/19(木) 03:30:19
>>C++はBetter Cだからなぁ。

馬鹿発見。
0038デフォルトの名無しさん2006/01/19(木) 04:09:42
>>9
現実のアプリケーションで性能差がどれくらい出るの?
プログラムをチューニングするほどの差がないなら、終了、だよ。
0039デフォルトの名無しさん2006/01/19(木) 04:13:09
複数のスレッドに分割するのが大変なアプリで、速度を要求するものってあるの?

重いアプリは、
今まで通りに、おおきな粒度で水平垂直に分割すれば、速くなるじゃないか。
0040デフォルトの名無しさん2006/01/19(木) 04:21:39
そうは言っても、
昔なら遅くなるし面倒だからやらない、なんて感じだった
付加的な処理でも、ＣＰＵの速度向上や生産性の向上で
どんどん付ける様になってる。

そうやってソフトが進化してきたのが、ＣＰＵのコア速度頭打ちで終わってしまう。
0041デフォルトの名無しさん2006/01/19(木) 04:25:16
>>32
最初からそういうプログラミングを教育をすれば良いじゃない。

Cやアセンブラから入ったＤＱＮＰＧはオブジェクト指向が理解できないけど、
同レベルの奴でも最初からJavaとかで始めると理解できる、なんて話があるらしい。
0042デフォルトの名無しさん2006/01/19(木) 08:21:16
関数型もいいが、Prologとかの論理型も並列処理に向いてそうな希ガス
0043デフォルトの名無しさん2006/01/19(木) 10:36:06
手続き型が一番向いてないね。
0044デフォルトの名無しさん2006/01/19(木) 10:41:34
逐次処理なのがネックだよねぇ・・・。

ただ、今のCPUとOSは、スレッド間の同期が重いと思う。
粒度を小さくしていくと、同期のオーバーヘッドが無視できなくなる。

だから、今のCPUとOSを使う限り、粒度の大きなマルチスレッド化しかない。
そのスレッド分割を人間がやるか、自動化するか、ってことだよね。
0045デフォルトの名無しさん2006/01/19(木) 11:08:34
よくは知らんけど純粋関数型言語ってのは
入出力に副作用時だけ同期させてればいいのかな？
0046デフォルトの名無しさん2006/01/19(木) 12:50:11
>>42
織田信長がそうだな。並列論理型言語。
しかし、論理型言語なんて使ってる奴いるのか？
0047デフォルトの名無しさん2006/01/19(木) 13:10:46
"Functional Concurrent Language" の検索結果 約 178 件中 1 - 10 件目 (0.53 秒)
"Concurrent Functional Language" の検索結果 約 744 件中 1 - 10 件目 (0.58 秒)

"Logic Concurrent Language" の検索結果 約 16 件中 1 - 10 件目 (0.77 秒)
"Concurrent Logic Language" の検索結果 約 344 件中 1 - 10 件目 (0.55 秒)

"Concurrent Procedure Language" の検索結果 約 3 件中 1 - 2 件目 (0.44 秒)
"Concurrent Procedural Language" の検索結果 3 件中 1 - 3 件目 (0.47 秒)
"Procedure Concurrent Language"に該当するページが見つかりませんでした。
"Procedural Concurrent Language" の検索結果 4 件中 1 - 4 件目 (0.46 秒)
0048デフォルトの名無しさん2006/01/19(木) 14:41:43
マルチコアの片方をGC専用にするのはありですか?
0049デフォルトの名無しさん2006/01/19(木) 14:44:05
"Concurrent Programming Language" の検索結果 約 24,700 件中 1 - 10 件目 (0.37 秒)
0050デフォルトの名無しさん2006/01/19(木) 15:24:48
そのうちマルチコアって言ってもCPUが4個とか8個とか16個とかが当たり前になるんだろうな。

そしてその後1スレッドを1CPUで動かす時代が来る。
0051デフォルトの名無しさん2006/01/19(木) 15:31:48
10年後。
CPUのクロックは100GHzになり、16384コア32768コアも当り前になり、
メモリは256Gバイトが3千円ぐらい。HDDは250Tバイトが1万円を切る。
もちろんPCの電源を入れると複数個のOSが同時に起動する。
0052デフォルトの名無しさん2006/01/19(木) 15:50:07
> CPUのクロックは100GHzになり、

わかってないな、こいつ
0053デフォルトの名無しさん2006/01/19(木) 15:53:03
>>52
なるだろう。
0054デフォルトの名無しさん2006/01/19(木) 15:54:53
>>52
電気で動くCPUとも書かれていないから良いんじゃない?
0055デフォルトの名無しさん2006/01/19(木) 21:01:49
これが技術的に可能になれば100GHzのCPUや256GBのメモリもできるだろ。
ttp://www.nanoelectronics.jp/kaitai/moletronics/index.htm
そのころにはHDDもこれに置き換わっているかも･･･
http://www.nanoelectronics.jp/kaitai/mram/index.htm
究極の並列処理素子。ここまで行ったら･･･
ttp://www.nanoelectronics.jp/kaitai/quantumcom/index.htm
0056デフォルトの名無しさん2006/01/19(木) 21:44:58
実現してない話はどうでもいい
0057デフォルトの名無しさん2006/01/19(木) 22:59:21
シングルコアで順調に速くなっていくんだったら、マルチコアなんて要らんだろ。サーバはともかく。
１０年で分子コンピュータ技術が実用レベルに達して商用になるかと言えば、ならない方に賭けるな。
だってCPUの基礎技術は２０年以上変わってないのでは？
0058デフォルトの名無しさん2006/01/19(木) 23:01:19
￣￣￣￣￣￣)／￣￣￣￣￣￣￣￣￣￣
　　　　( 　＾ω＾) 　　 　∧＿∧
　　　 ／ 　　　 ＼　 　（　　　　）何言ってんだこいつ
.＿＿|　|　　　 .|　|＿　/ 　　 　 ヽ
||＼　￣￣￣￣　　 ／ .|　　　|　|
||＼..∧＿∧　 　　(⌒＼|_＿./ ./
||.　 （ 　　　）　　　　 ~＼___＿_ノ|　　 ∧＿∧
　　/　　　ヽ　氏ねよ 　　 　 ＼| 　 （　　　　）
　　|　　　　　ヽ　　　 　　　　　　　＼/ 　　　 ヽ. ｵﾏｴ馬鹿だろ
　　|　　　　|ヽ、二⌒) 　　　　 　　／ .|　　　|　|
　　.|　　　　ヽ　＼∧＿∧　　　 (⌒＼|_＿./　/
0059デフォルトの名無しさん2006/01/19(木) 23:04:43
前：デフォルトの名無しさん ：2006/01/19(木) 23:01:19
￣￣￣￣￣￣)／￣￣￣￣￣￣￣￣￣￣
　　　　( 　＾ω＾) 　　 　∧＿∧
　　　 ／ 　　　 ＼　 　（　　　　）何言ってんだこいつ
.＿＿|　|　　　 .|　|＿　/ 　　 　 ヽ
||＼　￣￣￣￣　　 ／ .|　　　|　|
||＼..∧＿∧　 　　(⌒＼|_＿./ ./
||.　 （ 　　　）　　　　 ~＼___＿_ノ|　　 ∧＿∧
　　/　　　ヽ　氏ねよ 　　 　 ＼| 　 （　　　　）
　　|　　　　　ヽ　　　 　　　　　　　＼/ 　　　 ヽ. ｵﾏｴ馬鹿だろ
　　|　　　　|ヽ、二⌒) 　　　　 　　／ .|　　　|　|
　　.|　　　　ヽ　＼∧＿∧　　　 (⌒＼|_＿./　/
0060デフォルトの名無しさん2006/01/19(木) 23:34:08
分子コンピュータの開発なんてもう10年以上前からやってるわけだが
0061デフォルトの名無しさん2006/01/20(金) 00:04:15

C MAGAZINE 2006年2月号
ttp://www.cmagazine.jp/
デュアルコア・マルチコアのCPUで大活躍
OpenMPで賢いマルチスレッドプログラミング（前編）
0062デフォルトの名無しさん2006/01/20(金) 00:06:04
いい最終回だった
0063デフォルトの名無しさん2006/01/20(金) 00:37:36
実際のところ最もパワーが必要になるのは鯖とかエンコとかゲームだから
それらはマルチスレッド化での効果はわりと大きいからべつにいいんじゃね？

>>48
あり
Java5のインクリメンタルGCのデフォ並列世代別GCになってる
通常のアプリが動いてる後ろでガリガリGCしてくれてる
そしてストップが必要になるGCについてもこれもオプションで並列動作可能

あずーるとかみたいにハードのサポートが来るのが一番だと思うけどね
そうでなくとも中間言語系はバックグラウンドでかなり動いてるから
アプリは何もしてなくても2コアでもびっくりするほど恩恵を受けるよ
0064デフォルトの名無しさん2006/01/20(金) 00:51:17
Emacsのマルチスレッド化はいつのことになるやら・・・
0065デフォルトの名無しさん2006/01/20(金) 02:55:56
>>61
前編で終るのか・・・。
0066デフォルトの名無しさん2006/01/20(金) 03:01:37
最終号はなにか凝ったことするのかな
0067デフォルトの名無しさん2006/01/21(土) 12:49:44
メモリー自体にCPUを乗せて、簡単な処理はメモリーが直接計算する、という案は駄目でつか？
今の技術なら、Z80CPU1万個を一枚のチップに乗せて、並列に計算させるぐらいの事は、
できそうな気がするけどな・・・無茶か？
0068デフォルトの名無しさん2006/01/21(土) 12:50:44
>>67
消費電力が物凄い事になりそうだぞ？
0069デフォルトの名無しさん2006/01/21(土) 12:52:41
>>67
似たようなアーキテクチャがNTTのCELLでなかったかい？
0070デフォルトの名無しさん2006/01/21(土) 12:54:05
オブジェクト指向はクラスタ化のためにやるんだと思ってた・・・
0071デフォルトの名無しさん2006/01/21(土) 12:56:33
普通の会社はメモリと密接にってのはまず無理

メモリってデータ取り出すだけでどういう動作するか分かってる？
せいぜいメモリコントローラ作ってフロントエンドで処理するしかないよ

Z801万個くらいの性能デイならFPGAでできそうだが
0072デフォルトの名無しさん2006/01/21(土) 13:00:46
描画メモリーならレイトレースするエンジンがそんな感じだと思った
0073デフォルトの名無しさん2006/01/21(土) 15:20:43
ようわからんが、これってそんな感じ？
GPGPU
http://pc8.2ch.net/test/read.cgi/tech/1128780920/
0074デフォルトの名無しさん2006/01/21(土) 15:46:47
>>73
保守乙
0075デフォルトの名無しさん2006/01/21(土) 16:43:50
よく知らんが、WRAMとかSGRAMとかVRAMとか、その系統じゃね？
もう名前を聞かなくなって久しいが。
まだ特定用途向けに使われてるのかな。
0076デフォルトの名無しさん2006/01/21(土) 17:26:33
箱○に載ってるね。メモリアクセスだけで、Zバッファや
アンチエリアシングの処理をするのに使われている。
0077デフォルトの名無しさん2006/01/22(日) 01:29:23
Cellはゲームに特化したプロセッサだから汎用には不向きだぞ。
0078デフォルトの名無しさん2006/01/22(日) 03:06:27
だねえ、CELLは倍精度演算とか弱いし、特定のメディア用プロセッサであって
汎用CPUにはなれない。
そのかわりDSPの塊みたいなものだから用途が合えばめちゃ速いと思う。
0079デフォルトの名無しさん2006/01/22(日) 10:13:15
mpeg2やDivXの高品質リアルタイムエンコ、とかは?
0080デフォルトの名無しさん2006/01/22(日) 10:15:50
デジタル回路で処理してるだけかと
0081デフォルトの名無しさん2006/01/22(日) 11:16:09
メモリというかレジスタだな。
00821=メガデモスレ6602006/01/22(日) 21:10:22
http://pc7.2ch.net/test/read.cgi/jisaku/1136822334/
マルチスレッドスレに貼り付けてあったんだけど、面白そうなので
ここにも貼っておく。アンチマルチコアって自分だけじゃないのを
初めて知った。PC自作板ってつまんないから全然みないんだよね。
0083デフォルトの名無しさん2006/01/22(日) 21:16:12
つーか、アンチうざい
新しいのが出てきてそれについていけないやつだと思うけど
0084デフォルトの名無しさん2006/01/22(日) 23:21:03
2コアぐらいなら、OSとアプリケーションでおおまかにひとつづつ使い切るような感じで、
別にシングルスレッドのアプリケーションでも意味あると思うんだよね。
だけど、４、８とコアが増えてくるとそうはいかない。負荷がかかってるのにも関わらず
アイドル状態のコアが出てきちゃいそう。
0085デフォルトの名無しさん2006/01/22(日) 23:31:53
>>84
> 2コアぐらいなら、OSとアプリケーションでおおまか
> にひとつづつ使い切るような感じで、

流石にお馬鹿の Windows でも、そんなにＯＳのオーバー
ヘッドはでかくない。シングルスレッドプログラムではマル
チコア/マルチプロセサの恩恵はほぼないので、

> 負荷がかかってるのにも関わらずアイドル状態のコアが
> 出てきちゃいそう。

と言うのは、２コアでも十分ある。
0086デフォルトの名無しさん2006/01/23(月) 00:49:24
>>85
自作板を見てると、DualはWindowsの体感速度が上がるからっていう理由で
買ってる人が多いみたいなんだよね。IEやエクスプローラを含めたOS全般と
自分の使ってるアプリケーションの両方が同時にスムーズに動くと。
だけど、そういう人たちでもさすがに４個や８個もの多コアは買わないだろうな
という気がした。
0087デフォルトの名無しさん2006/01/23(月) 00:52:06
>>83
そういうやつが周りに一杯いるけどそういう奴は蹴落としていくしかないと思う。
なんとなく小泉総理が親友を作らず孤独な少年であったというのが分かる気がする
0088デフォルトの名無しさん2006/01/23(月) 01:15:57
淘汰されるなら淘汰されるで歓迎
0089デフォルトの名無しさん2006/01/23(月) 02:47:28
>>85
常に一個位アイドルなCPUが居るのって結構重要だったりする。
エンコやら異常事態やらで地獄の様に重い時でもUIの応答が軽いのはストレスを生まない。
0090デフォルトの名無しさん2006/01/23(月) 06:14:19
それはnice値変えるだけでもいいような
0091デフォルトの名無しさん2006/01/23(月) 07:30:41
それはniceなアイディアだ
0092デフォルトの名無しさん2006/01/23(月) 08:55:09
アンチってなんなの？
マルチスレッドプログラムがかけない人なの？
シングルコアの性能をもっとあげる方法を発明できる人なの？
アンチとして存在してる意味がﾜｶﾗﾈ
0093デフォルトの名無しさん2006/01/23(月) 09:40:16
>>92
今まで普通にプログラムを作ってきたプログラマー達だね。
彼らは今まで作り上げ積み上げてきた自分の技術が無駄になるのではないかと戦々恐々としている。
おもにアセンブラ・C/C++を使ってシングルスレッドでのパフォーマンスを上げることに血眼になってきた人たち
>>63の言うとおりにガベージコレクションの性能が上がったとしたらそれだけで彼らは失職の危機にさらされる。
まあ、主にゲームプログラマーだけどね。
実際ゲームはシングルスレッド信仰がすごい強い分野だと思う。

ただ、滑稽なのはゲームなんてクリエイティブな分野でそんなに技術屋さんがでしゃばっていること。
本当はマルチコアでどんな新しいゲームが作れるかを考えるべきなのにそれを邪魔するだけの典型的な既得権益者なので
外野としてはそんな害虫どもにはさっさと消えてもらうことを祈るだけだね
0094デフォルトの名無しさん2006/01/23(月) 12:54:33
＞彼らは今まで作り上げ積み上げてきた自分の技術が無駄になるのではないかと戦々恐々としている。
＞おもにアセンブラ・C/C++を使ってシングルスレッドでのパフォーマンスを上げることに血眼になってきた人たち

それで困るのは半端な連中だけだ

きっちっとした技術を積み上げてきたヤシなら、それほど恐怖でもない
むしろ他の連中と差をつけるチャンスだ罠
0095デフォルトの名無しさん2006/01/23(月) 13:25:29
>>93
ガベコレの性能とゲームプログラマの失職に何の関係がある？

あと、ゲームのどの変の処理にマルチスレッドを導入するべきだと思う？
0096デフォルトの名無しさん2006/01/23(月) 14:51:31
>>95
GCの性能が上がったら高級言語でもそこそこゲームが作れるようになるじゃないか。
ベンチマークではC++と関数型なんてほとんど変わらないしな。
そうなるとある程度ライブラリとかフレームワーク作ったり業務系と同じようになってくるんじゃないかな?
単純にシングルコアの性能だけでも相当向上してるのだからそうやってやり方が変わって脱落者が出るのでは？。

どんなゲームがいいかは例えばRTSのようなゲームで個々のユニットを複雑なアルゴリズムで動かすとかはどうだ?
0097デフォルトの名無しさん2006/01/23(月) 15:35:46
D言語の時代ｸﾙｰ?
0098デフォルトの名無しさん2006/01/23(月) 15:56:06
DってGC性能が低いんだったっけ？
それ以前に仕様がまだ固定化されてないのが気になるが

それとDはスレッドの機能が初期のJavaベースで非常に少ない気がするんだが
今後マルチスレッドプログラミングが増えればこのへんとかネックになってくるかもね
ま、必要になってくれば標準APIとして実装されるとは思うけど

今後スレッドが言語に組み込まれてない環境は厳しくなるよね
0099デフォルトの名無しさん2006/01/23(月) 16:43:54
>>96
処理速度の向上によって今までC/C++でしかできない・C/C++が望ましかったような
ゲームが、Javaや関数型言語でも実装できるようになるだろう、という予測？

それともイチから実装する難易度が超絶的に上がり、結果必然的に高レベルなライブラリが
整備されるので、高級言語だけでもなんでもできるようになるだろうという話？

後者は理解できるけど、前者は疑問なような気がする。
生産性の向上によって確保した知的資源は、更なる難問の解決に使われるのが普通だから。
（そうじゃないと低賃金労働でしか生き残れない）
0100デフォルトの名無しさん2006/01/23(月) 19:08:23
豪華なマシンになってPGが楽になる・・・なんてことはなく、
実際は性能を限界まで出しきることを期待されてひどい目に遭うだけ。
0101デフォルトの名無しさん2006/01/23(月) 19:23:38
>>100
ゲーム業界だとSFC,PS,PS2の時に聞かされた、PS2はまぁ期待にそえんでもなかったが。
■ このスレッドは過去ログ倉庫に格納されています