12/15(月) 掛川・晴

 うう~,寒いぃ~。12月も半ばを越えようとして,冬将軍が空っ風と共にやってきたようである。灯油の消費量が増えるなぁ。
 これから翻訳作業が一段落するまで,このWeblogを毎日更新することにする。もうのっぴきならないのである。今週末には下書きをでっち上げねばらならない論文が2本もあるが,それと平行して作業を進めねば正月明けの脱稿には到底間に合わない。・・・などといいつつ,本日は気力がなくて6行のみ。先が思いやられる。
 トップページのカウンタが7000を越えていた。歳末にはアクセスがガタ減りするだろうから,あと500ぐらいアップすればめっけもんかなぁ。しかし,何が面白くって人のページを覗くのであろう。ちっと不思議。

12/14(日) 岐阜->掛川・晴

 昨日は移動中に雨がぱらついていたが,午前中はよい天気であった。東海北陸自動車道の川島PAでは白猫がちんまりとひなたぼっこをしていた。
whitecat.jpg
 本日もそれに引き続いて良い天気である。わしの講演は時間切れにて次回(?)回しと相成った。それまでに完璧にしておけというプレッシャーとも言える。ついでに,またぞろ査読を依頼されて引き受けてしまう。全く,人の論文ばっかり批評して,自分ではロクに書けていないというのは,まるでいしかわじゅんのようで大変によろしくない状況である。これから年末にかけて,じっくりたまった仕事を向き合わねば。
 フセイン元大統領拘束とのニュースが飛び込む。農場の物置小屋に掘られた地下室に籠もっていたそうだが,まるで某教団の教祖様である。$750Kを抱えていたってところも同様。独裁者の末路はゼニと道連れ引きこもりってのが定番の絵になるのであろうか。
 翻訳,II-0を終了。これから年明けまでにII-9まで,なんとしても終了せねばならぬ。毎日一行ずつでも進めることにする。

12/13(土) 掛川・?

 天気なんぞこの際どうでもイイ。やっと今日からのワークショップ用資料をでっち上げることが出来た。結局新しいことは何も出来ず,出来損ないのsurvey止まりである。うがーっとなってPPTファイルを作っているところへ,第2回目の査読依頼メールが届く。ああもぉ,マーフィーはどこまでついて回るのか。解答書と修正論文のみをプリントアウトして帰宅。今日は遅くとも8時過ぎには出発しないといけないので,さっさとかえって寝るのである。でもしばらく更新が途絶えていたので,こうやってわずかの時間を惜しみつつ,日記を書いているという次第。
 今度こそ寝ます。

12/8(月) 掛川・晴

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

12/6(土) 掛川・雨

 しとしとと氷雨の降る師走の土曜日。今日もシコシコプログラムを作る。
 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
Thread 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」を読みながら寝ることにする。