[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[plamo:19673] Re: make -jについて
-
From:KOJIMA Mitsuhiro
-
Date:Mon, 14 Jul 2003 12:53:30 +0900 (JST)
- Subject: [plamo:19673] Re: make -jについて
- From: KOJIMA Mitsuhiro <kojima@xxxxxxxxxxx>
- Date: Mon, 14 Jul 2003 13:03:07 +0900 (JST)
こじま@いよいよ 2.6 の pre バージョンが出そうだな,です.
From: takao@hirata.nuee.nagoya-u.ac.jp (Takao Ono)
Subject: [plamo:19671] Re: make -j について
Date: Mon, 14 Jul 2003 12:17:32 +0900
> <20030714024506.GA2809@wiz7.prosaic1.a08.aist.go.jp>の記事において
> azure-ml@fan.gr.jpさんは書きました。
> azure-ml> しかしながら、どちらのカーネルで -j 2 をやっても効果はありません。
> 「n個の CPU があるときに make -j (n+1) ってやるとディスク待ちが減
> るよ〜」って話があったような.
make -j 2 は,make 時に動かす子プロセスの数の制限だから,カーネルや
CPU の性能云々よりも Makefile の書き方に依存するでしょうね.
Linux のカーネルの場合,2.0 のあたりで SMP 機能が入って,そのデモとい
う意味も込めて,ジョブが並列化されやすいように Makefile をチューニング
したから,SMP な環境で make -j 3 とかやれば,コンパイル時間はほぼ半分
(速度的には 1.8 倍くらい) になったはず.
# 世間一般的には,並列化をそれほど考えてない Makefile の方が多いので,
# せいぜい 1.5 倍くらいかな?
ちなみに,-j を指定する場合は CPU の個数 +1 にするのが良い,というのは,
ジョブの管理用にプロセスが一つあって,各 CPU にジョブをそれぞれ割りあ
てるから n+1 になる,という話を聞いたことがありますね.
# 最近は SMP なマシンをいじってないから,SMP 周りの話題にはめっきり疎
# くなっている..
> ん〜, どうなんでしょうね. パイプラインの段数を増やすと
> ○: 1段あたりの仕事が減るのでクロックを上げやすい.
> ×: 分岐等のペナルティが大きい.
> ってトレードオフがありますんで.
>
> 逆に, 複数のパイプラインを並列にすると
> # 「横に並べる」ってのはこんなイメージ?
> 命令間の依存関係を考慮して命令を発行しなきゃならないという問題が
> 発生します.
>
> Itanium なんかはこの辺をソフトウェアで解決 (命令に依存関係を埋め
> 込む) してますけど, ハードウェアでやろうとすると結構つらいような
> 気がします.
ソフトウェア的にやろうとしても,この手の CPU アーキテクチャにベッタリ
と依存する部分は GCC みたいな汎用コンパイラだと対応するのが難しいでしょ
うね.
Intel は自前のコンパイラを公開しているけど,AMD にはそこまでのパワーは
無いかな?
> azure-ml> # 将来的には大量のパイプラインを並列にして、分岐予測をするのではな
> azure-ml> # く、全て (は無理にしても多く) の場合を計算し、正解だけを使う、なんて
> azure-ml> # アプローチがでてきたりして。
> azure-ml> # それとももうやってるんでしたっけ?
> 研究レベルでは既に始まっているんじゃないでしょうか. IDF かどっか
> で話があったと思います.
グリッドコンピュータみたいな世界になってくると,こういうアプローチも出
てきそうな気がしますね.
# 高速思考と分割思考が錬金術師の基本技能,,とかつぶやいてみる(笑)
--------
こじま
- References
-
- [plamo:19670] Re: make -jについて, OHNO Tetsuji
- [plamo:19671] Re: make -j について, Takao Ono
[検索ページ]
[メール一覧]
Plamo ML 公開システム