ぎょーむ日誌 2000-09-08

2000 年 09 月 08 日 (金)

• 0630 起床． 結局， 0130 から一睡もできないまま 夜があけてしまった． 神よ．
• 朝飯・弁当の準備． シャワー． 洗濯． 朝飯． 時間あるんで コーヒー飲みつつでれでれする．
• 0808 自宅発． 晴れ． ちょっと暑い． あ， 洗濯もの干すの忘れてた． うう． 0829 東京モノレイル流通センター発． 0848 研究所着．
• なーんか， 眠い， というより， だるい． 全体的に． いまのところは．
• filereader.h とか cooridinates.cc といった kubolib コンポーネントのソースコードを プリントアウトして 26 穴つき透明袋に入れて A4 用のバインダーにとじて 自家製リファレンスマニュアルにしてる， と以前に記した． それをつらつらと眺めてみると …… 「ヘッダーファイルでは メンバー関数として 宣言されてるけど， 実装部には対応するコードがない」 いわばアタマだけの生首関数が いくつか転がっているのを見つけた． こういうのも呼ばれないかぎりは， リンカーがエラー判定してくれないのである． とはいえ， もちろん気色悪いので即座に削除した．
• 眠くなってくる． 眠くなるとロクでもない 下らない作業に取り組んだりする． たとえば「代入狩り」． ``int i = 0;'' などという記述を見つけたら， 凶悪な異端審問官のごとく ひひひと (ココロの中で) 笑いつつ ``int i( 0 );'' と書き直してみる． こうすると， C++ を憎みつつ Fortran や C を愛する人々の神経を 逆なですることできる …… って朝から何をやってるんだ， 莫迦．
• なんか眠気というのは周期的に訪れてくる のかもしれない． あと， なぜかいきなり空腹になった． 大丈夫なのか， 私の神経系．
• 自作の開空度 (らしきモノ) 計算を行う voxelight の再検討． Gridworld というクラスで 面倒な計算をあれこれとやっている．
• 私は一つのファイルにたくさんのコードを 詰め込まないようにしてる． あんまり長いと 見直すときにしんどいので． ところが， Gridworld 実装部 gridworld.cc だけは例外的に 683 行もある． なんでこんなに長いのかというと， 一番計算に時間を食う Bresenham アルゴリズム 関連の関数にことごとく 「inline 化」 という処理を施しているのである．
• inline 化って何 ? というコトはまたいつか ご説明するとして …… 結論だけ述べると， この危なっかしい魔法を用いると 処理速度が向上 (することも多いけどそうじゃない場合もある) というご利益と引き替えに， ひとつのファイルに何もかも詰め込まねばならぬ という呪いがもたらされるのである． 高速処理を重視する Gridworld クラス実装部は それゆえに果てしなく長くなりつつある．
• とはいえ， 巨大なクラスは作った本人が見ても ぱっと分からない部分が増えてくる． 分離分割したい． そのためには inline やめたほうがよいかもしれない．
• ためしに Gridworld::BresenhamStep という 一番よく呼び出される関数の inline を 外してみることにする． PipeTree で実験． inline つけた状態だと 一本の樹木を 30 ステップ成長させるのに 4.9-5.0 秒かかる． で， BresenhamStep の inline を外すと 同じ計算やるのに 5.3-5.5 秒 ……
• うーん， 微妙だ． 最悪の場合で一割ぐらい遅くなる， と期待されるわけね． 樹木の本数増やすと， もっと影響が出てくるかも知れない． となると， やはり inline 外すのヤだなあ． でも巨大化しつつあるクラスも嫌だし．
• 知床モデリングやったときに， 地面に光が当たったときの計算やらせる 関数をいくつか導入したんだけど， これがまた長いんですよね． せめてこいつらだけでも分離しようと 思ってたのに．
• 答えが出ないまま休憩． 昼飯の弁当を食うことにする． お， 日立が Transmeta のチップ搭載 ノート PC を 11 月に発売， か． 予想価格 20 万円前後 …… ま， 最初の一年くらいはモルモット諸氏に がんばってもらってるうちに， 値段も下がって来るんでしょう ……
• 午前の終わりで悩んでいた問題を解決するべく， またまた邪悪な手法を試みる． すなわち inline 化された 関数のうち問題になりそうなものを ヘッダーファイルの下のほうに 書いてしまう， という手口を試みる．
• …… さーて， 必要なものを gridworld.cc から gridworld.h に移し， 静的ライブラリー lib_voxelight.a を 再構築． もいっぺん PipeTree を作り直してみると …… 処理速度は低下しないわけだ． 当り前のことながら．
• しかし， このようにヘッダーファイルを ますます汚らしくしてしまった ムクいはいつの日か受けねばならないような 気がしてならない．
• かかる <贖罪> は 未来の可能性に属するコトなんで …… ともかく 手始めに gridworld.cc から gridding 関数群を分離してみる． これはやらなくてもいいことなんだけど， 最初は問題の少なそうな 改造から着手．
• えーと， この gridding 関数というのは 「つみ木の集まりに変換してくださいな」 という依頼を処理しているのである． こんなふう に．
• たんにファイルを二分割するような 単純なリストラは何の問題もなく終了．
• とりあえず gridworld.h, gridworld.cc そして gridding_function.cc から 「地形つみ木化」 の部分だけ抜き去り， topo_voxels.h と topo_voxels.cc に 退避させておく．
• すごい眠気に襲撃される． 気絶しそう． うう． しばらくじっとしてると睡魔は去る．
• 「地形ヌキ」 にした lib_voxelight.a を 試しに作ってみて PipeTree で動かしてみる． コンパイル成功． さて， 動くか． いきなりゲロ吐いてコケるなよ． あ， これは自分に言ってるんではなく， コンパイルされた pipetree が core という 汚らしいファイルを吐瀉なされぬように， というささやかな祈りであります．
• うまくいった …… lib_voxelight.a から 「地形形成・照合」 機能を削っただけなのだから， うまくいくのは当り前である．
• ここからが急所なんだが …… 最近ようやくのことで使えるようになった呪法である この「継承」ワザを使って Gridworld クラスから TopoVoxels という 「光線は地面にぶちあたったのか ?」 を調べるクラスを派生してみる． この機能はもともと Gridworld に 組み込んでいたんだけど， 継承というインチキで 「TopoVoxels = Gridworld + 地面地形関係の属性・機能」 を実現しよう， そう企んでるわけだ．
• なんで地形だけ分離したほうが良いのか ? 地形以外の grid 化というか voxel 化の (用語が一定しないナ) 対象となるモノは葉っぱとか樹木の幹である． この両者を比較すると， 次のような違いがある．
  • 葉っぱや幹は時々刻々と 形状が変化するけれど， 地形はそんなに変化しない (今のところ斜面崩壊してる場所の シミュレイションやれって仕事も 来てないし)．
  • 葉っぱや幹はポリゴンや円柱といった 形状の寄せあつめを を gridding_function で グリッド化している． 一方で地形のほうは 地形データーから「ソリッド」 な voxel モデルを作ってから， その地表面の部分を べりっとはがして作っている． 両者の間に共通性なし．
  • 要求される精度が違う． 葉っぱだと数センチから 数十センチぐらいか． 地面だともっと粗くてよい．
