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

[Ryoichi INAGAKI]

亀山様

稲垣です。情報ありがとうございます。

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 ノードかそれ以上かで実行するコードが違っていた
りするのでしょうか。


> > 使用しているのはデュアルコア Opteron なのですが、
> 
> Fedora Core 4 の  x86-64 のほうでしょうか?
> それとも i386 のほうでしょうか?
> 使用している PM デバイスは ethernet でしょうか?

ハードウェアは hp Proliant DL145 G2 を使用しており、x86-64 の Fedora
Core 4 を使用しています。

SCore はソースからコンパイルしたのですが、 score-src/SCore/rc 以下で
x86_64-fedoracore3-linux2_6 をコピーして x86_64-fedoracore4-linux2_6
として使っています。

PM デバイスは ethernet(tg3) と shmem を使用しています。


> > # Fedora Core 4 より Fedora Core 3 の方が無難でしょうか?
> 
> テストしているのが Fedora Core 3 なので, SCore 的には Fedora Core 3
> のほうが無難ですが. デュアルコア Opteron  だと install できるか
> どうかのほうが問題になりそうな...

結構、SCore 内部で CPU Specific な命令を使っていたりするのでしょうか...


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

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