朝方はちっと寒いかなあという程度だったのに,浜松からの帰宅時はものごっつぅ風が強い上に寒気がきっつぅ,という状態に。北極直輸入の寒気団が南下したようで,明日は日本海側は大荒れの模様。太平洋側は天気は良いものの,風の強い寒い一日となるようである。
帰宅して風呂に入ったら途端に眠気が襲ってくる。本日のノルマ,定義1.2を訳して寝ることにする。明日は東京。お休みなさい。
12/18(木) 掛川・晴
昨日に引き続いて忘年会。さすがに本日はnon alcoholにて勘弁して頂く。おかげでちょこっと飲み代が浮いた。
カラープリンタを購入する。年賀状印刷たけなわの時期だけに,販売店も力が入っていて,おまけに年賀状印刷ソフトだの印刷用紙だの予備のインクカートリッジだのを付けてもらう。早速,高大一貫の資料を印刷してみる。うげげ,高速だわ,にじみは少ないわ(それでも品質はLaserに劣る),何よりカラーが滅茶苦茶きれい。Magenta, Cyan, Yellow, Blackの4色しか使ってないのにねぇ。これでますます銀塩カメラから縁遠くなるな。
Iraqで元独裁者が捕まったというニュースの際,Baghdadの市民が歓喜のあまり銃を撃ちまくっている映像が流れた。あれは空砲じゃないよなあ,危ないなあ,と思っていたら,案の定,被害者が出てたのね。全く,この世は悲劇も喜劇もごた混ぜだぁ。
翻訳,定義1.1のみ終了。昨日よりは,カタツムリのしゃっくり程度の進歩が見られる。早く人間になりたーい(わしは再放送を見ていた世代)。
「方程式を解いてみよう!」
12/12の高大一貫講義で使った資料。Internet Explorerでのみまともに見られます。
http://na-inet.jp/research/dka2003.htm
Excelでない表計算ソフトでも実行可能なようにしてあります。
12/17(水) 掛川・晴?
ゼミの忘年会帰りで酔っぱらい状態。んで,これを書いているので,天気はうろ覚え。とりあえず寒かったことだけは確か。〆の鶏雑炊はうまかったです。
どういう訳か,当ゼミにはヲタクが多いという噂が立っているようである。教師にはその気が皆無であるにもかかわらず,不思議なこともあるものである。思うに,先人のゼミ生にヲが混じっており,それが伝染して今日に至っているのであろう。これがヲ濁という奴であるな。
忘年会の前に,三年生諸君にはPCを組み立てて貰った。いやぁ,若い力は素晴らしい。これで大枚2枚を叩いて済むんだから,安い出費である。全員で組み立てているのを見ていると,昔のマ○ポーシ○を思い出してしまった。確か今でもPC関連の会社が存続しているんだよな。
久々にGSLの本家,Network Theory社のサイトを覗くと,ありゃまあ,まるでGNU book centerの様相を呈している。以前はWebページがDLできたGSLのWindows版も,今じゃCD-ROMを購入せねば入手できなくなっている。やっぱり数値計算ライブラリだけじゃあ商売にはならないのだろう。昔,F博士が某ライブラリを商品として販売するための有限会社を作ったことがあったが,私が知る限り,売れたのは1件だけだった。そのうちF博士が病気になって自然消滅してしまったが,洋の東西を問わず,商売というのは難しいモンですな。
翻訳,酔っぱらいつつ3行。毎日でも続けることに意義がある(とでも思わないとやっていられない)。
12/16(火) 掛川・晴
毎度のことながら,予算だのカリキュラムだのの話し合いは面倒なことこの上ない。結局,次年度以降はネットワーク関連の講義からは全面撤退となる。旧カリキュラムの一講義が残るが,これも次回限りである。実験講座も数値計算がらみのものに再編成し,きれいさっぱり。
それはいいのだけれど,具体的に何をするかは全くの未定である。いくら何でもゴリゴリの数値計算は無理なので,グラフィックスやらPthreadやらと関連づけた応用指向の内容になるだろうな。またテキストを書き下ろさないと・・・面倒だが楽しみでもある。定番のMandelbrotやらJuliaやらを描いて,なるべくならOpenGLともからめて・・・なんて,考えるだけなら簡単なんだがなぁ。ま,これからは業績にもならない仕事は引き受けないことにしよっと。
つらつらと,M$のHPC Toolkitなるものを眺めてみると,えらい豪華バージョンなのは驚く。最もEvaluationが殆どで,短期間しか使用できそうもないところがみみっちい。送料だけで入手が出来るとのことなので,早速注文する。正月明けには届くかな?
前々から気になっていたので,ARPRECとMPFRの四則演算速度を比較してみた。この2者は実装方針がまるで違っていて,前者の多倍長浮動小数点は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の方がずっと高速になる。これ以上は研究上のし・み・つ(という程,大層なものではないけど)。