• …… と書いてるうちに， もっと良さそうな改良が できるような気がしてきた． しかし， とりあえず地面専用 topo_voxels を 継承によって作ってみる．
• あれこれとコンパイルエラーで いちゃもんつけられたメンバー変数・関数を かたっぱしから protected という属性にほうりこむという でたらめで危険なプログラミングによって， make できるところまでこぎつける．
• これはコンパイラー通ったというだけで， まともに動作するかどうかは 全然保証のかぎりではない． 試験運転やりたいんだが …… 知床モデルはもはや古すぎて 新しいライブラリーへの対応すむまで動かない． 対応ずみの PipeTree と Pasoh では 地形データーがない …… という状況． あとから小川データーを読み込ませる 専用のテストプログラムでも作るか． 読ませるだけなら， たいしたことないだろう．
• ふう． くたびれたので休憩． またまた脳内ドーピング． 不規則な生活してると 疲れやすく， そのために余計な出費が必要になる．

[本日のおやつ]
隣のコンヴィニエンス
ストアー「ポプラ」で
調達．Dydo エスプレッ
ソカフェ．140 円．

• さて， 上を書いてるうちに気づいた 「もっと良さそうな改良」 について再考する．
• いままで Gridworld クラスの中で 葉っぱも幹も地面も「つみ木」にされていた． Gridworld オブジェクトに 「これこれの位置には何がありますか?」 とお尋ねすると， 「そこには葉っぱは○個あって 幹は……」 というふうに 丁寧に答えてくれた． さらに いろいろなスケイルのつみ木が混在できるように， 将来はより高機能な方向に発展させて， などと漠然とは考えていたんだが ……
• しかしながら， むしろ Gridworld の機能を 落して 単純化したほうがより良い世界が開けるのでは なかろーか． ああ， つまり 「これこれの位置には何がありますか?」 と尋ねても， 単に 「○個」 としか回答できないような マヌケに「改良」してやるのである．
• これまでは， シミュレイション全体を統括する Forest クラスでは， Gridworld 一個だけ手元に 置いとけばよかった． しかし単能化した Gridworld は 対象ごとに準備する必要がある． とは言っても葉っぱとか幹とか それぞれ準備するだけである．
• 機能を落したときに期待される利点．
  • たぶん， 速くなる (← こりない莫迦)．
  • Gridworld がすっきりして 理解しやすくなる．
  • いろいろなスケイルの voxel を混在させることが 容易になる．
  • その結果， メモリーなどの資源節約になる．
  • システム全体の 柔軟性・拡張性が増す．
• うーむ， これはゼヒやってみるべきだろうな． おっと， しかし今日のところは撤退しよう． しかし夕方になるほど頭が冴える． 疲れてるんだが． この時差ボケどうにかならんかな．
• 1835 研究所発． かなり空腹なんだけど (あるいは何故かそういう時に限って) 本屋 dan に寄って本棚の回りを ふらふらと回遊する． おおっ， 航空機コーナーに話題の書 「世界の駄っ作機 1・2」 が山積み !! どーしよーかなー， と迷った末に買わずに撤退． 1906 東京モノレイル浜松町発． 1945 帰宅． 腹減った．
• 晩飯食ってから voxelight 改良作業に取り組む． 私の体内時計はどうなってしまったのか， 今日は晩飯のあとも眠くはならない． 少なくともいまのところは． 現在時刻 2135．
• わが可憐なる ThinkPad560E (Pentium 166MHz) では kubolib だの pipetree だのの コンパイルには無闇やたらと時間かかる． 浜松町に置いてる BookPC なら あっという間に終わる作業を， ゆったりと処理している．
• とりあえずコンパイルしたんで， 比較のために pipetree 30 step 走らせてみる． 実行に要する時間 27 秒近い． 5 倍以上遅いな． つまり CPU クロック比よりよくない． ま， 仕方ないか． のんびりやりませう．
• 今日の食卓
  • 朝 (0700): サツマイモの味噌汁の残り． オクラ和えものの残り． 両方かたづいた．
  • 昼 (1230): チンゲンサイのドウバンジャン炒め． 単品野菜炒めは久ぶりではないかな．
  • 晩 (2030): ニラとエノキダケの炒めもの．