或曰

-- 2003年12月下旬 --

Last-modified: Mon, 03 Jan 2005 00:15:01 JST
[dynamic,cache:on]
powered by tds-1.6.2

[著者管理] < = > [上旬] [中旬] [下旬] [一覧] [アクセス解析]
[最新版] [2003年12月以前] [2003年2月以前]


お名前 名前記録
一言
最近の一言
09/07 14:38読んだよ
09/07 14:38読んだよ
04/17 20:30ゆんGNU ld 遅い問題。うちの現在進行中のプロジェクトでも同じ問題に悩んでいたのですが、-Mapオプションを外したところ劇的に速度が改善されました。まさかこんな事だったとは。感謝。そして、ボトルネック調査の重要性を痛感した次第です。
03/01 22:40一生>はりあさん ありがとうございます。後でチェックしてみます。
02/28 13:10はりあ失礼します。BYACC / JAVA(http://troi.lincom-asg.com/~rjamison/byacc/) というのがあります。参考までに。

2003/12/20(Sat) [n]

%1

10:30 起床。

%2 ATC-HA7USB

昨日の件、午前中に再配送され受け取り完了。

単体のヘッドフォンとしてみた場合 20,000 円強の価値があるかは微妙。 同一・あるいは少し安めの価格帯のヘッドフォンと比較してぬきんでた音質とは言い難いため、 それなりのプレイヤー・アンプがあり、 そちらで音楽再生するのがメインという人は敢えて ATC-HA7USB を選ぶ必要はない。

ただし PC で音楽を再生するのがメインの人なら、 PC 内部で発生するノイズの影響を全く受けないクリアな音楽を再生できるため、 この価格でも十分に見合う。

やや高音が耳障りなので、 これは MP3 プレイヤー側で調整した方が良いかも。

@ というわけで

携帯環境としてはこれまで通り NOMAD Jukebox ZEN + B&O A8, 仕事中は PC + ATC-HA7USB に切り替え。

以前はプログラミングに集中していられる日が多かったのだけど、 最近は人が増えてきたこともあり、 しばしば割り込み的に非公式ミーティングやサポートが発生している。 そのためプレイヤーの操作性やヘッドフォン脱着の容易さが重要になったため、 環境を変えようと思った次第。

%3 お出かけ

秋葉原経由で忘年会。

%4[Web 巡回] Web 巡回

@ STL メモリアロケータ

どの STL を使ってるのか知りませんが、 SGI STL 由来のもの *1だと毎回 new/delete 呼ぶことはありません。 標準のアロケータに

という仕組みが入ってます。

先月書いたメモ

そういえば CodeWarrior VC++.NET のアロケータは、どうなってるんだろう。 暇があれば読んでみるか。


*1:gcc 付属のものや STLport など。

%5 お買い物

久しぶりに訪れた LaOX The Computer 館の 6F 書籍フロアにて。

前者は、会社に定期購読させる可能性アリ。まずは自費で買ってみる。 後者は特集記事の Google 徹底解剖に興味が沸いたため。

デマルコの新刊も出ていたが、 積読状態の書籍が多いため、 そちらを優先して購入見送り。

%6 忘年会

大学の同期生と、東日本橋にある合鴨料理の店「鳥安」にて。 店は古きよき日本を思い起こさせる佇まい、料理・サービスも文句なく。 久しぶりに、美味しい料理を、楽しい面子で堪能しました。

話の内容は微妙に黒かったので省略。

%7 帰省

23:50 実家着。

%8 読書記録

内憂外患。

かつては権力を持つ代わりに責任を負い、 以て帝国の中枢を任じていた元老院は批評家に堕し、 帝国の中間階級を構成し軍の中核をなしていた重装歩兵は、 例外的少数の騎兵に軍の主役を譲り渡す。 軍事と政治が分離し、 国民は超えることが不可能な壁で区切られた階層に分離し、 中長期的な目標を皇帝・元老院・市民と一体になり着実に実現していったローマは昔日のものに。

これまでの繁栄を保障してきたシステムがゆるやかに瓦解し、 環境の変化に対して適切な対策をとれずに崩壊をさらに早めていく様を見ると、 歯軋りする思い。

しかし、 自分が彼らの立場にあったとしたらより適切な策がとれるかと考えると、 安易に批判を口にできない。 特に、 後になって振り返ってみれば帝国の崩壊を早めたと思われる政策も、 当時の立場で考えると妥当な策と見えるものが多いことが何ともやりきれない。


2003/12/21(Sun) [n]

%1

11:30 起床。

%2 お買い物

@[Comic] コミックス

@ PC 関連

実家用の PC と周辺機器、 両親に要求要求を聞き取り調査の上、 スペック決定と注文。 コストパフォーマンス重視・ノート型である必要なしということで、 Athlon XP を使ったショップブランドマシンに。

覚書: アンチウイルス系のソフトを用意すること。


2003/12/22(Mon) [n]

%1

11:30 起床。連休の狭間につき有休。

%2

書籍消化中。

Practical Statecharts in C/C++ は数ヶ月前に購入したものだけど、 ようやく手をつける。

一章を読み終えたところで、 年末の読書予定を変更し、 この本を最優先で消化することに決定。 今抱えている問題を解決するため、 使えそうだ。


2003/12/23(Tue) [n]

%1

10:30 起床。

%2 CAN

先日の忘年会で、 組み込み屋さんから教えてもらった通信プロトコル。 概要だけ解説してもらったのだけど、 私が慣れ親しんでいる Ethernet などとは設計思想が大きく異なっており、 興味を持ったので詳細を調べてみた。

@ 概要

正式名称は Controller Area Network。 リアルタイム処理向けの通信プロトコルで ISO 11898 として標準化されている。 主な応用分野は、 自動車の組み込み機器間通信。

シリアル通信。 ノード間通信機能を提供しルーティング機能はもたない。 OSI 参照モデルに当てはめると、 Ethernet などと同じデータリンク層に位置。

通信スループットは組み込み用途としては高いが、 Ethernet などと比べると低い。 数kbps から 1Mbps 程度。

@ その他の通信方式

ひとつの通信路を複数のノードで共有する場合、 通信が衝突する可能性がある。 これを解決する方法として私が知っていたのは、 TDM, FDM/WDM, Token方式, CSMA/CD の 4 種類。

TDM
通信路の利用権を時間単位で分割して「最初の 10ms はノード A, 次の 10ms はノード B, ...」と通信でいるノードを限定する。
FDM/WDM
通信に用いる周波数帯を分割する。
Token方式
通信権をノード間で受け渡す。まず最初にノード A が通信権を持っており、通信する必要がなくなったら次にノード B に権利を受け渡す。(TokenRing, FDDI)
CSMA/CD
ほかのノードが通信していないことを調べ、通信を開始。衝突したら、ランダムな時間待って送りなおし。(Ethernet)

このうち TDM, FDM/WDM は一般に物理層に近いところで使われ、 Token方式, CSMA/CD はその上のデータリンク層で使われる。 TDM, FDM/WDM は、 帯域の狭い通信路を複数用意しているのと変わらないため、 以下の議論では除外して考える。

ところでリアルタイム処理では、

ことが要求される。 そのためリアルタイム処理で用いる通信には、 次の二つの特性が要求される。

この観点から見た場合、Token方式, CSMA/CD は次の欠点がある。

Token方式
トークンの確保に大きなレイテンシ (遅延時間) を要する。
CSMA/CD
ノード間の通信優先順位をつけられない。また確率的なアルゴリズムであるためリアルタイム性を保障できない。

@ 衝突調停アルゴリズム

CAN の要は次の二点。

CAN では通信におけるレイテンシを小さくするため、 Ethernet と同様にブロードキャスト、 すなわち一つのノードが発した通信を全ノードが受け取る形で通信を行う。 では複数ノードが同時に通信を始めた場合の衝突をどうするかだが、 プロトコルを工夫することで通信中に動的に衝突を検出・調停している。

バスに接続された各ノードは、 各瞬間にバスに dominant ビットもしくは rezessive ビットいずれかを出力し、 バスから dominant ビットもしくは rezessive ビットいずれかを受け取る。 各ノードが出力するビットと、バスから受け取るビットの関係は次の通り。

ノードの状態 バスの状態
全ノードが rezessive ビットを出力している。 rezessive
1 つ以上のノードが dominant ビットを出力している。 dominant

各ノードが次のアルゴリズムに従って通信を行う。

  1. バスが空くまで待つ。
  2. 通信を開始。各ノードは、まず通信の優先度をエンコードした Identifier*1を送る。
  3. 自分が rezessive ビットを送ったにもかかわらず、バスから dominant ビットを受け取った場合は、送信中止。
  4. 送信中止になることなく Identifier をすべて送り終えたら、自分がバスを占有している。データ送信を開始。

きわめてシンプルなアルゴリズムだが、 これで Identifier 送信の時間だけで調停は確実に完了し、 調停・データ送信が 1 フレームで済み、 かつ再送処理や確率的な待ち時間のような不確定要素が全く無くなる。 詳細は省略するが、 受信ノードがデータを受け取ったことの確認処理も工夫されており、 これも同一のデータフレーム送信処理で完結する。

Controller Area Network (CAN) - Protocol の中ほどにある Real-time data transmission の図を見ると、 具体的なイメージを掴む助けになる。

@ 学生時代に

待ち行列理論や誤り訂正符号・暗号化の話は勉強したが、 CAN, SONET/SDH のような simple & robust な通信方式に触れる機会はなかったと思う。 まぁ、CAN だとレイテンシなどを見積もるのがあまりに簡単だから、 試験に出すなら確率的アルゴリズムのほうが良いんだろうけど。

通信まわりは、 面白いネタがいろいろ転がってますね。 たまに齧ると良いかも。

そういえばタネンバウム先生のネットワーク本、第4版の邦訳が出てるから買わないと。


*1:これは設計段階で決めておく。

%3 衝突解消

今の仕事だと、 通信ではなくキャラクタ移動時の衝突解消アルゴリズムにいくつか問題があって、 打開策を考え中。


2003/12/24(Wed) [n]

%1

06:10 起床。

%2 一貫性などと言うものは、小人の心に宿るお化けみたいなものだ

この言葉を知ったのは、 鶴見俊輔の著書に対する評だったか。

ふとした折に胸に浮かぶことがあり、 気になっているのだけど、 原典は何なのだろう。

%3[Work] お仕事

@ 出社

自宅によって荷物を片づけ、会社に。 到着は 10:30 ちょい過ぎ。

@ bison-mode

スクリプト部分を書いているメインプログラマが、 XEmacs で yacc のソースを編集するための適当な major mode を探していた。

google にお伺いを立てて bison-mode を見つけて試してみたのだけど、イマイチっぽい気が。 もう少し cc-mode などに近い挙動をする bison-mode は存在しないんだろうか。

@ 状態遷移図書き

キャラクタの状態遷移図を書いていて一日終わり。 状態に階層関係を入れたら遷移を表す線がごっそり減って、 かなり見通しが良くなった。

@ シーンの状態遷移

見かけ上の待ち時間を減らす小細工を入れつつ、 問題になりそうな境界条件を中心に苛めてみる。

特に問題なく。

@ ミーティング準備

システム管理系の人とのミーティング、 営業日が残り少ないので明日やることに確定。 今日は資料作りにさける時間がなかったので、 これは明日に回す。 最悪、箇条書きのメモで済ませるかも。

プロジェクト側の目論見は、 ビルドクラスタのメンテナンスやソフトウェアの評価など、 システム構築がらみの仕事を私から切り離すこと。 さすがに私がやるには手が不足気味なのと、 プロジェクト内部で留めるより外と共有した方が良さそうな話だから。

@ 帰宅

19:30.

%4 お買い物

来月以降は買わない予定。他に、読むべきものが多すぎる状況につき。

あと新聞の定期購読を切ろうかと真剣に検討中。


2003/12/25(Thu) [n]

%1

09:00 起床。

%2[Work] お仕事

@ 出社

10:00 ちょい過ぎ。

@ ミーティング (1)

進捗報告。

ちょっと微妙になってきたな……。 年始早々に、立て直しを計る必要がありそうだ。

@ ミーティング (2)

システム管理系の人とのミーティング。 資料は LaTeX で箇条書きのリスト作って済ませる。

ミーティングの内容は、 プロジェクトが抱える具体的な問題に関する話から、 情報交換レベルのものまで幅広く。 定期ミーティングをやらずに、 たまに話すとそうなるか。

全社的に共有できるコンパイルファームやレンダリングファームを作った方が、 何かと幸せになれそうな気がする。 中長期的にはその方向で、 今回は間に合わないと思われるので短期的には次の作業をお願いします、 とうことで。

他のプロジェクトでもビルドプロセスを工夫しているところがあるとのことだから、 そちらの情報も集めてみよう。

ちなみに、 現在はフルビルドを何も工夫せずに 1 プロセスで行うと 14 分 (内リンク 55 秒) を要する。 これを、 私が用意した並列ビルド環境を使って PC 4 台 / CPU 8 個 / 32 プロセス並列でコンパイルし、 さらにリンク作業をローカル HDD を持つマシンで行うと 2 分前後 (内リンク 30 秒) に短縮される。

コンパイル時間はマシンを増やせばどうにかなるが、 リンクは並列処理が不可能なため、 抜本的な対策が必要。

@ コード書き

ビルドシステム関連で Linux 上で動くコードを1つ。

@ 帰宅

20:50


2003/12/26(Fri) [n]

%1

09:30

%2[Work] お仕事

@ 出社

10:30

@ ビルドクラスタで謎のコンパイルエラー

特定のファイルをコンパイルすると、 コンパイルに失敗する。 エラーメッセージを見と、 ソースコードの一部がコンパイラ (cc1plus) に渡る段階で欠落しているように見える。

調査を進めると

ということが判明。 思い当たることとして、コンパイラに渡している -pipe オプション *1を外すと解決。

推測だけど、 プリプロセッサ側で write() システムコールが失敗する可能性を考慮しておらず、 パイプ入出力に使うバッファが溢れた時に、 コンパイラに渡すプリプロセス済みコードが欠落してしまうのではないかな。 そういえば希に発生している ee-as が segmentation fault で死ぬ問題も、 これで解決するかも。

@ CVS 管理作業

プロジェクトのメンバーが引越作業をしている間に、 裏で CVS リポジトリの管理作業。

他のプログラマの作業状態を把握するため、 cvs commit 時には自動的に commit メッセージをメールで撒くようにしてある。 これまではメール作成に log.pl スクリプトを使っていたのだけど、 何かと log_accum.pl の方が便利なので入れ替え。

参考

@ 納会 + 忘年会 + 歓迎会

会社の納会はそこそこで切り上げ、 プロジェクトメンバー全員で店に移動して忘年会。 来年早々にプロジェクトに来ていただけることに決まったプログラマの忘年会も兼ねる。

@ 新年の予定

プログラマに関しては、今のところ空きポジションは二つ、具体的には

がある。 来年早々に来ていただくことが決まったプログラマは、 本人の希望を聞いた感じだと私の仕事を手伝っていただくことになりそう。

私にサブプログラマが付く時期が予定より早まることになるから、 少し急がんとマズいな。 プロジェクトに来たは良いが、 やることなくて手持ちぶさたでは本人も腐るだろうし。

プロジェクトに来てしばらくは開発環境 (bash, CVS, GNU Make, 分散ビルドシステム, etc...) に慣れたり、 既存のシステムを理解するのに時間を費やす事になる。 加えて当人がスクリプト言語の経験がないという事で、 perl, ruby, python あたりの言語いずれかを使えるようになってもらう必要アリ。

前準備

  1. 事務処理, ネットワーク環境整備などで 1, 2 日ぐらい潰れる。
  2. その後で既存のシステムに慣れてもらいつつ、実機上で動く簡単なプログラムを書いてもらう。
  3. スクリプト言語を勉強しつつ、覚えたスクリプト言語を使ってバイナリデータを作成し、実機で読みとるところまで書いてもらう。
  4. 私が書いてる部分のフレームワークを理解してもらう。

具体的な仕事をお願いできるのはこの後だから、 短く見積もっても仕事始めから 2 週間は先か。 そのあたりで何か1つ、 仕事を振れるように準備しておこう。


*1:一般には gcc が起動する子プロセス (プリプロセッサ, アセンブラ, コンパイラ) の間でデータを受け渡すために一時ファイルを用いるが、 その代わりにパイプを用いる。

%3[Web巡回] Web巡回

@ 一貫性などと言うものは、小人の心に宿るお化けみたいなものだ

先日、日記に書いた件。

オリジナルは 19世紀・米国の哲学者エマソンが、 書籍「エッセイ集」に納めた Self-Reliance という文章だそうです。 実物を手にとって確認はしていませんが、 邦訳は

この書籍の「自己信頼」だと思います。

コメントを頂いた minemaz さんともう一方、 ならびに 小松さん ありがとうございました。

Self-Reliance ちょっと見ただけですが、

"To be great is to be misunderstood." (偉大であるという事は、誤解される事なのだ)

とか、他にも引用されそうな語句がちらほら。


2003/12/27(Sat) [n]

%1 マジスパ下北沢店の年末年始

年末年始の休みは 12/30 - 1/3 まで, それ以外は通常通り営業とのこと。 明日行こう。

%2 帰省前準備

実家帰省前の後始末と、帰省に先立つ準備。

@ 環境整備

修理から帰ってきた後、 放置していた ThinkPad X22 の環境整備。

最初 FreeBSD 5.x 系列を入れようと思ったのだけど、 インストール中に kernel panic で死ぬので諦めて FreeBSD 4.9-RELEASE に。

MagicDraw 7.2 を入れてみたら日本語が豆腐に化けたり、 vim + im_custom が segmentation fault で落ちたり、 日本語が入力できなかったり、 MozillaFirebird の port がコンパイルエラーで通らなかったりとやや苦労するが、 最終的には全部解決。

MagicDraw 7.2 日本語表示の件は

で OK.

im_custom は以下のパッチを当てる。

--- vim62.old/src/skk.c	Sun Dec 28 02:48:41 2003
+++ vim62/src/skk.c	Sat Dec 27 19:43:50 2003
@@ -700,9 +700,11 @@
 		if (!usr_dic)
 		{
 			expand_T	xpc;
+			ExpandInit(&xpc);
 			xpc.xp_context = EXPAND_FILES;
 			usr_dic = ExpandOne(&xpc, "~/.skk-jisyo", NULL, 
 				WILD_SILENT|WILD_USE_NL, WILD_ALL);
+			ExpandCleanup(&xpc);
 		}
 		curBuff[0] = '\0';
     	inpBuff[0] = '\0';
@@ -1632,9 +1634,11 @@
 			expand_T	xpc;
 			if (usr_dic)
 				vim_free(usr_dic);
+			ExpandInit(&xpc);
 			xpc.xp_context = EXPAND_FILES;
 			usr_dic = ExpandOne(&xpc, val, NULL, 
 				WILD_SILENT|WILD_USE_NL, WILD_ALL);
+			ExpandCleanup(&xpc);
 		}
 #ifdef USE_SERVER
 		else

