世の中、上には上がいるらしい。というわけで追加。
上記は 3w-asin-books-22 のこと。わぁあったまいー、ちょぉすてきぃ。まー私は 50 アサマシエイトの人 [詳細] なので実害はないのだけど。
出勤前に新宿紀伊国屋書店に回って、何か参考になりそうな本はないかと探してみたのだけど……私の探し方が悪いのかな、いい本が見つからない。とりあえず、中川 徹・小柳義夫「最小二乗法による実験データ解析」(1982, 東京大学出版会) と 栗原 正仁「わかりやすい数値計算入門」(2004, ムイスリ出版) を購入。中身はこれから読む。
(T^T) な xyzzy のソースを読んでいる。とりあえず VC6 SP5 でビルドが通るところまでは終えた。今は sock.h/cc と resolver.h/cc を getaddrinfo()/getnameinfo() でホゲるようにすることで何とかなると信じて両クラスの仕様推定中。
なんでこんなことをしてるかというと、動機は非常にシンプルで、某 kamail と某 2ch-mode が仕事先で使えなくなってしまったのを何とかするため。フフフフフ、これさえ解決すれば「IPv6 [しかサポートしない] って最低ですよねー、あ、私は別に困らないですけど」と言う資格が手に入るぜ。(心が闇に染まっていく)
xyzzy と IPv6 の続き。仕様調査はほぼ完了して、getnameinfo/getaddrinfo を持たない 95/98/NT4/2000 なんて知らねーという方針なら何とかできそうという見込みが立った。古い winsock までサポートしようとすると死ねそうだけど。
sockinet.h/cc が socket 周りの facade になってるようなので、とりあえずは sockinet::saddr(host,serv) と sockinet::create(), sockinet::connect() を何とかすれば何とかなるかなという感触。sock.h/cc が winsock2 (IPv4) のほぼそのままのラッパーになってるのが悩ましいところだけど……あまり修正範囲を広げるのもアレなので使えるものは使いまわす方向で何とかできないか、とりあえずやってみよう。
_alloca(1024*1024) の生呼び出しだとなぜか例外が発生する罠にはまって、4 時間浪費。最初はスタックサイズがバイナリに反映されてないのではと推測してリンカオプション等を変更してみるも、状況は改善せず。
スタックを 4M 程度消費する main のみの単純なアプリを書いて実証しようとするも、エラーは再現せず。xyzzy 内で alloca() を使ってもやっぱりそこでは例外発生せず。結局 pre_allocate_stack1() を次のように書き換えたらエラーが出なくなった。
static void pre_allocate_stack1()
{
char *p; // alloca の生呼び出しではエラーが発生するようなので回避コード追加
p = (char *)alloca(1024*1024);
sprintf(p, "使ったフリ - 理由はわからないがこれで回避できたので");
}
原因は不明だけど、とりあえず回避には成功してスタートラインには立てたらしい。次は resolver の変更か。
IPv6 対応は完了せず。sock を潰して sockinet と resolver だけの構成 (xyzzy 的に必要な機能だけ実装して) にしようとか色々と迷走した挙句、結局 resolver および sock::netdb を getnameinfo/getaddrinfo のインタフェースに変更し、sockinet::saddr を addrinfo のラッパーにすることで何とかすべきという方向に到達したのが 21:00 頃。
その後も sockinet::saddr がホスト名・ポート指定なしで呼び出されているときにどうしようとか悩みは深く、結局昨日の内には終わらなかった。ああ、今週もしばらくの間は職場からは AirH" 経由でなければ 2ch-mode を利用できないのか……。流石に勤務中に xyzzy のソースをつつく訳にはいかないので、最小二乗法の勉強に戻ることにする。
AviUtl の出力プラグインでのオーディオサンプル数の話。正しく取れている場合もあるとの事なので、再検証。前回と同じ AVI ファイルを指定して動かして見ると……やっぱり妙な値が入っている。
ひょっとしたら入力ファイルに依存するのかと、M2P ファイルを VFAPI 経由で読み込むと……この場合は正しいサンプル数が渡ってくる。AVI だとダメなんて話は無いはずということで、PCM オーディオの AVI をソースにして動かすと……この場合も正常なサンプル数が渡ってくる。
どうやら圧縮オーディオの AVI (最初に試した AVI は音声 MP3 だった) で、範囲指定を一切しない状態だと妙なサンプル数が渡ってくるらしい。最近取り込んでいないからと保存用 AVI をソースにテストしていたのが失敗の元だったか。
これなら README に書いておけば済む話なので、対応も可能と。xyzzy の作業が終わったら作業再開することにしよう。
「普通はスクリプト系の言語で書かないか、これ」というようなコードも C で書くようになってしまった今日この頃。みんな ruby が遅すぎるのが悪いのだ。
やりたかったことは、単純に数 M 行の 2 次元サンプルから最小二乗法で関数近似したり、最頻値求めたり、平均値求めたり、最大値求めたかったりしただけなんだけど ruby だと分のオーダーじゃ処理できなくなってしまうからなぁ。perl とかだともちっとはやいのかしら。
この程度のコードだと言語に何を使おうが実装の手間は変わらないので、結局実行速度で選ぶことになってしまう。最近では ruby を適当にコマンドラインをでっち上げて system() 呼び出すだけの高級 bat 言語としてしか使わなくなってしまった。
IPv6 の方は昨晩ようやく link が通るところまで到達し、とりあえず xyzzy.exe ができあがった。kamail を試してみても当然のようにサーバにつながらなくなってしまっているので、本日帰宅後にデバッグ予定。なんとか今晩でケリを付けたい。
先月末と今月頭に買った４冊の本で、一番役に立ったのは最も初心者向けの「わかりやすい数値計算入門」だったという悲しい話。
そういえば大学の１・２年の頃に講義でやったことがあったな〜と思いつつ、今回の問題については、線形最小二乗法で充分だということが判明したので残りの本は本棚に死蔵されることに決定。まぁそのうち役に立つことがあるかもしれない。
事情は理解できるのだけど、WSPiApi.h と sockimpl.h/sock.cc で困ってる。片方は Windows XP SP2 platform SDK のヘッダファイルでもう片方は xyzzy のソースファイル。
どちらもレガシーのサポートをしようとしての努力の結果なんだということは、理解できるのだけど、地雷を踏んでしまって足を持ち上げられない現在の立場としてはなんとも言いがたい。
#include <winsock2.h> #include <ws2tcpip.h> // WSPiApi 対策 #ifdef getaddrinfo #undef getaddrinfo #endif #ifdef getnameinfo #undef getnameinfo #endif #ifdef freeaddrinfo #undef freeaddrinfo #endif
とりあえず上のコードを書けば関数テーブルを潰さずに済むのだけど、これだと XP 以外で動かなくなってしまう。どちらがマシかといえば関数テーブルを潰して ws2_32.lib をリンクし、WSPiApi.h を利用した方が良いだろう。流石に WspiapiLegacyGetAddrInfo 等のコードを移植するのは嫌だし。あー sock.cc にはあまり手を入れずに済むかと思っていたのだけどな〜。
というわけで、ws2_32.dll と自動リンクする形でとりあえず IPv4 では kamail が POP3 サーバーとお話できるようになった。職場の IPv6 環境でも問題が出なければ当面の作業は完了予定。
OK。kamail/2ch-mode 共に問題なく動作してる。適当にコードを整理したら亀井さんにメールを書こう。
これまでは portproxy 使ってしのいでいたのだけど、何が嫌って、WAIT_CLOSE 0 状態の socket が残っている時に、再度 POP3 に取りに行ったりしたら OS が完全にフリーズしてくれたりするところ。おかげで今まではメールを出した後、コマンドラインから netstat で WAIT_CLOSE 0 が消えたことを確認して、それからメール取得していた訳だ。
本質的な解決としては graceful にソケットを閉じるようにするべきなのだろうが、とりあえず今回の IPv6 化で portproxy でのフリーズ問題だけは無くなってくれたので気にしないことにする。つーかこれは犯人が xyzzy 側なのか kamail 側か、どちらなのかすら判っていない状態なので。
dump4w これだ。これが欲しかったのだ。というわけで ４年前から探していたものが手に入った。まだ検索周りとかあやしそうなところ [無限ループにはまって、ウィンドウは消えるけどインスタンスが消えなくなってたり - 一度だけ遭遇して再現方法は不明] があるけど、そのうちバグ修正とかもしてくれるに違いない。
むー例の自前 build IPv6 化 xyzzy が kamail を起動すると通常メニューが消えて kamail メニューだけになってしまう。Alt, e, p でクリップボードからのペーストができない。不便だ。
とりあえずメールは出したわけで、本家が正しく IPv6 対応してくれるならこちらで調べる必要はないだろう。かなり願望が入ってる予測だけど。
void GraphicWizardsLair( void ); // 経由で 現状のディスクローズ [Doblogスタッフブログ] へ。
私の体験はだいぶ前の話であることを断っておく。Xeon 1.4GHz Dual の 2U サーバーが DELL 価格で \1M を超えていた大昔の話だ。
あるところで PostgreSQL/PHP/Apache で普通に WEB サーバが作られていた。普通でなかったのは利用方法。そのサーバーには専用クライアントが 30 秒に一度、24 時間停止せずにアクセスしてくる。会員制サイトだったので、一回のアクセスごとに認証キーを入れ替え、クライアント側とサーバー側でつき合わせて整合しなかったら再度認証を要求という処理をしていたそうだ。(専用クライアントだからある程度融通が利いたのだろう)
当然ながら、認証キーは更新のつど PostgreSQL に保持される。さて、とりあえず開発がひと段落ついて、正式サービス開始前に負荷テストをしようということになった。40 台程度の PC を動員しクライアントソフトを起動した状態で放置して帰った翌朝の話。
サーバーの CPU 負荷は 100% に張り付き、ps の出力には postmaster が延々と並び、クライアントにはタイムアウトエラーのログがひたすら記録されていた。10 分単位で CPU 負荷をログ出力していたのでそれを確認してみると、開始直後は 5% 以下だった CPU 負荷が時間が経過するごとにリニアに上昇していき、8 時間後には CPU が 100% に張り付くようになっていた。
一応クライアントを全て停止して vacuume を試してから翌晩再度負荷テストを実行したところ、サーバーの CPU 負荷は昨晩と全く同一の挙動を示してくれた。データの更新件数が重なるたびに CPU 負荷が上昇していくらしい。結局その時は頻繁に更新される認証キー等をローカルファイルに直接書き込むことで対処したそうだ。（流石に 4 時間単位での vacuume というオプションは選択しなかったらしい）
有効なデータ件数は特に変わるわけではないのに（ロールバック用のデータだけが増えていくだけのはずなのに）なぜ CPU 負荷が上がっていくのだろう（どういうデータ構造にしてればそんなことがおこるのだろう）という感想を持ったのが記憶に残っている。PostgreSQL はいい RDB なのだろう。データ総数が 100 万程度で、インデックスも作成されていて、データの更新が滅多に起こらない環境では。(最近の PostgreSQL ではそんなことはないと思いたいのだが……)
以上の経験より、「現状のディスクローズ」に対する感想。
「よくわからないものを使うからこんなことになるのよ」
サービス開始前に負荷テストぐらいしてれば当然気が付いてただろうに。というわけで同情はしない。
どうして連休の度に「時間ねー」と叫びながら自宅作業をする羽目になってるのだろう。9 月最終週に余裕こいてログファイルを眺めるだけの生活をしていたのがまずかったのだろうか。
今回は 9 月の連休の時とは違って、残り作業がデバッグと調整だけだから少しは気楽な立場ってのが救い。10 月第 4 週を予備日として確保するためにも、今週 4 日間でアレとアレの見直しを済ませて、18 日の週からは高速化作業に進めるようにしておかなければ。
むー 420 出力プラグインでは func_get_video_ex() を使いまくって YUY2 を取得しているのだが……。拡張 AVI 出力の方でやってないのは歴史的事情と CODEC 毎に切り替えるのが面倒だったからで。98 系では飽和問題があるけど、一応受け取るだけなら 99 系以外でもできたはず。
仕事でくたばっている上に、「ひぐらしのなく頃に」を通販ページでぽちっとなしてしまったので 拡張 AVI 出力側作業は一回休み。
以下やりたいこと。
いつになったらやる気が復活してくれるのかなぁ（遠い目）
PSP は H.264 Main Profile に対応するのか。てっきり地上デジタルと同じで Baseline Profile で行くと予想していたのに。PSP の画面解像度だとインタレースに魅力を感じてという訳ではなさそうだから、やっぱり CABAC の圧縮率目当てなんだろうなぁ。
まー CABAC とインタレースに対応して Main Profile 対応というか、FMO だの ASO だのといった超時空な仕様に対応して Baseline Profile 対応というか、どちらかを選べといわれたら私でも Main Profile 対応の方を選ぶか。そっちの方がまだ現実的だし。
流石に Baseline Profile ただし FMO & ASO 除くといった規格無視な態度に出るわけには行かなかったのだろう。南無南無。当分は他人事で済むはずなので他人事モード。
今週末こそ仕事と無関係な生活をする予定だったのだけど……昨日一日をかけてもバグを潰しきれなかったのでデバッグ中。あー止まらないくせに結果が間違ってる系のバグは大嫌いだ。
潰しても潰してもバグが全滅しないので消耗が激しい。全部自分で書いたコードだから他人に責任を転嫁するわけにもいかないしなー。むーん。
何とか 14:00 まででバグ潰しに成功。アルゴリズム的にはもっと改善の余地がありそうだけど、手を入れる前よりは良くなってくれたのでこの辺で手を引こう。
週明けからは予定通り高速化の方に専念することにして明日は仕事とは関係ないことをやろう。このままだと心が腐れ果ててしまう。（既に愚痴が止められない辺りに腐敗の兆候が……）
そんなこんなで、実家のキューブ PC に電源を入れて FreeBSD の cvsup を済ませ、apache13/php5/mysql50 と ports から install。ルータで 22 番と 80 番の転送設定を行い外からアクセスできることを確認。これで外から突付ける実験マシンのセットアップが完了した。
AVI でのオーディオ対応も順調に作業が進展し……ているのだけどインタリーブの管理はプログラム側でやってあげなきゃいけないのかなぁというあたりで微妙に嫌な気分になっていたり。AVI2 への対応は何となく正しい構造をでっち上げてファイルに書き込む部分まで全部自前で作らなきゃいけないのかなという雰囲気でかなり嫌な感じ。DirectShow でまかなおうとする場合はやっぱりオーディオの供給フィルタとビデオの供給フィルタを作り、AviMux / FileWriter と順次繋いで Run をかけないといけないのだろうし……。正直どっちも泥沼。
当然といえば当然なんだけど Ultr@VNC は IPv6 対応していない。グガガガガゴギ。AirH" で VNC などという破滅的な行動を取らねばならないとは。時間さえあればソース調べて IPv6 対応してやるのにくそったれー。
昨日か一昨日の日経新聞の記事を読んで気になっていた「試験・研究目的での特許利用」に関する資料を発見したので読む。資料は「特許発明の円滑な使用に係る諸問題について」[産業構造審議会知的財産政策部会特許制度小委員会特許戦略計画関連問題ワーキンググループ] [特許庁]
一応私の立場を明らかにしておくと特許法 69 条 1 項に関しては拡大解釈派。つーか MPEG-2 VIDEO VFAPI Plug-In のおかげで 100% 利害関係者で、今のところ逃げ道がこの条文しかない状態なので。
で、そんな立場の私がこの案 (特に「1章」周辺) を読んでどんな感想を抱いたか。
おいおい、いわゆる先進国の中で唯一「試験・研究目的」の例外規定が明文化されてないアメリカの特許法と、そんな特許法を持つ国で争われた「デューク大学裁判」の判例を元に大学等での特許使用でも特許権者の許諾が必要とか言ってるよ……。
他の国で争われた事実がないって……例外規定の存在する国では当然のように訴訟が起きてないだけじゃないのか？ まるでこれから裁判が発生して、そこでアメリカ同様の判例が示されるといわんばかりの態度だな。おまけに「後発医薬品訴訟」での最高裁判決も「医薬品認可」という手続きにともなう特別な判決という方向に持っていきたい気配が濃厚。
あー特許法 1 条の精神はどこにいってしまったのかなぁ。
どうやら imtc.org から移転していたらしい。というわけでぐぐる神に発見してもらった移転先 [ftp://standards.polycom.com/]
ドキュメント読みたくなる度に google に「JVT 公式 FTP」などと入力して見つけてもらう日々というのも何とかしたいところだよなぁ。記憶力の低下を実感してしまう。
瀕死。今週１週間でどこまでもっていけるかなぁ。
旅立ちたい気分。何をやっても悪い方向にしかいかない。
どうやら、今週末は先週と違って気楽な気分で過ごせそうだ。先週は泥沼にはまってたからなぁ。
某仕事は何とか先が見えてきて、明日 & 来週 5 日間アセンブラコードをガリガリと書いていけばそこそこの性能のものが実現できそうという見込みが立ったところ。もっとも、それが達成できても周回遅れの状態でのドン尻でのゴールだからあんまり喜べはしないのだけど……まぁリタイアよりはマシだと思うことにしよう。
あー世界でもトップに伍して歩いてると実感できるような仕事がしてみたい。ちゅーか皆がゴールした後になってからスタート切らせるのは正直止めて欲しい。気力が続かん。
何か参考になるモノは出ていないかと、Intel のサイトを眺めていて見つけた、正気を疑ってしまう情報。"Understanding Memory Access Characteristics of Motion Estimation Algorithms" [動き検索におけるメモリアクセス特性の理解]
まだそんなに真面目に読んでないけど、なんだか「参照フレームから動き検索用のウィンドウ部分だけバッファにコピーしてきて、参照フレームよりもサイズの小さいバッファ内で検索する」とか書いてあるような気がガガガガガ。
ほんとにそれ効果あるのか、だってウィンドウ部分のメモリコピーってかなり重いはずだぞ、比較的検索範囲が狭くて済むダイヤモンドサーチベースの話みたいだけど、それでもコピーしたけど読まれない部分とかあるだろう。そもそも Dothan みたいな 2M の L2 cache もってる CPU なら SD 解像度の輝度 plane が全部乗るだろう。
結構良いのかも。Epson Direct から EdiCube F550H を (Mobile Athlon 64 3000+ モデルで) BTO した機械 (親向けに購入) が届いていたので、セットアップのついでに今仕事で作っているソフトを走らせてベンチマークを取ってみたのだが……予想よりもはるかに高速に動いてくれてる。
うーむ、非圧縮 AVI (YUY2) からのエンコードという HDD に足を引っ張られがちなベンチマークなのに、下手をしたらデスクトップの Prescott 3.6GHz (P4 560) マシンよりも高速に動いているような。高速化が煮詰まった時には機種選定の選択肢として推薦してみることにしよう。
9 月の中ごろに申し込んでいた実家の (TEPCO) 光の工事が昨日の午前中に予定されていたのだが……なにやらトラブルが発生した (多分導通チェックパスせず) らしく開通延期とのこと。次回工事予定日は 13 日を指定したので、2 週間の延期に。
まぁ中途半端に開通したフリをされて、1 kbps しかでないとかなるよりもマシなはずなので、我慢する。昨日は外も雨が降っていたし、作業も大変だっただろうから。
借りてる部屋の方は既に B flet's のマンションタイプになっているので、実家の環境も光への移行が済めば VNC 等で突付く際も楽になるはずだったのだが……2 週間だけなので待つことにしよう。