6/4(金) 掛川・晴

 爽やかに晴れ上がった。気温も高くなく,5月初旬の気候。
 職場のメール遅延は,GWにbombが殺到したためらしい。本日午後には復旧したとのこと。うちみたいな無名かつ小規模な所まで来るんだから,有名かつ大規模な所の管理者は日々大変な努力を強いられているんだろうなあ。空気のようにいつもネットワークが使えている,という状態を維持することがどれだけしんどいことか,経験のない人にとっては想像できないだろうな。
 Athlon64マシンに,Fedora Core 2 for x86_64とi386版をインストールし,dual bootableな構成にした。もちろん,どちらも英語環境である。すると,あらら,あれほど使い物にならなかったx86_64バージョンのGNOMEもさくさく動くじゃぁあーりませんか。もちろん,Terminalは正常に動作し,Mozillaも日本語のencodeは正常に行われ,ちゃんとこのWeblogも読むことが出来た。
 で,早速両環境でMPFRbenchを行う。・・・うーん,やっぱり64bit環境は偉大である。ベースライブラリのMPNはC generic codesでコンパイルされており,tuned assembler codesは一切使っていないにもかかわらず,である。
 こりゃ,自宅のPCも職場のClusterも,安定したx86_64 OSが出揃うまで更新しない方が良さそうですな。あと2年ぐらいは存分に活躍してもらいましょうぞ。・・・ってことは,自宅のPCのバヤイ,RAID化したのが一昨年の8月だから,今年の8月で丸2年,その後2年使い続けると,4年もお付き合いすることになるのね。毎年のようにマシンを買い続けた昔が嘘のよう。それだけPCは能力の限界(つーか,熱問題解決能力の限界と言うべきか)に達しつつあるんだなあ。Celeron 1GHzのWin2K Proマシンでも全然不満が湧かないのであるから,OSも良くなったってことかしらね。

6/3(木) 掛川・曇

 取り急ぎ業務連絡のみ。
 本日(6/3),tkouya(here is atmark)cs.sist.ac.jp宛にメールを送った方へ。どうも全てのメールが不着になってしまっているようです。送信者にエラーも返らないようなので,気が付くのが遅れました。すいませんが,私宛に連絡を取りたい方はtkouya(here is atmark)na-net.ornl.govまでメールを再送して下さい。よろしくお願い致します。
 ・・・どーりで今日の午後は静かだなあと思ってたんだよな。いい機会なので,届いているメールでも不着になったことにして,バックれることにする。ほっほっほ。
 ボチボチ,不着だったメールが届きだした。ヘッダを見る限り,学内・学外を跨ぐFWで糞詰まり状態だったようで,数時間の遅延が発生している。届く順番も滅茶苦茶だし,最終的には届かないものも出そうである。
 ということで,大事な用事がある方は,上記アドレスまで再送お願い致します。

5/28(金) 掛川・晴

 昨日で,cs-pccluster2のケーブル整理作業が終了した。
