天気予報通り，さぶい朝。東海道新幹線も一部区間(掛川-京都)で徐行運転を余儀なくされているようだ。少し咳も出る。一週遅れの感冒か？
昨日アップした高大一貫講義の資料，早速５人に見て頂いたようである。みんなめざといなあ。しかし面白い内容じゃぁないと思うがなあ。先方さんには不評だったみたいだし。
そーいや，Linux kernel 2.6.0が出たんですね。わしみたいな零細PC Cluster遊び人にはあまり関係がないかなぁ。
Fedora Core 1本も２冊程登場していましたな。正式リリースのタイミングを狙っていたとおぼしいが，さて売れますかな？ Score 5.6.1のインストール手順でも書いてくれているんなら買うんだがなぁ。
ではぼちぼち行って参ります。8:22発のこだまに乗る予定だったが，どーせ遅れるんだったら一本早い7:43発を使った方がいいな。ということでそろそろ身支度をせねばならぬ。今日は車中で翻訳作業予定。どこまで進められるかなあ，と人事のように言ってみたりするテスト(年がばれる言い回し。漏れもヲヤジが入ってきたなあ)。
一旦帰宅。掛川駅の新幹線ホーム下では遅れている7:43発のこだまを待つ人で混雑していた。20分遅れだそうで，一旦戻ってきた次第。しかし，この有様では列車もかなり混雑していそうなので，やっぱり予定通り次の8:22発こだまで出発することにする。これなら５分遅れで到着予定なんだそーな。名古屋～関ヶ原の雪が溶ければ平常ダイヤに戻るだろう。・・・久々に「うだうだ」書いてますな。雪のおかげ。・・・まだ時間があるな。ではまだうだうだしよう。
考えてみれば来週も東京なんだよなあ。毎年年末，というか12月は当でする機会が多い。交通費だけでボーナスの残りカスが全て消えてしまうのである。やるせない。
では今度こそ行ってきまーす。
12/19(金) 掛川->浜松->掛川・晴後曇
朝方はちっと寒いかなあという程度だったのに，浜松からの帰宅時はものごっつぅ風が強い上に寒気がきっつぅ，という状態に。北極直輸入の寒気団が南下したようで，明日は日本海側は大荒れの模様。太平洋側は天気は良いものの，風の強い寒い一日となるようである。
帰宅して風呂に入ったら途端に眠気が襲ってくる。本日のノルマ，定義1.2を訳して寝ることにする。明日は東京。お休みなさい。
12/18(木) 掛川・晴
昨日に引き続いて忘年会。さすがに本日はnon alcoholにて勘弁して頂く。おかげでちょこっと飲み代が浮いた。
カラープリンタを購入する。年賀状印刷たけなわの時期だけに，販売店も力が入っていて，おまけに年賀状印刷ソフトだの印刷用紙だの予備のインクカートリッジだのを付けてもらう。早速，高大一貫の資料を印刷してみる。うげげ，高速だわ，にじみは少ないわ(それでも品質はLaserに劣る)，何よりカラーが滅茶苦茶きれい。Magenta, Cyan, Yellow, Blackの４色しか使ってないのにねぇ。これでますます銀塩カメラから縁遠くなるな。
Iraqで元独裁者が捕まったというニュースの際，Baghdadの市民が歓喜のあまり銃を撃ちまくっている映像が流れた。あれは空砲じゃないよなあ，危ないなあ，と思っていたら，案の定，被害者が出てたのね。全く，この世は悲劇も喜劇もごた混ぜだぁ。
翻訳，定義1.1のみ終了。昨日よりは，カタツムリのしゃっくり程度の進歩が見られる。早く人間になりたーい(わしは再放送を見ていた世代)。
12/17(水) 掛川・晴？
ゼミの忘年会帰りで酔っぱらい状態。んで，これを書いているので，天気はうろ覚え。とりあえず寒かったことだけは確か。〆の鶏雑炊はうまかったです。
どういう訳か，当ゼミにはヲタクが多いという噂が立っているようである。教師にはその気が皆無であるにもかかわらず，不思議なこともあるものである。思うに，先人のゼミ生にヲが混じっており，それが伝染して今日に至っているのであろう。これがヲ濁という奴であるな。
忘年会の前に，三年生諸君にはPCを組み立てて貰った。いやぁ，若い力は素晴らしい。これで大枚２枚を叩いて済むんだから，安い出費である。全員で組み立てているのを見ていると，昔のマ○ポーシ○を思い出してしまった。確か今でもPC関連の会社が存続しているんだよな。
久々にGSLの本家，Network Theory社のサイトを覗くと，ありゃまあ，まるでGNU book centerの様相を呈している。以前はWebページがDLできたGSLのWindows版も，今じゃCD-ROMを購入せねば入手できなくなっている。やっぱり数値計算ライブラリだけじゃあ商売にはならないのだろう。昔，F博士が某ライブラリを商品として販売するための有限会社を作ったことがあったが，私が知る限り，売れたのは１件だけだった。そのうちF博士が病気になって自然消滅してしまったが，洋の東西を問わず，商売というのは難しいモンですな。
翻訳，酔っぱらいつつ３行。毎日でも続けることに意義がある（とでも思わないとやっていられない）。
12/16(火) 掛川・晴
毎度のことながら，予算だのカリキュラムだのの話し合いは面倒なことこの上ない。結局，次年度以降はネットワーク関連の講義からは全面撤退となる。旧カリキュラムの一講義が残るが，これも次回限りである。実験講座も数値計算がらみのものに再編成し，きれいさっぱり。
それはいいのだけれど，具体的に何をするかは全くの未定である。いくら何でもゴリゴリの数値計算は無理なので，グラフィックスやらPthreadやらと関連づけた応用指向の内容になるだろうな。またテキストを書き下ろさないと・・・面倒だが楽しみでもある。定番のMandelbrotやらJuliaやらを描いて，なるべくならOpenGLともからめて・・・なんて，考えるだけなら簡単なんだがなぁ。ま，これからは業績にもならない仕事は引き受けないことにしよっと。
つらつらと，M$のHPC Toolkitなるものを眺めてみると，えらい豪華バージョンなのは驚く。最もEvaluationが殆どで，短期間しか使用できそうもないところがみみっちい。送料だけで入手が出来るとのことなので，早速注文する。正月明けには届くかな？
前々から気になっていたので，ARPRECとMPFRの四則演算速度を比較してみた。この２者は実装方針がまるで違っていて，前者の多倍長浮動小数点はIEEE754浮動小数点をつなぎ合わせて実装しているのに対し，後者は整数演算をベースに下から積み上げて実装されている。どーも，浮動小数点数に限っては，前者の方が高速ではないかと感じていたので，ちみっと簡単なベンチマークプログラムをでっち上げてみた。環境は次の通り。
コンパイル条件：GCC, G++ 3.2.2, オプション： -O3 -funroll-all-loops
ハードウェア： Intel Pentium III 800MHz,OS: RedHat9
ショボくてすまん。んで，結果は次の通り。
1024 bits(308 decimal digits)の場合(単位はMFLOPS)
ADD 3.333333e-01(ARPREC), 1.58025e+00(MPFR)
MUL 2.222222e-01(ARPREC), 1.04235e-01(MPFR)
DIV 7.207207e-02(ARPREC), 6.99597e-02(MPFR)
2048 bits(616 decimal digits)の場合(単位はMFLOPS)
ADD 3.478261e-01(ARPREC), 1.03226e+00(MPFR)
MUL 2.222222e-01(ARPREC), 3.40426e-02(MPFR)
DIV 4.266667e-02(ARPREC), 2.25989e-02(MPFR)
4096 bits(1233 decimal digits)の場合(単位はMFLOPS)
ADD 3.478261e-01(ARPREC), 7.03297e-01(MPFR)
MUL 2.162162e-01(ARPREC), 1.11732e-02(MPFR)
DIV 2.308802e-02(ARPREC), 6.86695e-03(MPFR)
8192 bits(2466 decimal digits)の場合(単位はMFLOPS)
ADD 1.403509e-01(ARPREC), 4.26667e-01(MPFR)
MUL 1.066667e-01(ARPREC), 3.70199e-03(MPFR)
DIV 1.218583e-02(ARPREC), 2.11640e-03(MPFR)
うーん，確かに桁数が増えると，ARPRECの方が，特にMUL,DIVで高速になっている。しかし，1024bits(308 dec.digits)では危惧していたほど差は出ていなかった。8192bits(2466 dec.digits)が「実用的」な桁数かどうかは議論の分かれるところだろうが，おおむね，「んなに計算してどないすんねん」レベルと見ていいだろう。つーことで，Piやeの世界記録を狙いたいという向きはARPRECを使えばよろしい。関数機能も豊富なのでお勧めする。
で，わしはと言えば，今のところGMP+MPFRから乗り換えるつもりはない。もちっと原因を調べてからでも遅くはないと考えている。64bit addressingになってしまえば改善するものなのかどーか，cacheのhit率を上げることで改善できるものなのか，HTやSMP環境でPthread並列化すればどーか，等，調べることはいっぱいあるし。ARPREC使うなら，Template使ってBNCpack++を作った方がよろしかろうて。
それよりも，ARPRECは1024bits以下の桁数にしてもこれ以上の速度改良がみられないのが問題なのである。この場合，MPFRの方がずっと高速になる。これ以上は研究上のし・み・つ(という程，大層なものではないけど)。