整数 IDCT の MMX 化成功。バグがなんとか取りきれたので、Ver. 0.2.9 として公開。
う〜ん。あんまり速くならなかったのがちょっと残念。一応 IDCT 関数だけで見れば半分程度にまで高速化できてるみたいなのにトータルでは 2 秒しか結局速くなってくれなかった。
他にも最適化できそうな所としては、逆量子化や可変長符合のデコード周辺とかがまだあるのだけど、とりあえず IDCT の MMX 化が終ってヤマを超えたので、最適化は一時中断。Ver. 0.3.0 に向けてプログラムストリームへの対応をはかることに。
う〜ん、悪友Ｋの方ではどうなっているのだろう。浮動小数点 IDCT を作った後で、システムストリームについて少し調べてくれるようなことも言っていたのだが……。
残念。悪友Ｋの方は本業が忙しいらしく、コードを書いてる余裕が無いらしい。仕方がないので、ISO/IEC 13818-1 をようやく読み始めてる。
といっても、本当に眺めてるだけなのでさっぱり理解は進んでいない。一応予備知識として大体のことは判ってたつもりだったのだけど……。
なんだかな〜、こりゃちょっと時間がかかるかも、うん。
で、当面サポートするつもりがないトランスポートストリームの方だけど、インタフェース 11 月号で、BS デジタル放送の特集組んでたんだね〜。知らなかった。
パラパラとめくってみた限りではトランスポートストリームとかについても書いてあってなかなか面白そうだったのだけど、今日の飯も怪しいくらいに貧乏なので購入できず。もう１週間はやく気が付いてれば金が残ってたのにとちょっぴり悲しくなってしまった。
とりあえず記憶を頼りにこんな数字だったはずという値に戻したのだけど……どーやらロックがうまく行われてないらしい。
一瞬カウンター無しのページにしようかなとも考えたのだけど、それも嫌だったので、ちょっとロックのやり方を変更。symlink 形式にした。
flock とかが安定してればそっち使ったほうがよいのだけど、最近どうなのだろう、昔試した時は NFS 経由のせいか、２重ロックかかってしまい、どうしようも無くなったので諦めた記憶があるのだけど……。
とりあえず１週間ほどテスト運用して、問題ないようだったら pub/bin のも置き換える予定。
ぼーっと m2v.vfp のアクセスログを眺めていたら……、なんじゃそりゃと言ってしまいたくなるものを見つけてしまった。
GET /%257Eee69011/mpeg2/m2v_vfp.lzh HTTP/1.0 404 298
ってそりゃ 404 になるだろうそんな URI じゃ。なにしろそんなディレクトリ無いんだし。なんだか定期的にリトライ繰り返してるところを見ると、何か DL ツールを使ってるのだろうか？
う〜ん、'~' (チルダ) を %7E と URI エンコードしてるのを、さらに % をエンコードして %257E ですか……
とりあえず、対策としてはそんなツール使うのやめなよと助言してあげることぐらいだけど、でもホント、~ と %7E ってどっち使うのが安全なんだろうね（正しい、正しくないは別にして）
しばらく前にダウンロードしたっきりで放っておいた Windows Media Format の SDK に何となく気が向いたので目を通してみたのだけど……。
悲しいことに、C++ インターフェースしか用意されてない。
う〜ん、C++ はあまり好きじゃないのだけど、C プログラムから C++ インタフェースを呼び出すのってできたっけ？
１週間経った のでカウンタを新バージョンに置き換え。
ほとんど Ver. 2.4 と同じなのだけど、image オプションの挙動が少しあやしいみたい。ドキュメントを確認しようとしたのだけど、オリジナルサイトが何故か 404 なので調べられず。
まあ、image オプションを使う人は居ないだろうからということで気にしない（一応後で調べてみる）ことにして、サンプルは image オプションを使わないで済む形に変更。
多分これで、データは飛びにくくなるはず。（飛ばなくなるとは言いきれない）
PS に対応するために、とりあえずファイルフォーマットの勉強も兼ねて、デプレクサを作ろうと決意した。
うん、これ以上規格眺めてても何も身につきそうにないし。とりあえず PES の詳細については書いてある場所が判ったので、手を動かしてみようと思って。
まあ、作ってるうちにうまい処理方法が見つかるだろうとか考えてるのは……考えが甘いかな〜。
何となく考えてる方法としては、とりあえず PES パケットデータをそのままバッファに入れる形にして、PS は read(), seek(), tell() 互換で取り扱う形にしてみようかな〜（この場合、videostream.c のみの修正で済む）というのがあるのだけど、問題はきれいに作れるかどうかなんだよね。
まあ、今回は（公開するつもりのないソフトだし）そういったことを意識せずに、気楽に書く予定。
バイトの給料が入ったのでついつい散財してしまった。こういうことしてるからいつまで経っても貧乏なんだと、判ってはいるのだけどね。
しかし、本だけで１万円超えるところだったというのはちょっと問題かも。内訳は「オブジェクト指向スクリプト言語 Ruby 」（まつもとゆきひろ・石塚圭樹／ASCII）「画像処理工学」（村上伸一／東京電機大学出版部）「成恵の世界」２巻（丸川トモヒロ／角川）「インタフェース」２０００年１１月号（CQ 出版）
ついでに、はやまってゲームも１本買ってしまった。やってる時間もないというのに……そのうち遊ぶ時間ができると良いのだけど。
しっかし、つくづく趣味に走ってるな〜。まあ自分で買う本なんてそんなものなのだけど。
大失敗。かろうじて、首の皮一枚でまだ望みは切れていないのだけど、かなり厳しい。完全に自分のミスだから非常に痛い。
あ〜、あちこちに迷惑かけてしまったからこれはもう、無理かも（いや、望みを捨ててはいけない）
とりあえず、こっち をもっと形にして、１１月になるまでにせめて PS 対応だけでも済ませておかないと……。
大体 PS の中身が判ってきた。ただ、今一つ良く判らないデータがあるのはどうしたら良いものやら。とりあえずデプレクサを作るだけなら現状の知識でも何とかなりそうなのだけど、最終目標は MPEG-2 のカット編集ソフト作成だから、いずれマルチプレクサ作るときに苦労しそうな予感がする。
さて、とりあえず規格の方は一通り目を通したので、実際の PS をバイナリで眺めてみたのだけど、ちょっと考えていたのとは違うみたいだ。
PS はパックで構成されていて、パックは複数の PES パケットで構成されていると書いてあったので、ビデオストリームとオーディオストリームで大体同じ時間単位で区切って PES をパックにまとめているのかと考えていたのだけど、幾つかのソフトで作成されたプログラムストリームを見た限りでは、パックには一つしか PES パケットが入っていないように見える。
大体、オーディオとビデオは同じ時間単位で多重化されてるみたいだけど、パックはそれぞれ独立で、１つにまとまっている訳ではない。
当てが外れてしまった。PES の編集するときはパックの SCR を読みながら、適当にパック単位で切り張りしてあげれば済むかと思っていたのだけど、どうやらそう甘くはいかないらしい。
課題： オープンソースのマルチプレクサを一つ入手しておくこと（VBR 対応のものが望ましい）やっぱり規格書だけじゃコード書くの難しい。
デプレクサの作成が煮詰まったので、気分転換を兼ねて分岐予測に関してのメモをまとめておく。
まず、前回 投機実行（特に静的分岐予測）についてあれこれ書いたけれども、実際のコードでは、普通、静的分岐予測アルゴリズムについて考える必要はなかったりする。
何故かというと、投機実行に際して静的分岐予測アルゴリズムが適用されるのは最初の１回目のみで、２回目からは前回の分岐結果を参照して、そちらに分岐するものと投機実行されるから。
静的分岐予測アルゴリズムを考慮せずにコードを書いたとしても、速度的に問題になるような場合（頻繁に実行される分岐 == ループの中の分岐）では、前回の分岐結果を参照した、動的分岐予測アルゴリズムが適用されるため、普通の場合は速度上の問題が発生することはない。
但し、以上の議論はあくまでも普通のコードの場合。普通でないコード（例えばループの中で数千個単位の比較＆分岐が存在する場合とか）では、これはかなり違ってくる。
動的分岐予測アルゴリズムの問題点は他のあらゆる問題と同様に「有限な資源」という一言に集約される。分岐予測の場合の資源とは、BTB (Branch Target Buffer - 分岐予測テーブル) のことで、BTB は他の資源と同様にサイズに限界がある。
Pentium III の場合、BTB のサイズは 512 個でこれ以上の分岐は記録できない。BTB が溢れてしまった場合は（多分だけど）一番古い分岐から上書されていく。この場合は動的分岐予測は不具同然になって、常に静的分岐予測しか使われなくなる。（当然遅くなる）
この場合の正しい対応としては、比較と分岐を静的分岐予測アルゴリズムに適応させることではなく、ループ内部の分岐を減らすとかループを分割してループ内部で BTB が溢れないようにすることだったりする。
「ソースがドキュメントです、バグも全て記述されています」
……う〜ん、確かに正しい意見なんだけど。あまり同意したくない。
例えば、MSDN 無しでレジストリから設定値を読書きする関数を書けって言われた場合、ひょっとしたら既に全部覚えてて簡単に書いてしまう人もいるのかもしれないけど、大抵の人はちょっと待ってくれと言うと思う。
これは Windows のソースが公開されていないからとか、そういう問題ではなく、たとえソースが公開されていたとしても読みたくならない。（というよりも、何処に書いてあるのか探したくない）
うん、欲を言えば両方そろっているとありがたいのだけど、ソースとドキュメント、どちらかを選べと言われたらドキュメントの方を選びたい。こういうことを希望するのは私が軟弱なせいなのかもしれない（漢は黙ってバイナリ直読みハンドディスアセンブル？ 確かにその通りだね）
まあ、中にはソース非公開のくせにドキュメントも不十分という論外なものも（特に Windows 用のライブラリ等で）あるけれども、ソース非公開のライブラリの方が、全体的にドキュメントの質が高いように感じるのは気のせいなのだろうか？
で、ソースのみ公開のと（ソース非公開だけど）良質なドキュメントが付属しているものを比較すると、圧倒的にしっかりとしたドキュメントがついてるものの方が使いやすいのだよね。
卒研のほうでもこ〜ゆ〜目にあうとは……。
え〜と、卒研で使っているのは FHI98MD という第一原理分子動力学シミュレーションのパッケージなのだけど……ドキュメントが英語だけなのはまあ良いとしよう。ドイツ語じゃなくて良かったと感謝すべきなのだろうから。
ただ、ドキュメント化されていない仕様がてんこもりで、サンプルでもそういったものを使いまくっているため結局フォートランのソースを読まなければいけなくなったりして……うきぃぃぃぃ。
あ〜、うん。ちょっと取り乱してしまった。
当然ながら、日本語の資料なんてものは バンド計算入門（小林一昭 さんのページ）ぐらいにしか見当たらない。（見当たるだけ仕合せだという説もある）
あ〜。なんか使い方調べてるだけでタイムアウトしてしまいそうな予感がする。こんな事で良いのだろうか？
2001, 8/17 - 小林一昭さんのページへのリンク修正
笹本 祐一「ブループラネット」（朝日ソノラマ）購入、読了。
なかなかよいお話でかなり楽しめた。お奨め。後半すこし ？ な展開があったけど、そういう演出ならそれはそれでありかと納得できる。
まあ、私がこんな事を書かなくても好きな人は既に買ってるだろうから、内容についてこれ以上云々はしない。ただ、SF がそこそこ好きで、まだ「星のパイロット」シリーズを読んだことが無い人が居れば、是非試して欲しい。きっと後悔はしないだろうから。
最近自宅の OS を Windows 2000 に移行した。何故かと言うと MO のアクセスが本格的にへたって来て 3M 以上のファイルを読もうとすると「シリアル NO XXXX-XXXXX」のメディアを入れてくださいという青画面が表示されるようになってしまったから。
新しく入れた FastTrak 66 のドライバがまずかったのか、それとも GV-DVC/PCI のドライバがまずかったのか、富士通の 2048 byte/sector VFAT32 パッチが悪いのか……と色々と試した挙げ句、どうにも復活できなかったので復旧を断念。
どうせ再インストールするのならばというわけで、大学の NT 環境でプログラムのデバッグをするのも辛くなっていた事だしと Windows 2000 を予備の HDD にインストール。
結果は MO のアクセスも無事に復活。100M 単位のファイルでも無事に読書きできるようになった。
以上は良かった点。で、悪い点。
インストール前から判っていたことだけど、MV-300 は 2000 用ドライバが無いため Windows 環境からは使用できず。とりあえず今の所は不明なデバイスとしてぶら下がっている。最近 MV-300 は linux からしか使ってないから良いかというわけでこの点については納得済。
次に、RICOH MP9060A OEM の Caravelle RW6424/DAK で DMA が効かなくなる。元々 MB の BIOS で DMA ON にするとブートしてくれなかったので BIOS では DMA OFF、Windows 98 では DMA ON という姑息な手段で対処していたのだけど、2000 では厳密なチェックしているらしく DMA が ON にできなくなっていた。この状態で DVD などを再生させようとすると、ROM アクセスの度に CPU を占有して実に素晴らしいガタガタの再生をしてくれる。これには我慢ができなかったので、Pioneer の DVD 115 を購入。ただし、こちらはこちらでアクセス時に盛大な騒音を立ててくれるので、そのうち買い換えたい気分で一杯。速度制限ユーティリティとかが無いかと探してみたのだけど見つからなかったのが残念。
まだ 2000 環境に移行して 1 週間程度しか経っていないので、とりあえずの感想はこの程度。その内もっと嫌な点に気が付くかもしれないけど、それについてはまたの機会に。