Java と MozillaFirebird は、面倒だったので Linux 版 *1 をインストールして済ませる。

あ、ハイバネーション区画確保するのを忘れた。 Windows 98 リカバリ用のパーティションを潰してしまえば、 今からでもハイバネーション区画を作れるか?

@ 不在連絡票

エヌ・シージャパンから荷物が届いているとの事。 時期的には、リネージュ II クローズド・ベータテストのアカウントかな。


*1:port/java/linux-sun-jdk14, port/www/linux-mozillafirebird


2003/12/28(Sun) [n]

%1 マジスパ

ポーク角煮, 虚空, クイティオ大盛り。

%2[Magazine] お買い物

@[Comic] コミックス

鋼の錬金術師は、 ゲーム記事もしばしば取り上げる「月刊少年ガンガン」発のヒット作ということで、 チェックのために購入。 会社に領収書を回してもいいんだけど、 今回は身銭切ってマジメに読む方向で。 ガンガン本誌は買わずに、 ざっと目を通して済ませる。

あとは仕事と関係なく、単なる個人的趣味。

@[Magazine] 雑誌

%3 帰省

しました。

帰省前に 昨日の荷物 を受け取りに行ったら、 予想通りリネージュ II クローズドベータテストのアカウントだった。

実家の PC じゃビデオカード貧弱すぎて遊べないだろうから、 ユーザ登録は正月明けに上京してから。