switches.jpg
 パケットが伝送される状態を観察できるようにするという目的は果たしたものの,さすがに二十数本分のTwisted-pairケーブルを束ねるとかなりの太さとなり,それらがまとめてSwitchに突き刺さっている様は,さながら人体解剖図のようで生々しい。Bladeサーバを使っているブルジョアさん達が普段は触れられない,隠蔽されている光景がここにはある。まあ,無線LANが高速化されれば,少なくともこの半分のケーブルは消滅するのであるが。
 お手伝いをお願いしていた学生さんが到着する頃にはあらかた作業は終わってしまっていたので,お掃除のみお願いし,これで全ての作業が完了した。これで先日インタビューを受けた方に,このclusterの写真を撮ってお送りすることが出来る。と言う訳で一番見栄えのする(といっても単なるPC室にしか見えない)部分を切り取って先方へお送りする。
 余勢を駆って,懸案だったWin32環境で使えるgmpとmpfrを,Visual Studio .NETでコンパイルする。C onlyのgenericコードを使ったものはワシも作ったし,他にもあるが,CPU毎にtuneされたassemblerコード,しかもWin32で使用できるものはGladmanさんのものしか知らない。しかし,こいつは.NET環境専用になっちゃっているので,「いつか見ておれワシだって」とばかりに,機会をうかがっていたのである。MSDNを手に入れた今日,ワシに障害はないのである。ちらっとVineにて,generic onlyのgmpとtuned asmsを使ったものでベンチマークをやってみたが,10倍の差が出てしまった。やっぱり速さは命,gmpにはasmコードが必須であるのだなあ,と改めて感じる。
 オリジナルはP4向けのasmをリンクしていたので,それをそのまま使ったものと,P3向けのasmを使ったものの2種類のDLL/Export lib, Static libを作る。作業としては大したものではなかったが,統合環境の中で「あっちのasmを無効にしてこっちのgeneric Cを有効にして・・・」などと,マウスでちくちく変更する作業は不毛なものであった。こっ,こんなものー,Makefileをしっかり書いておけば一発じゃんっ。VC++.NETにはちゃんとnmakeが入っているのだから,その気になれば可能なのであるが,.NET使いは統合環境しか眼中にないのか? まあ,無事にlibが出来たので,ついでにBNCpackもコンパイルして多倍長計算が動くことは確認できたところで疲れて帰宅。これでMPIBNCpackが使えるようになれば完璧。夏休み前には何とかなるかしらん?
 ふーん,Note PCのバッテリリフレッシュサービスなんてのがあるんだ。覚えておこう。

5/27(木) 掛川・曇

 Cluster部屋の模様替え作業中につき,肩が凝る。今日で終わるかしら?
 Windows HPC Edition(/.J)ねぇ。まあ考えそうなことではあるけど,C#の押しつけはやめて欲しいな。それに,MPI以外の選択肢がないのは,商用Clusterとしてはいかがなものか。OpenMPぐらい使えるようにしてくれてもバチはあたらんだろう。
 しかし,よくこんな記事がたれ込まれたな~と思っていたら,・・・あ,投稿した人を見て納得。

5/25(火) 掛川・晴

 良い天気だったような気がするが,はてどうだったか? 随分涼しい。ここんと寒暖の差が激しすぎて,体調を崩す人が増えたようだ。ゴホゴホと咳をする人に対しては「お大事に」と口先だけの言葉をかけつつ,「ワシに写したら承知せいへんでぇ」と内心では脅しをかけるのであった。
 やっとAthlon64 3200+(2GHz)のマシンにFedora Core 2 for x86_64をインストールできたので,早速MPFRでベンチマークテストをしてみる。使用したプログラムはこちら
 それぞれの演算,関数の時間(ms)を計測し,Athlon64の時間を1として,Pentium IV 2.8GHz, Xeon 3.06GHzマシンでの時間の比をグラフにしてみた。10進100桁計算の結果と,10000桁計算の結果をそれぞれ示す。
mpfrbench_100.png
mpfrbench_10000.png
 いやぁ,GMPのx86_64向けtuneの成果か,はたまた64bit環境のおかげか,周波数では最も劣るAthlon64が,P4の1.x倍, Xeonの2倍~3倍高速なのはちょっと驚き。まあ,32bit環境と64bit環境とでは,そもそも桁の取り方が異なっているので,比較としては公平ではないのだが,それでもこれだけ違うとちょっと考えさせられる。うーん,Athlon64 Clusterを目指すか?
 とまあ,計算自体はよろしいのだが,Fedora Core 2 for x86_64のGUI環境は,ハッキリ言ってメタメタであり,使い物になるレベルではない。日本語環境にすると,Terminalの起動でエラーが発生して何にも出来ない。暫くはファイルサーバとして使用するしか,仕方がない代物である。・・・と文句ばっかり言って,何の手助けもできない一ユーザだから,暫くは様子を見るしかないのであった。