[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[plamo:19671] Re: make -j について



小野@名古屋大学 です. 脱線ついでに:

<20030714024506.GA2809@wiz7.prosaic1.a08.aist.go.jp>の記事において
azure-ml@fan.gr.jpさんは書きました。
azure-ml>   しかしながら、どちらのカーネルで -j 2 をやっても効果はありません。
「n個の CPU があるときに make -j (n+1) ってやるとディスク待ちが減
るよ〜」って話があったような.

azure-ml> > ところで、AthlonXP のように、パイプラインを横に並べるのと、P4 のように、
azure-ml> > パイプラインを縦に長くするのとでは、どっちが効くんでしょうね。おそらく
azure-ml> > 一長一短だとは思うのですが、分岐予測まわりも絡めて考察すると、かなり奥
azure-ml> > が深そう。
azure-ml>   個人的には短いパイプラインを横にしたほうが速いんじゃないかなあ、って思
azure-ml> っています。ベンチマークのような単調な命令をこなすのならばやっぱり深い
azure-ml> パイプラインのほうが有効なんでしょうけど。
ん〜, どうなんでしょうね. パイプラインの段数を増やすと
○: 1段あたりの仕事が減るのでクロックを上げやすい.
×: 分岐等のペナルティが大きい.
ってトレードオフがありますんで.

逆に, 複数のパイプラインを並列にすると
# 「横に並べる」ってのはこんなイメージ?
命令間の依存関係を考慮して命令を発行しなきゃならないという問題が
発生します.

Itanium なんかはこの辺をソフトウェアで解決 (命令に依存関係を埋め
込む) してますけど, ハードウェアでやろうとすると結構つらいような
気がします.

ところで, AthlonXP のパイプラインって 1本じゃありませんでしたっけ?
# 同時命令発行数とパイプラインの本数は関係ないし.

azure-ml> # 将来的には大量のパイプラインを並列にして、分岐予測をするのではな
azure-ml> # く、全て (は無理にしても多く) の場合を計算し、正解だけを使う、なんて
azure-ml> # アプローチがでてきたりして。
azure-ml> # それとももうやってるんでしたっけ?
研究レベルでは既に始まっているんじゃないでしょうか. IDF かどっか
で話があったと思います.
-- 
名古屋大学大学院 情報科学研究科 計算機数理科学専攻
小野 孝男

Follow-Ups
[plamo:19673] Re: make -jについて, KOJIMA Mitsuhiro
[plamo:19674] Re: make -jについて, Shun-ichi TAHARA (田原 俊一)
[plamo:19675] Re: make -j について, OHNO Tetsuji
References
[plamo:19670] Re: make -jについて, OHNO Tetsuji

[検索ページ] [メール一覧]
Plamo ML 公開システム