%4[Web巡回] Web巡回

@ リンク処理のボトルネック

k_satoda: リンク処理のボトルネックは、デバッグ情報ではないのですか?

それは間違いではありませんが、正解でもないです。 リンクに要する時間は、大きく次の二つに分類されます。

以前に試したことがあるのですが、 前者は GNU ld + ELF という環境では、 デバッグ情報の有り・無しでほとんど差が出ませんでした。

後者はファイルを NFS で共有すると有意な差が出てきます。 デバッグ情報込みでオブジェクトファイルを生成すると、 ソースコード 10 万行程度でも軽く 50MB を超えるため、 ファイルの読み込みだけで数秒~十数秒かかります。 デバッグ情報を含めなければ、 それだけオブジェクトファイルのサイズが減る道理。

ただし、 これもリンク処理をファイルサーバ上で行うことでほぼゼロにできます。


2003/12/31(Wed) [n]

%1 実家 PC 環境整備

だいたい終わり。 必要なソフトも一通りインストールして、 父母がやりたいと言っていたことは出来るように。

PC モニタまわり PC 本体

ThinkPad は私物。 右写真のミニタワー型 PC が、 今回新調した Athlon XP マシン。

@ ついでに

私が帰省したときに仕事できる環境も作ってしまう。 MagicDraw 7.2 (on FreeBSD 4.9-RELEASE, linux-sun-jdk-1.4.2.03, ThinkPad X22) でお絵描きしつつ Quantum Programming のコード読み中。

