久しぶりに近所の本屋にいくと、書籍の売り場が拡張されていた。
ここは書籍の他に携帯からカメラからCD/DVD、ゲームはてはプラモや駄菓子まで
節操なく売ってる店だったんだが、書籍にしろ CD にしろ、売り場面積が狭いのに
輪をかけて絶対量が少なく、揃えの点では全く期待できない店だった。
それが、携帯売り場を２階に移して１階を全て書籍にし、さらに本棚も増やして高層化して
絶対量・密度共に向上させてあった。
……でも充実したとはいいがたいのは何故（笑）
朝の９時からセッションが始まるくせに、夜の７時半から９時半までの working discussion まであるとはどう言うことか。
束縛されまくり。一日座っているだけでへとへと。
布団が暑くて、さらにチェックアウトの都合で朝飯が早くてイマイチ疲れが取れてない。
某君は山形の米はうまいとお替わりしていた。
昼飯の蕎麦につきあわせるために山形から一人召還。到着までの時間つぶしに天元台まで行ってみたり。
帰りの新幹線は案の定混み混み。福島で次のやまびこに移って６人席占有して帰って来たが、さすがに途中から混みだして気が付けば満席状態。爆睡して東京に付いたのが６時で、６時40分のバスがまた満席でこっちは補助椅子。
朝６時のバスで上野まで出て、つばさで米沢へ。
死ぬほど混んでいて最後まで立ち通しの上、ツアー客かなにかが頻繁に通路を行き来する罠。 JR め、ちゃんと運搬できる量のある列車を走らせやがれ。
写真とって、芋煮喰って、ゲーセンで寝て、山翠でメシ喰って温泉入って寝る。
月曜から職場で国際会議なので、会場設営を少々。
机並べ替えたりパソコンかき集めて来たり、マイクやプロジェクターのテストしたり。
windows xp ってメニューとか英語にできないの？
LAM/MPI 環境での並列計算、 FreeBSD box だけ MPI universe には組み込めても並列計算には参加参加させられなかった。こいつだけ private address なので、ネットワーク周りでしくじっているのかと思っていたが、いろいろ試すと１プロセスだけなら MPI 経由で実行できるが、複数プロセスにすると FreeBSD box 上だけに限定しても死ぬことが判る。幸いにも core を遺していったので gdb で拾うと libc_r の中で死んでいる……。
libc_r っつーと thread ？って気が付いたが、ここで動かそうとしているプログラム、無茶苦茶 thread unsafe なのである。 POWER3 x 4 の AIX や某スパコンの要素並列ノードでコンパイラに thread 化したコードを吐かせると、確実に挙動が変わって実行できなくなる。
FreeBSD box 上では Linux 用の Intel Fortran を使っているんだが、オプティマイズかけると勝手に thread 化して、しかも MPI から並列実行させるとその辺の破綻が顕在化するってことだろうか。
案の定 g77 を使って作ってやるとちゃんと並列に計算している。
しかしな〜、 g77 の吐くコード遅いんだよな…。
これはもう極力使いたくないんだがさてどうしたものか…。
ifc でオプティマイズ外して調子見るかな〜
ちなみにこれが、同じ計算をさせた時の計算時間の比較。短い方が速い。 FreeBSD のいいコンパイラ欲しいな
MacOSX / PowerPC G4 1GHz g77 -O4 -fnoautomatic (gcc 3.4) total cpu time = 697.12 XL Fortran -O4 total cpu time = 456.01 AIX / POWER3 375MHz XL Fortran -O3 -qstrict -qarch=pwr3 total cpu time = 633.07 FreeBSD / Pentium III 800MHz g77 -O3 -funroll-loops -fnoautomatic (gcc 3.2.2) total cpu time = 706.52 Intel Fortran -O3 total cpu time = 640.77 PGI Fortran -O4 total cpu time = 514.98
lam/mpi 環境の build はなんとかこなして、各ホストにセットアップした。
ここからが難行の始まりで、 mpi 環境が boot するまでしばらくハマる。
各ホストの mpi daemon を kick するのに rsh/ssh を使うのは許すとして、そしてこいつらは似たようなものだから一つのモジュールで扱うのも妥当として、どうして default が rsh でそれを ssh に置き換える方法を探すのにこんなに苦労するんじゃッ。何も訊かず rsh/ssh を一つのモジュールでやるからには自前で判別して使える方を使うのかと期待したじゃないか。最後には、自前でリモートホストの login shell の判別をやった挙げ句に sh(bash)/csh(tcsh) 以外のことを考えてなくて勝手に ~/.profile を見に行ってコケる始末。 zsh だからそんなのな〜いっつーの。
そして、 mpi 化したプログラムを起動するのに夜中までかかってしまう体たらく。
build に使った俺の Mac (n0) と、そいつを持っていった別の Mac (n1)、そして private にぶら下がる FreeBSD (n2) とホストがあって、どれも mpirun で自ホスト指定で実行させると動くのに、複数ホストで動かそうとすると駄目。
これが、「どのホストから」「どのホストとどのホストを含めて」実行させようとしたかでエラーが出たり出なかったり、密かに process はあがってるんだが mpi_init 待ちでだんまりだったりどこで死んでるのかさっぱり判らん、っつーか調べようがない。このホストのプロセスがシグナルいくつで死んだと通知はされるものの、だ〜れが殺したなんとやらで、誰に殺されたのかが判らなくて手の打ちようがない、ウッキ〜〜〜。
ターゲットを OS が同じ２台の Mac に絞ってあれこれやってると、俺のマシンから kick すると起動されないがリモートのマシンから kick すると起動されるところまで行く。なんでだ？ナニが違う？なんどやっても向こうから kick すればちゃんと計算できるのに、ローカルホストからだと駄目
この謎がどうにも解けなくて、最後に自分のマシンにダミーユーザを作って、そいつで同じことやってユーザ環境の所為じゃないことを確かめてやっと前進。
1) lamboot を実行したホストでは lamd に起動されたプロセスは lamboot が実行されたディレクトリを見ているくさい
2) リモートホストでは lamd に起動されたプロセスはホームディレクトリ上で動いているくさい
3) どうもこのプログラム、各 slave もカレントディレクトリからファイルを読み込むらしいっ。萎え〜〜〜〜〜〜(o_ _)o
ふつー master でファイル入出力して slave は計算だけするようなデザインにしないか〜〜
要するに、リモートホストから実行された時は、リモートの側のカレントディレクトリに必要なファイルがあり、リモートに取ってのリモート、もともと lamboot を実行した俺の計算機の側では、必要なファイルがあるところで lamboot を実行していたという……。
で、ついでに master は origin ホストで動くようで最終結果はリモートから実行されてもローカルホストに落ちてるんだが……。
これ以上はプログラムの作者を小一時間問いつめないと駄目だな。
とりあえず、 XLF/XLC を使って LAM を野良 build。
一見 make は通るんだが、いざ install しようとすると何故かライブラリを作り損ねている罠。
これが libtool を経由していて、誰が阿呆で作り損ねているのかさっぱり判らない。
generate された libtool 自体がンポなんじゃないかいな？
ともかく autoconf ものは、何か問題があった時に追っかけるのが困難でかなわん。そういや configure も env F77=xlf を無視して f77 でオプションチェックやってやがったぞ。幸い f77 は xlf への symlink だったからいいものの、諸般の事情で別の f77 が見つかるようなシステムだったらどうしていたものか
どうも autoconf ものにはいい思い出がなくて、作者と同じ環境以外では build させないためのツールじゃなかろうかと思ってしまう。
ちなみに、 FreeBSD 環境では PGI Fortran のパフォーマンスを捨てがたかったので Linux の方で LAM を build しようとしたら、ずいぶん昔に買ったものと見えて C++ が微妙に転けまくる。 std::hoge で no instance of overloaded function とか言われると萎えるぞ。
結局もう一つソースツリーを展開して gcc を見つけさせて configure; make して、問題の部分のログを diff したり、ソースツリー自体の diff を取ったり。
やっぱり cc の挙動の違いから必要なコードの足りない libtool が generate されてるようだ。
やはり cc は gcc 以外あり得んか
うーむ、よそで build して持ってくると target の path なんかがバイナリに埋まってるぞな。持ってくる先の環境に合わせて、むこうで build しとかんと駄目かいな？
env F77= してたが、よくみると FC というの別にある罠。
なんとなく気まぐれでアイロンなんか買ってみる。
どうせ滅多に使わないので極力小さなものを、と探してみると、小さい奴はあるんだがみんなでかい base station つき……(--;;;
使われずに放置されてる時間の方が圧倒的に長いのに、その状態でスペース喰い続けてるのはイケてないのでもっと安っちぃので探す。適度に小さくて軽いので３４８０円。でいざ買おうとすると在庫がないと平気でいう近所のケーズデンキ。マタカヨ。在庫ないものを並べておくなよ。
展示品で良ければ言うので、「展示品なら安くなるよな」と儀礼的に返して５００円引き。
ひょんなことで見つけた MPI の実装
わしは PVM の人だったんで MPI は使ったことなかったんだが、さすがに今じゃ MPI じゃないと駄目だろ
最近使わせられてる MacOSX もサポートしててヘテロな環境もオッケー。 fink にも ports にもあって、こりゃ楽しめそうかと思ったら、 fink/ports のは major version で古いし、うっかり package に頼ればライブラリが g77 で make されてパフォーマンス気にしてコンパイラ選ぶと命名則が噛み合なかったり、 package をコンパイルするところまで干渉すると実行ファイルとともに MPI のシステムまで配付して管理しなきゃいけなそうでなんか旨味がないなぁ
某IBMのC++コンパイラ、 C++ と C で実行コマンドが違うのはよくある話だが、こいつはコマンド名が xlC と xlc で挙動を切り替えている。
それはまぁありそうな話なのでなんとも思わなかったんだが、今日になって急に気が付いた。このファイルシステム case insensitive だから xlC と xlc の区別ないじゃん。
調べてみると bin ディレクトリには xlc しかない。 case insensitive ってことは、こいつが xlC でも XLc でも実行されるってことだ。
簡単な shell script 書いて試してみたが argv[0] には、ちゃんと case sensitive なのが渡ってる。まぁ、当たり前っちゃあ当たり前なんだがなんか気になる挙動だな。
なんか、 PowerMac G5 買う上司（先日のとは別）が、今使ってる G4 1GHz dual + mem 1G くれるいうんだが、いまいち使い道思い付かないな。あえて *BSD にしてもどの程度メリットあるんだか…
新人がシミュレーションの計算をまわす都合で、何故か上司の計算機にアカウントが発生。
PowerPC G4 1GHz dual にメモリ 1G というマシンで、俺の PowerBook と CPU は同じなので速いとは思わないが dual なのはうらやましい。ちなみに、 120G の HDD が 110G まで埋まってるんですけど(^^;;;;
しかし developper tools も X11 もコンパイラもないし、かといって環境作るには HDD 厳しそうだしで使う気があまりおこらんな。 chsh はあるけど、 Netinfo なのでログインしてのシェルのシェルの変更は無理か。うーむ、コンソールからやらンと駄目なのか、面倒だな。
CVS で access する都合で何故かで同僚の FreeBSD box にアカウントが発生。
Pentium4 2.6GHz というマシンで速くてうらやましい。儂が最後に買ったマシンは D3 の時の Pen3 で、まだ火は入れているけどさすがに遅いのよ。
coda client を MacOSX 上で build してみた。
coda と言えば AFS から生まれたネットワークファイルシステムで、クライアント側にキャッシュを遺すことでディスコネクトも可能と言う奴である。
と思ったが、 coda client は kernel に coda filesystem 組み込んで /dev/cfs にアクセスできないといけないようだ。うーむ、 MacOSX で kernel hack か…
参照： Japan.internet.com LinuxTutorial - Linux 用 Coda 分散ファイルシステム
職場ではよくどこが主催しているのか、なにやら判らん講習会や講演会をやっていて、館内放送で参加の呼びかけがあるのだが今日のは凄かった
曰く、 Windows Update に関する講習会(o_ _)o
確かに職場でも worm が流行っていたりしてたまに怒られてる人がいたりするので大事だとは思うが、「そういう機能があります。実行しましょうね」以外のナニを教えられるというのだろう
[referer: [an error occurred while processing this directive]]
« 2003年09月 | Main | 2003年11月 »
2007年12月 2007年11月 2007年10月 2007年09月 2007年08月 2007年07月 2007年06月 2007年05月 2007年04月 2007年03月 2007年02月 2007年01月 2006年12月 2006年11月 2006年10月 2006年09月 2006年08月 2006年07月 2006年06月 2006年05月 2006年04月 2006年03月 2006年02月 2006年01月 2005年12月 2005年11月 2005年10月 2005年09月 2005年08月 2005年07月 2005年06月 2005年05月 2005年04月 2005年03月 2005年02月 2005年01月 2004年12月 2004年11月 2004年10月 2004年09月 2004年08月 2004年07月 2004年06月 2004年05月 2004年04月 2004年03月 2004年02月 2004年01月 2003年12月 2003年11月 2003年10月 2003年09月 2003年08月 2003年07月 2003年06月