うだうだWeblog2

　忙しさ絶好調。書類の催促が来るわ，講義で計算を間違えるわ(いつものことだが)，研究室のブレーカーは落ちるわ，説明会の案内は来るわ，会議があるわ，金はないわ（ボーナス支給日を勘違いしていた)，もてないわ，研究会の準備は全く出来てないわ，こーゆー時に限って別の作業をしたくなるわ，DVでビデオ取りしていたら録画できていないわ，卒研生は寝坊するわ，つられてわしは早寝になるわ，事前申し込みしていたPC Cluster シンポジウムには出席できそうにないわ，翻訳作業は全く進んでいないわ，未処理伝票は一向に減らないわという大騒ぎの最中に，発注していたcs-pccluster2の部材が一挙に届いてもう大笑いさ。
　全ての準備が整ったので，次週には若い力を結集して，P4マシンを組んで頂くことにする。ホントは全部自分一人でやりたいところだが，こう忙しくてはどうしようもない。今週がピーク。次週は少し落ち着くだろう。

　しとしとと氷雨の降る師走の土曜日。今日もシコシコプログラムを作る。
　Pthreadを使って，Fedora Core 1を突っ込んだP4 2.8C GHzのマシンでベンチマークテストをする。多倍長でやってみると，どうも倍精度よか性能向上がいいようである。うーむ，これはすげぇ。多倍長だと内積計算でもmulti-thread化の効果期待できそうである。MPIBNCpackが一段落ついたと思ったら，大本のBNCpackを改良しなきゃならんのかぁ。全く高速化技法って尽きることがないよのう。
　で，気がついたのだが，このマシンで2threadsを使ったプログラムを走らせて，timeコマンドを使って時間計測をすると
real 1m28.966s
user 2m55.700s
sys 0m0.200s
などという結果になる。最初見た時は，松田優作ではないが，「なんじゃこりゃー」と叫んでしまった。どうやら2thread走らせると，それぞれのthreadのuser timeを合計した値が出てくるらしい。実際にはrealの時間で処理が終わっている。
　で，times関数をmanしてみると，案の定であった。しかもLinuxの場合，こちとらThreadを使った気になっていても，KernelではProcessとして認識しているようである。実装がそうなっているからなんだそーだが，これって手抜きなの？
　ためしに，メイン処理からtimes関数を呼び出してみると，開始時点では
User Time : 109
System Time: 14
CUser Time : 1029
CSystem Time: 1
となっているのに対して，終了時には
User Time : 113
System Time: 14
CUser Time : 17457
CSystem Time: 4
という有様である。この時走った2threadのそれぞれで同じくtimes関数を呼び出してみると，thread 0では
Thread 0 開始時
User Time : 0
System Time: 0
CUser Time : 0
CSystem Time: 0
Ｔｈｒｅａｄ 0 終了時
User Time : 8206
System Time: 1
CUser Time : 0
CSystem Time: 0
となり，thread 1では
Thread 1 開始時
User Time : 0
System Time: 0
CUser Time : 0
CSystem Time: 0
Thread 1 終了時
User Time : 8222
System Time: 2
CUser Time : 0
CSystem Time: 0
となっている。つまり，メイン処理部ではtms構造体のうちcutimeが，それぞれのThreadに費やされたutimeの合計値を保持するようになっている。これでは1 CPUで行ってきた時間計測手法が全く通用しない。
　結局，実時間をgettimeofday関数を呼び出して計測することにしたが，おかげでBNCpackの時間計測関数がまた増えてしまった。今までは1CPUマシンでしか動かしたことがなかったので，times関数を使うget_sec関数という奴しか実装してなかったのである。今回，新たにgettimeofday関数を使う，get_real_sec関数なるものを実装したのである。ああめんどくさ。
　しかし時間計測はやっかいである。今回生じたMT環境での事柄もそうだが，大体，ベンチマークなんぞ，実行するたんびに微妙に食い違うのはざら，というより当たり前のことである。バックで様々なプロセスが蠢いているためでもあろうし，割り込みが入るタイミングも違うであろうし，何よりPCのハードウェアタイマなんてどこまで当てになるのやら。信頼性があるようなら，NTPなんて無くなっていいはずである。で，NTPなんぞマジメにインストールしようモンなら，そこで修正される時間も問題になろうし，ニュースにもならない「うるう秒」も入り込むかも知れないし，大体，今こうやってプログラムを動作させている3D空間中の「時間」とやらが完全に一体化しているのかどうかも怪しい。ああもぉキリがないのである。故に時間計測なんぞにうつつを抜かしてはいけない，という結論を得る。
　今日で一仕事終える予定だったのに，またぞろやることが増えてしまった。ストレスを新たに抱え，明日に備えて「わしズム Vol.9」を読みながら寝ることにする。

