井上
Jump to navigation
2005・12・27
移動しました
2005・12・20
EoE
EoE (Ethernet over Ethernet)
http://itpro.nikkeibp.co.jp/article/COLUMN/20051216/226378/
誰かから口頭で聞いていたら、冗談だと思って聞き流したと思います。
Ethernetによる本格的なルーティングが行われても、不思議ではない世の中です。
TCP/IPをC言語に例えると、一部アセンブラで書いてチューニングしました、の印象です(この観点では、MPLSにも似た匂いを感じます)。
2005・12・18
ジングルベル from Google (libjingle)
Libjingle - Google Talk Voice and P2P Interoperability Library
http://code.google.com/apis/talk/index.html
P2Pと言っても、いわゆる多ノード協調環境としてのP2Pではなく、NATを越えてPeer間の1対1のセッションを確立する機能を提供するライブラリです。このライブラリで、WinnyやWinMXがすぐに作れるわけではありません。
ダウンロードして少しソースを見てみました。
- ライセンスはBSD系ライセンス
- 言語はC++です。サイズは、.hと.ccを合わせて3万行強(exampleコードとthird_partyのlibaudioコードは除く)
- STLを使っています。テンプレートばりばりのコードではありません。
- クラス名とメソッド名はらくだ式、変数はへび式とらくだ式が混在(モジュールごとに作者が違うせい?)。
- XMLパーサはexpatをクラスでラップしています(*1)
- sigslotを使っています(*2)。コードは、かなりsigslotに依存していそうです。
- Boostのscoped_ptrを使っています(Boostには非依存です。scoped_ptrのヘッダだけ取り込んでいます)。
- 通信プロトコルは、XMPPの拡張(Jingle)です。
(*1)(expatはAirOneでも使っている、高速XMLパーサです)
(*2)sigslotはイベントドリブン的なコードを書くためのライブラリです。イベントループを持たないので、イベントと言うよりフックと言った方が適切かもしれません。作者は女性です。
2005・12・16
「なるほどナットク! P2Pがわかる本」を読みました
岩田さんの「なるほどナットク! P2Pがわかる本」を読みました。
http://sats.zekku.com/daylist_html?year=2005&month=10&day=20
だいぶ前から机の上に積んであった気がしますが、ようやく読みました。(おそらく)2年以上積んであった
「イノベーションのジレンマ」に比べると、だいぶ速いので許してください。
良い点:
こういう概論的な本では、
- 言葉の定義(言葉と意味の対応)が明確であること
- 言葉の使い方が一貫していること
- 上の対応が作る概念体系に矛盾が無いこと
が重要で、ここらに問題があると読んでいて頭に来ますが、この本はきちんとしています。さすが岩田さん、エックスアリエルです。
悪い点:
1.
暗号化に対する「復号」が、「複合」になっています。一箇所だけのtypoではなく、全編に渡ってtypoしています。
2.
p168の「電子証明書と秘密鍵の管理」はいまいちです。アリエル社内でも誤解している人がいるので、アリエルエリアに記事を書きました。
「証明書と鍵に関する、ありがちなメタファーとありがちな間違い」
http://dev.ariel-networks.com/modules/xfsection/article.php?articleid=60
# 書いて思いましたが、誤ったメタファーに、メタファーで対抗するのは間違いかもしれません。
3.
前書きで井上に対する謝辞が無い(第二版に期待...)。
項目の量だけ見ると、悪い点の方が多いですが、良い本なので勘違いしないようにしてください。
2005・12・09
地獄のペアプログラミング
今日、拘束14時間、約12時間のペアプログラミングをしました。嫌い嫌い大好きXPって感じです。
端で見ているから他人のミスに気づくという側面もありますが、辛口ながら、ミスの多さは偶然では無いと思いました。以下、少し愚痴っぽい話ですが、プログラミングの基本的な部分を含んでいるので書きます。
# 以下の例で命名が甘いですが、そこは論点では無いので無視してください。
「データ構造」と言っても、高度な話ではありません。非常に基本的な話です。
簡単に言うと、Cで書くと
struct foo_t {
int x;
int y;
} foo[N];
のようなデータ構造であるべきものを、次のように書いていました。
int arr_x[N];
int arr_y[N];
要は、構造体の配列であるべきところが、複数の配列になっています。
配列arr_xと配列arr_yが(暗黙に)関係しています。結果として、これらを参照するコードは次のようになります。
for (i = 0; i < N; i++) {
int x = arr_x[i];
int y = arr_y[i];
// xとyはペアで使われる
}
以前、プロのプログラマ歴20年以上の人がこんなコードを書いたので、速攻で直させました。例え、動いたとしても、こんなコードは、存在そのものが許せません。
今日は諸般の事情により放置されました... (言語がPerlだったというのも理由のひとつです。Cだったら10分で書き直すのですが、Perlのリファレンスとハッシュのコードを10分で書き直す自信がありませんでした。会社に戻ったら、隣の凄い人にバカにされそうです)
フラグ変数が多すぎる、という問題もありますが、実はぼく自身もフラグ変数を結構使うのであまり人のことは言えません。
しかし、フラグの直交性には気を使います。ここでのフラグの直交性を簡単に説明すると、次のような話です。フラグ変数a,b,cと3つあった時、フラグcに「aかつb」の意味しか無い時、フラグ変数cの存在を許してはいけません。途中でフラグの意味が変わって、気づいたらフラグ変数cの意味がそうなっていた時も、即刻フラグ変数cを削除すべきです。
cの部分の記述性を明示したいなら、ぼくなら、次のようなマクロでCの部分の記述性を明確化します(Perlなら、まあ関数にでもするのでしょう)。
#define IS_C(conf) ((conf)->is_a && (conf)->is_b)
「呼ぶ-呼ばれる関係」はぼくの用語ですが、雰囲気で察してください。
コードに問題がある時、呼ぶ側の問題なのか呼ばれる側の問題なのかの区別をすることは重要です。この区別を素早く行うためには、呼ぶ側と呼ばれる側を切り離す「感覚」が必要です。
今日のペアプログラミングで、呼び出す外部コマンドが未実装、という状況でした。切り離す感覚があれば、とりあえず何もしない(キックされたことだけが分かる)ダミーの外部コマンドを用意して、あると仮定してテストはできます。外部コマンドでも関数呼び出しでも同じようなものです。今風のモックオブジェクトという用語もありますが、頭での理解より、切り離すと言うか突き放すと言うか、そういう感覚が先です。
このような切り離す感覚があれば、呼ばれる側だけの単体テスト、呼ぶ側だけの単体テスト、と小さな部品ごとの動作確認の意識にもつながります。今風にユニットテストと言う用語もありますが、これも頭での理解の前に、区切って隔離するとでも言うべき、感覚の方が先です。
- その他
- printfデバッグもバカにしたものではありません
- 1分でprintfが書けるなら、コードを見てなぜ動かないのか考えているより、たぶん解決は速いです。
- 気になることはコードに書いておきます
- コードを見ていると、気になる部分が見つかります。一瞬で直せれば直しますが、後で良さそうなものは、コードにコメントでメモっておきます。BSD系の伝統に従い、ぼくはXXXコメントと呼んでいます。気になる部分の多いコードだと、あちこちにXXXマークがつきます。本を読んでいて、気になるページにしおりをはさんだり、メモを書いたりする感覚に近いです。
2005・12・08
BPなんとか
2005・12・02
ワークス、アリエル共同勉強会の資料を公開しました
http://dev.ariel-networks.com/modules/xfsection/index.php?category=14
第1回目は、須崎さんがAJAXの講師をしてくれました。
須崎さんと言えば、知る人ぞ知る、
2004/12/9にAJAX的方法論に言及していた人です。ちなみに、AJAXという言葉が生まれたのは、
2005/2/18です。
外人が言うとそれに合わせて一緒に語り出す、その辺の日本人とは格が違います。日本シリーズの先発とアジアシリーズの先発ぐらい格が違います。
2005・12・01
排他制御のパフォーマンス
aprのprimitiveな排他制御のパフォーマンスを調べてみました。
やっていることは単純で、lock、unlockを次のようにひたすらループで回すだけです。
#define NUM_LOOP 10000000
now = apr_time_now();
for (i = 0; i < NUM_LOOP; i++) {
apr_thread_mutex_lock(mutex);
apr_thread_mutex_unlock(mutex);
}
printf("mutex: %" APR_INT64_T_FMT "\n", apr_time_now() - now - nop);
nopは、あらかじめ何もしないループを回した時の計測時間です。
APR_INT64_T_FMTの部分は、GNU/Linuxではlld、WindowsではI64dに置き換わるマクロです(64bit整数のprintf用書式指定にプラットフォーム依存があるためのマクロです)。
普通のmutexとread-write lockをGNU/Linuxで計測したことはあったのですが、今回、次のふたつを初めてやりました。
- Windowsでの計測
- atomic APIの計測
atomic APIは、
apacheのパフォーマンスチューニングで紹介されているAPIです。
Windowsでは、InterlockedIncrement()などのAPIのラッパーになっています。
GNU/Linux(x86)では、次のようなアセンブラに展開されるマクロになっています。
#define apr_atomic_cas(mem,with,cmp) \
({ apr_atomic_t prev; \
asm volatile ("lock; cmpxchgl %1, %2" \
: "=a" (prev) \
: "r" (with), "m" (*(mem)), "0"(cmp) \
: "memory"); \
prev;})
何回か実行しておかしな変動要因が無いことを確認した結果、次のような数値になりました。細かい数値はあまり意味がありません。桁だけの世界です。
CPUの性能が低すぎて書き間違いではないかと思われるかもしれませんが、事実です。
aprの排他制御系のAPIは、OSのAPIのthinラッパーなので、GNU/Linuxの場合はpthread系API、Windowsの場合はWin32 APIそのものと思っても大きな誤差はありません。
計測項目:
- mutex(unnested): nestを許さないmutex lock
- mutex(nested): nestを許す、つまり同一スレッドが連続してlockを呼んでもブロックしないmutex lock
- rwlock(write lock): read-write lockのwrite lock
- rwlock(read lock): read-write lockのread lock
- atomic(add): atomic APIのaddオペレーション
GNU/Linux (Debian sarge、Linux 2.4.30、libc 2.3.2、Athlon 650MHz):
- mutex(unnested) ... 約2600000マイクロ秒/1千万回 ...1回あたり約0.25マイクロ秒
- mutex(nested) ...約5600000マイクロ秒/1千万回 ...1回あたり約0.56マイクロ秒
- rwlock(write lock) ... 約4300000マイクロ秒/1千万回 ...1回あたり約0.43マイクロ秒
- rwlock(read lock) ... 約5800000マイクロ秒/1千万回 ...1回あたり約0.58マイクロ秒
- atomic(add) ...約460000マイクロ秒/1千万回 ...1回あたり約0.046マイクロ秒
Windows (Windows2000 SP4、Athlon 1.1GHz):
- mutex(unnested) ... 約12000000マイクロ秒/1千万回 ...1回あたり約1.20マイクロ秒
- mutex(nested) ...約700000マイクロ秒/1千万回 ...1回あたり約0.07マイクロ秒
- rwlock(write lock) ...約12200000マイクロ秒/1千万回 ...1回あたり約1.22マイクロ秒
- rwlock(read lock) ...約41100000マイクロ秒/1千万回 ...1回あたり約4.11マイクロ秒
- atomic(add) ...約90000マイクロ秒/1千万回 ...1回あたり約0.009マイクロ秒
新しい発見。
GNU/Linuxでnested mutexの方が遅いので、Windowsでも同じだと思っていました。事実は、Windowsではnestedを許すmutexの方が速いです。
atomicオペレーションは圧倒的に速いのでatomicで置き換えられる箇所はmutex lockから置き換えたいです。実際は変数ひとつを守るだけのmutex lockはあまり無いですが。
2005・11・29
C++ vs. Java vs. C#のネットワークパフォーマンス比較
Comparing Two High-Performance I/O Design Patterns
http://www.artima.com/articles/io_design_patterns.html
を読んでみました。
ここで比較しているReactorパターンとProactorパターンを、それぞれPOSIX風に言い換えると次のようになります。
Reactorパターン
select(2) or poll(2)でソケットの監視をして、non-blockingなrecv(2)、send(2)で送受信します。
ソケットが読み書きできるようになるまでカーネルで待機して、読み書きできるようになるとユーザアプリに制御が来ます。ユーザアプリはrecvで読み込んだデータをバッファにコピー(読み込み時)するか、バッファにデータを書き込んでsendを呼びます。実際のネットワーク上へのデータ送受信は、カーネルの仕事です。
Proactorパターン
非同期IOのAPI(aio_のprefixの付いたAPI)で送受信します。
ネットワークの送受信が完了した時点で、カーネルからユーザアプリに制御が来ます。読み込みの場合、バッファに読み込みデータが既に入っているので、ユーザアプリはそれを使えます。
後者の方が効率的という話は新しい話題ではなく、POSIXのリアルタイム拡張(10年以上前)の頃からの話です。もっとも、10年以上経っても前者が優勢である現実はaioにも問題があるゆえだと思っていますが(率直に言って、あまり使いやすくありません)。
上記の記事自体は、OSごとに両方のパターンを混ぜて使うのは大変なので、select/pollでProactorをエミュレートするテクニックの紹介です。やっていることは、Proactor jobと呼ばれるユーザアプリのイベントハンドラが読み書きを完結させて、改めてReactorパターンに従うイベントハンドラを叩く、というだけです。
興味深いのは、C++、Java、C#のパフォーマンス比較です(3ページ目のグラフ)。C#がJavaに負けてます。Javaは自分の手元で使うと遅いのに、公開されたベンチマークだと良い結果を目にすることが多いです。本当はできる子なのに、ぼくの前では手を抜いているのか、と厭味を言いたくなります。
2005・11・27
IBMのナレッジマネジメント
IBMではナレッジマネジメント(以下、KM)が成功しているようです。
(ある意味、一時期IBMのシステム内にいたのに)聞いたことがありません...
これは
- IBMのKMの成功はロータスに伝わっていなかった
- 実はDominoのことを言っている
- 実はRavenが生きていた! (*)
- IBMのコンサルティング部門の魔法の力で、成功したことになっている
のどれかでしょうか。
KMに誰も情報を蓄積しない問題はずっと昔から続いている問題です。銀の弾丸はまだ見つかっていません。ただし、ソーシャルブックマークなど類似のサービスがたくさんある中でも、ポジティブに回り始めるものがごく稀に突然変異的に現れます。この転換点がどこにあるのか、それとも既に銀の弾丸を見つけた人がいるのか、気になります。IBMに答えがある気はしていませんが。
(*)一応、笑うところです。マニアすぎて誰も分からないと思いますが。"raven lotus"でWebを検索すると少し情報が見つかります。
prototype.jsの勉強会。そしてRubyの影
今日の勉強会のネタは
prototype.jsでした。と言っても、prototype.jsの使い方のような軟弱なネタではなく、prototype.js自体のコードを辛口で講義する内容でした。
Enumerableの
日本語の説明を見つけました。そして、prototype.jsのEnumerableは
Rubyのインターフェースをそのまま踏襲していることを知りました(Rubyの方を見ていませんが、内部の実装もほぼ踏襲しているのかもしれません)。
そう言えば、昨日存在を知った
diggでprogrammingセクションを見ると、意外(?)にRubyが目につきました。
「Why Ruby Shouldn’t Be Your Next Programming Language (Maybe)」は、RubyなんてしょせんCやJavaやPerl(これら3つはlegacy扱い)の延長線上の言語なので、新しく学ぶならLisp系の言語にしなさい、と言うまことにありがたい記事です。批判があってこそ一人前ですし、C、Java、Perlの後継として位置付けられている点は興味深いものがあります。
一方で、
SourceForgeのプロジェクトの利用言語でJavaがC++を抜いてトップにという記事もあります。そもそもC++がCを抜いてトップだったことすら驚きです。
もっと読む...
2005・11・25
アリエルエリアにユニマガ原稿を公開しました
ユニマガ原稿(UNIX MAGAZINE 2005年 9月、10月、11月のP2P特集)
http://dev.ariel-networks.com/modules/xfsection/index.php?category=13
執筆陣のアリエル関係者(原稿公開対象者)
井上、
大谷、
岩田
他の執筆陣
亀井さん、大谷卓史さん@吉備国際大学
# かなり力作ぞろいです。
# xoopsは相変わらず腐っています。文書公開に非常に気を使います。
2005・11・24
IPv6の専門家について行きました
久しぶりにIPv6界隈に顔を出しました。
アリエルにはIPv6の専門家(浜岸さん)がいるので、ぼくはついて行っただけですが。
面識は無いのですが、
itojun氏の最近の様子を聞きました。
日記を見ると、元気なのか死んでいるのか分かりませんが。
考えてみると、そんなに年齢が違うわけではないのに、向こうは遥か昔に伝説的ハッカーになっている気がします。まあ、有名であることが良いかは知りませんが。
2005・11・17
圧力団体その2
世間の普通の人気サイトをあまり知らないので、更新停止でサイトの存在を初めて知りました。
http://ameblo.jp/dukkiedukkie/entry-10006178492.html
世間には圧力団体があふれています。
P2P業界の新しい圧力団体?
先週の記事ですが、japan.internet.comに
「Microsoft と Cisco、『ICE』技術をサポート」があります。
この記事の内容はともかく、
オリジナル版(英語版)を見ると、後半が翻訳されていません。翻訳されていない部分は、MSサイドから見たSkypeの弱点、と言うか、もっと率直に言うと、Skypeの悪口部分です。
これはjapan.internet.comに連載記事を持つ某P2P企業社員が政治的圧力をかけた結果でしょうか。真相は不明です。
ICEのIETFドラフトに目を通してみるかと、"ice nat ietf"で検索すると、
吉澤氏の記事を見つけました。と言うことで、IETFドラフトを読むのはやめて後編を待つことにしました(軟弱)。