[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 メーリングリストの案内