[SCore-users-jp] Re: Is it a MPICH-SCore problem?

[Ryoichi INAGAKI]

亀山様

早稲田大学の稲垣です。
返信が遅くなってしまい申し訳ありません。

On Mon, 05 Dec 2005 19:51:32 +0900, 
kameyama ＠ pccluster.org wrote:

> In article <20051205.185837.193695604.inagaki ＠ ueda.info.waseda.ac.jp> Ryoichi INAGAKI <inagaki ＠ ueda.info.waseda.ac.jp> wrotes:
> > On Mon, 05 Dec 2005 17:23:30 +0900, 
> > kameyama ＠ pccluster.org wrote:
> > 
> > >  6. system call を trap しているので, そのための overhead
> > >    7. memory limit などを監視するための overhead
> > > がありますが, 多分, そんなに大きくはないと思います.
> > > 7. は default で single user mode で 10 秒です.
> > > (scrun の -ts オプションで変更できます.)
> > > 6. は compile のときに -noscwrap オプションをつければ回避できます.
> > 
> > 両者とも試してみましたが、状況は変わりませんでした。
> > scrun の -node 指定が 1 ノードかそれ以上かで実行するコードが違っていた
> > りするのでしょうか。
> 
> 基本的にはコードは同じです.
> ただ, PM の初期化などを行なうかどうかが違ってくるだけだと思います.
> (program の起動前とか, MPI_init() あたりだけだと思いますけど...)
> 
> > > > # Fedora Core 4 より Fedora Core 3 の方が無難でしょうか?
> > > 
> > > テストしているのが Fedora Core 3 なので, SCore 的には Fedora Core 3
> > > のほうが無難ですが. デュアルコア Opteron  だと install できるか
> > > どうかのほうが問題になりそうな...
> > 
> > 結構、SCore 内部で CPU Specific な命令を使っていたりするのでしょうか...
> 
> CPU 依存のものは若干はありますが, かなり限定されていると思います.
> (spinlock とか,  SCore-D の記述言語 MPC++ での setjump/longjump とか...)
> 
> むしろ, compiler の変更 (Fedora Core 4 は gcc 4) のほうが
> 影響は大きいかも知れません.

GCC 3.2 を使って SCore をビルドしてみましたが変化はありませんでした。

SCore 自体をプロファイリングしてみたいのも山々なのですが、卒論等の関係
でそのあたりに手をいれる時間もあまりないので、当座は素の MPICH で凌ご
うと思います。解決できたら、また報告させていただきたいと思います。


_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
  早稲田大学大学院 理工学研究科
  情報・ネットワーク専攻 上田研究室 D1

  稲垣 良一  <inagaki ＠ ueda.info.waseda.ac.jp> 
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/