@ ThinkPad X22 ハイバネーション

ハイバネーション領域の確保は、 本来 FreeBSD をインストールする前にやっておくべき事だが、 うっかり忘れて環境整備してしまったので、 後付けでハイバネーション領域を作ることに。

  1. ThinkPad で FreeBSD を起動。/stand/sysinstall を使って、Windows 98 リカバリ用のパーティションを解放。(ディスクに空きがなかったので)
  2. IBM のサイトからIBM ThinkPad ハイバネーション・ユーティリティ・ディスケット II (スタンドアロン・ブート) Ver.4.50を入手。Windows 環境でフロッピーディスクに書き込む。
  3. そのフロッピーディスクで ThinkPad X22 を起動し、メニューに従ってハイバネーション領域を作成。
  4. FreeBSD が起動しなくなったので、FreeBSD インストール用のディスク (kern.flp, mfsroot.flp) から起動して、ブートローダだけ上書きする。

これでハイバネーション可能になりました。

どうも X サーバ起動中にハイバネーションを行うと、 復帰時に画面が乱れることがある。 ハイバネーションから戻った後に Ctrl + Alt + F1 でコンソールに切り替え、 再び X に切り替えると解決するので、 とりあえずこれで凌ぐ。

%2 大掃除

実家の大掃除。 私は古い PC を箱に詰めたり、窓を拭く程度でおしまい。


以上、10日分です。 (直前の日記

このページはTomsoft Diary System 1.6.2を用いて生成されています。
Copyright (C) 2003
Issei Suzuki <issei@issei.org>