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

kameyama @ pccluster.org kameyama @ pccluster.org
2005年 12月 5日 (月) 19:51:32 JST


亀山です.

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) のほうが
影響は大きいかも知れません.

                       from Kameyama Toyohisa



SCore-users-jp メーリングリストの案内