　本格的な冬に突入しつつあるようだ。それでも平年より気温は高めに推移しており，ただでさえ暖かいここ遠州の地では，日中は上着が不要である。
　昨日はPthreadをP4 2.8CGHzマシンで初めて使ってみた。2 thread生成して実正方行列の積を計算する単純なプログラムなのだが，やってみると案外面倒である。それでもshared memoryなので，MPIで並列行列積をcodingするよりも楽に完成した。しかしみんなよくもまあ，こんなシチ面倒な手続きをするもんだ。やれやれとベンチマークを取ってみると，おおっーと感動する結果になっている。特に
，cacheコントロールなんぞを全く考慮していないBNCpackを使っていると，行列を分割しヒット率を上げる効果も加わって，計算時間が激減する。昨夜はこれを知って，深夜の実験室にてFedora Core 1に思わずほおずりをしてしまった。いやぁ，SMT万歳である。どーせしばらくはSMPマシンなんぞとは縁遠いままだろうが，このお安い(何せ\10万未満)P4 with HTでSMPを疑似体験して楽しむことにする。・・・しかし，プログラミングが面倒になるなあ・・・。
　何か参考になる資料はないかとGoogle様を漁っていたら，こーゆーPDFファイルがあった。プログラミングの詳細は不明だが，行列積のサンプルがある。
　で，忘れない内に書いておくが，pthreads for Win32ってのがあるのね。これもまたRedhatのご助力を得ているprojectのようである。イチイチWindows環境用にMT部分を書き直すのも面倒なことこの上ないので，うまく行けばソースレベルの互換性は保てる・・・かしらん？

　昨日は産学官連携フォーラムに出席。今年が初めてだったのだが，昨年よりも盛況だったようである。場所を移したのが吉と出たか。とある企業の方は，研究内容を紹介するパネルの数が少ないと言っていた。うーん，まあ，確かに。
　わしのパネルはモノクロレーザープリンタで打ち出したものだったが，周囲は全員カラー印刷。こうなったら暫くはカラーと縁遠いままでいようと開き直る。
　ぼーっとしている間に，企業との共同研究の話が出ている。果てさて，どうなりますことやら。そーゆーおゼゼの絡む仕事とは無縁で生きてきたからなあ。あまり期待しないで待っていましょうか。
　12月に入って，このWebへのアクセスは平均130人/day程度で推移している。まあまあというところか。次年度は非常勤の仕事もなくなりそうで，一番アクセス数の多い数値計算テキストを何とかせにゃいかんかなぁ，とぼんやり考える。大師匠に見せるためのサンプルとして，ちょこっと書き出しているが，やってみると難しい。何せ，テキストのフォーマットを根本から変えようとしているからなあ。大師匠のリクエストだし，何とか答えるべく努力はしてみよう。
　昨年の日記と比べてみると，ずいぶんと真面目になっている(笑)。落ち着いたっつーか，いいたいことをストレートに書かなくなったっつーか，つまりは順調に長いものに巻かれているのである。よきかな。昨年購入した自宅プリンタも活躍しているし，前に書いた通り，今年はPC関係の買い物の予定はない。Iraqでは外交官がテロの標的になったが，国内で引きこもっているわしの日常は，平和に過ぎて行きそうである。そんな師走。

　あーもー師走だー。教師でなくても社会人なら走り回る最後の月。頑張りましょう。しかし，その出鼻をくじく，ドンヨリ日より。気温も一向に安定しないし，調子が狂ってしまいそう。
　アリアドネMLから，「日本社会心理学会第44回大会ワークショップ　電子コミュニティの歴史的変遷と社会心理学－日本型blogは匿名掲示板？それともWeb日記？－」(長いなぁ)の資料が公開されているという情報が寄せられる。年表が結構役立ちそう。2chの議論が盛り上がるシステムの分析などもある。資料よか，直接講演を聴きたかったな。
　今日から地上波デジタル放送開始。まだ大阪・名古屋・東京の３大都市圏のみだが，いずれは全国に波及するようである。そうなると，視聴率の意味合いも変わってくるのかしらねぇ。