2008-04-30

HTML5規格が、だいぶ現実的になった

http://www.w3.org/html/wg/html5/
http://www.w3.org/html/wg/html5/

4月28日に更新されている。何が現実的になったかというと、style属性がグローバルになったことだ。また、font要素は廃止された。以前は、非現実的なことにstyle属性は廃止され、font要素はWYSIWYGエディタのためだけに残されることになっていたのだ。

なにがダメだったのかというと、少し前にも愚痴を書いているが、例えば、このブログがHTML5で作られている場合、文字色を指定するのが困難だということだ。確かに、CSSで文字色を指定することはできるが、ある記事だけで、ある色を使いたい場合、一体どうやって指定すればいいというのか。昔ならば、font要素が使えたし、今ならば、span要素にstyle属性を使えばいい。

<font color="#ff0000">アカの手先しか使わないobsoleteなマークアップ</font>
<span style="color : #ff0000 ;">ソビエトロシアでは、規格が君に遵守する!</span>

しかし、以前のHTML5では、そのどちらも廃止されていたので、16777216通りのクラスセレクタを作るか、style要素をscoped属性とともに使うしかない。

//style.cssあるいはhead要素内のstyle要素
//ブログである記事のためだけにこんなことをするのは非現実的
//これと似たようなクラスセレクタを、あと16777215個つくる。
.communist-color { color : #ff0000 ; }

//article.html
<span class="communist-color">ウラー</span>

//すくなくとも、ひとつのHTMLだけで記述できる、現実的な解決方法
//しかし、本当にこんな面倒な方法を取らなければならないのだろうか。
<article>
<style scoped="scoped">
.communist-color { color : #ff0000 ; }
</style>
<p>
<span class="communist-color">ウラー</span>
</p>
</article>

どちらの場合も、ただ文字色の色を変えたいだけなのに、恐ろしく面倒な記述が必要になる。たしかに、物理的なマークアップを排除して、純粋に意味でマークアップするのは理想的だが、現実のユーザは、ある特別な文字色を指定したいと思うはずだ。いままで簡単にできていたことが、HTML5でできないとなると、誰がHTML5など使いたがるだろう。あるいは、HTML5の使いたい機能だけ使って、残りはHTML4.01という、頭を悩ますひどいサイトだらけになるだろう。とりえあず、この問題は解決した。HTML5を使う価値が出てきたというものだ。

2008-04-28

アーサー王の死

騎士囚人、トーマス・マロリー卿が書き、ウィリアム・キャクストンが編集した、「アーサー王の死」の邦訳を読んだ。なかなか面白い。原文にも挑戦したいところだ。

Malory, Sir Thomas. Le Morte Darthur: Sir Thomas Malory's Book of King Arthur and of his Noble Knights of the Round Table, Volume 1
Malory, Sir Thomas. Le Morte Darthur: Sir Thomas Malory's Book of King Arthur and of his Noble Knights of the Round Table, Volume 2
Le Mort d'Arthur: Volume 1 by Thomas Malory
Le Mort d'Arthur : Volume 2 by Thomas Malory

ちらと目を通した限りでは、それほど難しいというわけでも無さそうだ。少なくとも、シェイクスピアより、よほど読みやすい。しかし、このあたりの英語は、今と違っている。少し調べなくてはならない。

どうも、15世紀ごろの英語を、Middle Englishと言うらしい。

特徴的なのは、やはり人称代名詞だろう。中性人称代名詞もあるようだし、なにより二人称単数がthou, thee, thyだ。三人称の女性代名詞も、今と発音がだいぶ異なるようだ。

動詞にも、まだ人称変化が残っている。今でこそ、三人称単数現在が残っているだけだが、当時はすべてあった。そもそも英語には、人称代名詞があるのだから、動詞の人称変化は、論理的に考えると、意味が重複しているわけで、必要ないと思われるのだが、まあ、あるらしい。一人称からそれぞれ、-e, -(e)st, -eþという。この、þというのは、今の英語で言えばthに似た発音らしい。これも含めて、四種類のアルファベットが、今の英語のアルファベットに加えてあるらしい。以上の事から、次のようになるのではなかろうか。

I have it.
Thou hast it.
Sche hath it.

また、名詞の変化もあるようだが、これに関しては良くわからない。

興味深いのは発音だ。当時はサイレントレターがなく、すべての文字を発音したらしい。たとえば、Knightは、/ˈknɪçt/という発音になるらしい。 今のような、/ˈnaɪt/ ではない。少なくとも、今の英語よりは分かりやすい。

うーん、大学に行くべきだったかなぁ。もうひと言語、学んでいれば、より深く言語を理解できるのかもしれない。

追記:
どんな言語にも例外はあるように、どうやら、よく使われる動詞には例外がある。haveの二人称単数の人称変化は、havestではなく、hastらしい。

x264が再びMSVCでコンパイルできるようになった

remove void* arithmetic from r821

なぜ修正に11日もかかるのだろう。しかも、直したのは、壊した本人じゃない。問題のコミットの当日に、コミットした本人と言い争っていたというのに。まあ、ひとつのコンパイラだけに依存すると、危険だということだ。どうも皮肉なことに、このpointer to void arithmeticというのは、GNU Cの「機能」だというのだ。やれやれ。

2008-04-26

Unified Function Syntax C++0x N2582

N2582 Unified Function Syntax

lambda expressionと、関数の戻り値の型を後ろに書くN2541は、よく似ているから、一緒にしてしまえというもの。lambda expressionと同じ文法が使える。

//いままで
int func(void) ;

//N2541
auto func(void) -> int ;

//N2582
[ ] func(void) -> int ;

予約語が、欲しいです。functionとかlambdaなんてありふれた予約語を、いまから作るなんて無理なことが分かっていても、やはり欲しいものは欲しい。

最近、面白かったものをふたつ

Auto Guitar Hero

マイケル父さんが、息子のアレックス君を負かすために作った、全自動ギターヒーロー。コンポジット信号をFPGAで解析して、ギターコントローラに信号を送っている。エキスパートレベルもノーミスでクリア可能。すべては息子に勝つために。

http://4mat.jp/experiment/divdiv
http://4mat.jp/experiment/divdivdiv
このスレより:http://pc11.2ch.net/test/read.cgi/hp/1189817507/

ほとんどdiv要素だけ構成されたサイト。経緯としては、HTML2.0にも、HTML5の方向性にも納得できない連中が、もうdivだけでいいじゃんと言い出し、実際に作られたネタサイト。

2008-04-23

結局gitってなんなの?

まあ、Yet Another Version Control Systemなわけだが、どうもCVSやSVNとは方向性が違うらしい。なにしろ、あのLinus Torvaldsによって書かれたのだ。CVSやSVNを無意味だと否定し、tar玉とdiffのほうが、まだいくらか使いやすいと公言するような人間だ。そんな人間がバージョン管理ソフトウェアを書くと、どうなるのか。

そもそも、gitはLinuxのカーネルの開発のために書かれた。Linuxのカーネルの開発は、かなり大規模で特殊だと思う。世界中にいる開発者たちが、コードを改良して、diffを送る。良いdiffは、公式に取り入れる。diffを作っている間にも、公式のソースコードは変更される。

そんなわけで、gitを書いたらしい。gitにはひとつの絶対的なレポジトリというのがないとでもいおうか。gitを使うと、どこにでもローカルレポジトリができる。このローカルレポジトリに対してコミットを行う。当然、本流と自分のソースは変わっていく。gitを使えば、本流から変更をひっぱってきたり、自分の変更とマージしたりできる。

とまあ、バージョン管理らしいことは一通りできるのだが、どう考えても使いやすいとは思わない。Linuxのカーネルのように、恐ろしく多数の人間が独自に変更してdiffを送るような、そういう環境でなければ、恐ろしく使いづらい。

まあ、何が言いたいかというと、stupid git!

そういえば、gitでググると、バージョン管理ソフトのgitがトップに来るが、コレはかなりすごいことじゃないだろうか。普通、gitといえば「ヤツ」を意味し、"stupid git"、とか、"ugly git"などと使われる単語のはずだ。ハリーポッターでも、頻出する決まり文句だ。Googleにおいて、そういう既存の用例を上回る評価をされるとは、よほどの影響力だ。

x264の64bitビルドがうまくいかなかった件について

俺:x264のx64ビルドがうまくいかねーよ
俺:mc-a.asmの413行がわけわかんねーよ
俺:なんだよ"cmp r4m, dword 4"って、typoかこれ?
Manao:それは俺のとこではコメントだ
俺:なんだよコメントって?
Manao:;----------------
俺:最新版のスナップショット落として使ってるんだけど?
Manao:git使え
俺:しゃーねーなー
俺:gitつかったけどmc-a.asmの413行はコメントじゃねーぞ
俺:スナップショットと同じじゃねーか
Manao:やべ
Manao:おれのローカルレポジトリがぶっ壊れてやがる

やれやれ、もうしばらくかかりそうだ。例によって私はhito

03:40 (hito) in mc-a.asm at line 413, there is "cmp r4m, dword 4" and yasm complains about it. what is r4m? is that typo?
03:48 (Manao) update your repository
03:48 (Manao) mc-a.asm:413 is a comment for me
03:48 (Manao) (and it's the second time you ask)
03:49 (Manao) (and that you get the same answer)
03:49 (hito) what is comment?
03:49 (Manao) for me, mc-a.asm:413 is :
03:49 (Manao) ;--------------------------------------------------------------------
03:49 (Manao) so it means your version isn't up to date
03:49 (hito) i just download a snapshot.
03:50 (Manao) install git and use it
03:50 (hito) i ll try it.
03:57 (hito) it's same here
03:57 (hito) i wonder why.
03:58 (Trax`) make clean and try again?
04:01 (hito) is clean a git command?
04:01 (Trax`) no just: make clean
04:01 (Trax`) to clear any leftovers from previous compile
04:02 (Trax`) or did you get a complete fresh branch?
04:03 (hito) i've never use git.
04:03 (Dark_Shikari) jbrjake: no, that's switching pictures
04:03 (Dark_Shikari) SVC is Scalable Video Coding
04:03 (Dark_Shikari) hito: you better start using it
04:03 (hito) i've just make dir and use this command : git clone git://git.videolan.org/x264.git
04:04 (hito) it create x264 directory
04:04 (Trax`) sounds ok
04:04 (hito) and mc-a.asm at line 413 is still not a comment
04:05 (hito) just same as snapshot.
04:06 (Trax`) same here
04:07 (Manao) umpf, my bad
04:07 (Manao) it seems i broke my local git repository, and git pull --rebase didn't update my repository
04:07 (Manao) so, hito, what gives yasm -v ?
04:07 (Manao) erm --version
04:08 (hito) 0.7.0 i think
04:08 (hito) 0.7.0.2066
04:08 (Manao) windows / linux ? if windows, cygwin / mingw ?
04:08 (hito) windows
04:09 (hito) it doesn't need cygwin so i guess mingw.
04:09 (Manao) and x86 or x64 ?
04:09 (hito) yasm is a x86 binary.
04:09 (Manao) but you're building for win32 or win64 ?
04:10 (Manao) for me, with cygwin and yasm 0.6.99, it builds without error
04:10 (hito) for win64. i don't have 64bit windows. but i just want to check if i could built it.
04:11 (Trax`) cygwin and 0.7.0.2066 yasm is fine
04:11 (Manao) Trax`: you build for win64 ?
04:11 (hito) yes.
04:11 (Manao) i asked Trax` :p
04:11 (hito) oops not for me :)
04:11 (Trax`) hmm no what switch is that
04:11 (Manao) win64 might be broken
04:12 (Manao) i don't know if anybody tested it since the huge macro frenzy to unify w86/x64 asm basecode
04:13 (Dark_Shikari) lol
04:13 (Trax`) so what configure option do I need for that?
04:14 (Manao) dunno, i never crosscompiled

2008-04-20

Google App Engineが面白そう

仕事も見つけないといけないのだが、実に面白いものも見つけたので紹介してみる。

Google App Engineというものが提供され始めたようだ。残念ながら、乗り遅れてしまったので、アカウントが取れなかった。しかし、将来のために、学んでおこうと思う。

Googleが動画で言っていることを、少し訳してみる。
transcript

そもそも、Webアプリを作るには、すべきことがたくさんある。まずコードを書かなければならない。もちろんそうだ。

しかし、そのほかにも、Apacheのconfigやらスタートアップスクリプトやらを書かなければならないし、SQLも用意して、テーブルやらパスワードやら何やらも作らないといけないし、トラフィックやログの統計を調べるために、モニタリングツールも設定しないといけない。バージョンアップをどのように行うかという問題もある。

技術的なことも、もちろん大変だが、これらをすべてやり遂げたとしても、まだ課題がある。実際に使うサーバが必要だ。どんな形であれ、どこかでアプリを動かさなければならない。それには、カネが必要だ。週に何度も使わないようなアプリでさえ、動かすサーバを借りるには、かなりのカネがいる。

金銭的な問題と物理的なことも、大変だが、まあ、コードを書き終えて、各種設定も終わり、サーバも買ったとしよう。問題はまだある。発展に伴う運用だ。サーバはクラッシュするし、設定ファイルはエラーだらけ、ハードディスクも潰れりゃ、トラフィックも増大し放題で、DBも直さにゃならんし、サーバも増やさにゃならん等々。アプリを動かし続けるのは大変だ。

GoogleはApp Engineを使って、この問題から解放(abstract away)してやろうというわけだ。

いやはや、なんとも。そしてそのabstract awayするために提供しているApp Engineが、実に興味深い。ディスクとかファイルなんてものはなく、なにか決められた物理的なサーバがあるわけではない。どうやら、Googleの他のサービスも、これを使って実装されているのらしいことをほのめかしている。データというものは、Googleの提供するDBとやらを使ってアクセスするのだが、どうもこれ、普通のリレーショナルなDBでは無さそうだ。無数のサーバに分散されているのだろう。

さて、まずはpythonを学ぶところから始めなくては。なんとも情けない話だ。

2008-04-18

pthread_pool、スレッドプールなライブラリ

pthread_pool

とりあえず公開。Windows VistaのThread PoolとCondition Variableを使い、かなり制限されたpthreadを実装している。ソースコードはとてもシンプル。ほとんど何もやっていない。MSVC限定。ライセンスはBoost Software License - Version 1.0

x264に使う目的で書いた。ある仕事をスレッドに丸投げして、結果を放置するか、待つ場合に使える。放置して、スレッドの終了を知る必要のない場合はpthread_detachを、待つ場合はpthread_joinを必ず呼び出すこと。さもないとリソースリークする。また、CRTはDLL版を使うこと。さもないと特定のCライブラリ関数を使った場合にリソースリークする。

スレッドプールで実装しているので、一度にいくらpthread_createをしても問題ない。VistaのThread Poolの実装はなかなか賢く、スレッドの消費するCPU時間などから、いくつスレッドを作り、いくつの仕事を実行するか、必要のないスレッドはいつ殺すか、などを判断してくれる。プログラマは何もする必要がない。ただ、プロセス中で最初から最後まで生きているようなスレッドの使い方には不向き。短時間で終わる。あるいは、終了時間は分からないが、とにかくプロセスの終了まで永遠に存在しているようなスレッドではない場合に効果的。

2008-04-17

理想は押し通せないものなのか

ある会社の面接を受けたが、地雷だった。面接官とさまざまなやり取りをしたのだが、どう考えても、この会社はまともではない。

まずやたらと、「例えどんなにソースコードが汚かろうと、動けばいい」ということを強調する。その引き合いに出す例がどうも納得いかないのだ。

例えば、速度がとても重要な場合は、クラスなど使うことはできないなどという。曰く、「クラスをどんどん深く継承すると、それだけコンストラクタを深く呼び出し、遅くなる」と。コンストラクタのインライン展開ができないコンパイラなのだろうか。

そしてさらに、関数を呼び出すだけでも遅くなるなどと言い出す始末。モダンなコンパイラなら、たとえ翻訳単位が別であっても、リンク時にインライン展開できるのだが。そもそも、すべてインライン展開すべきという妄信も疑問だ。というのも、インライン展開をすると、コードサイズが肥大し、キャッシュに載らなくなる。また、モダンなCPUならば、見えないレジスタを使って、スタック、特に関数のreturn addressをキャッシュぐらいしているだろう。本当に疑問だ。

とにかく、「汚くても動けばいい」ということを、金科玉条のようにしている面接官であった。

あと、「ほうれんそうって知ってますかね。ほうこく、れんらく、そうだん、ですよ。コレがとても大事で云々」、などと言っていたのだが、ひょっとして2chのVIPスレにあったブラック企業じゃないだろうなぁ。

ともかく、ここでは働けそうもない。ああ、どこか常に最新技術を追い求められる働き口はないものか。

ただいま、x264がMSVCでコンパイルできない件について

frame.cで、void *型に対するポインタ演算をしているためだ。報告しに行ったら、どうやら、gccではvoid *型へのポインタ演算は、1バイト単位での演算だとみなされるらしい。あたかもuint8_t *型であるかのように振舞う。なんて腐ったコンパイラだ。しかも言い草がこうだ。

「例えどんな単純な修正であっても、マイクロソフトの信者の要求は受けない」

お前な、Cのどの規格にも違反してるコードだぞ。しかも、そのコードを修正する前は、ちゃんとvoid *型をuint8_t *型にキャストしてから演算を行っていたのだ。何故それを見習わない。

ついでに、Cのキャストは嫌いだといったら、これまたC信者らしい意見で反論された。いわく、ugly。キャストはuglyな処理だからuglyな文法でいいのだ。そのコードを読んだものをして、なにかuglyな処理が行われていると知らしめるのが目的だ。D&Eを読め。D&Eを。

2008-04-16

Premature optimization is the root of all evil

かつてDonald Knuthは言った。"Premature optimization is the root of all evil."(下手な考え休むに似たり) と。

x264というH.264のエンコーダがあるが、これのマルチスレッドの実装は、1フレームごとにひとつ、スレッドを作るというものだ。しかも、pthreadだ。ここで私は思った。「Oh Please」と。「スレッドの作成と破棄は、高くつくぜ」と。スレッドプールで実装すれば、パフォーマンスがあがるのではないか、また、pthreadをWindowsでエミュレートするのは余計なオーバーヘッドがかかるのではないか、と思ったわけだ。

x264のソースコードを読んだ結果、pthreadを前提としたコードで、Windowsのスレッドには、容易に書き直せないことが分かった。しかも、スレッドプールにしなければならない。考えたあげく、ひらめいた。Windowsでpthreadを使いたい場合は、大抵はPthreads-w32を使うことになる。これは、有志が実装したpthreadだ。ならば、自分でも実装しない法はない。pthread_createで、実際にスレッドを作るのではなく、スレッドプールを使うのだ。

さて、Windows Vistaには、Thread PoolとConditinal Variableが実装されている。これらのAPIを使えば、やるべきことは、ただpthreadのラッパを用意することだけだ。プロセスを超えた処理はできないが、この場合、それは問題ではない。さっそくpthreadを実装しよう。

pthreadの実装は、実に楽であった。pthreadの仕様は、まあ悪くない。pthread_joinは、同じスレッドに対して複数回呼び出すことはできないという制限のおかげで、リソースリークもない。また、CRTで用意された専用のスレッド関数を使わなかった場合のリソースリークは、どうやらDLLを使うと、問題にならないらしい。完璧だ。

さっそく、pthread-win32と、私のpthreadの実装を比較してみた。結果は、残念なことに、パフォーマンスに差はなかった。さまざまなオプションで試したが、どうしてもエンコード速度は、誤差程度しか違わない。

そもそも考えてみると、x264の実装は、同時に実行されるスレッドは制限されている。スレッドの作成破棄のオーバーヘッドというのも、じつは私の環境ベンチマークした限りでは、0.1ミリ秒程度だ。対して、重い設定でエンコードしようとすると、秒間2~3フレームぐらいしかエンコードできない。1フレームの実行に500ミリ秒もかかっているわけだ。これはスレッド作成にかかる時間の実に五千倍に相当する。また、H.264は多重にフレームを参照できたりするので、あるスレッドが別のスレッドを待たなければならないことがよくある。などと色々理由は思いつくわけだ。それにしても、この結果は悔しい。

結局、出来上がったのは、64bitコードでも使える、限定的なpthreadのライブラリだった(pthread-win32は現在、64bitへのポータビリティに問題がある) x264で使っても、パフォーマンスは一切向上しない。やれやれだ。

余談だが、VistaのThread PoolとCondition Variableはとても使いやすい。また、今回pthreadの規格を深く読んだのだが、どうも納得のいかない点もある。これについてはまた今度。

2008-04-14

例年通り夏の風物詩

http://www.nhk.or.jp/kagoshima/lnews/01.html

14日午後、加治木町のパチンコ店の駐車場で止めていた車の中で1歳の男の子がぐったりしているのがみつかりまもなく死亡しました。

警察は母親がパチンコをしている間に車の中に残された子どもが熱中症にかかったものとみて調べています。 警察によりますと死亡したのは鹿児島市の34歳の会社員の男性の1歳7か月の長男です。

14日午後4時前、加治木町木田のパチンコ店の駐車場で、車の中でぐったりしている男の子を35歳の母親が見つけました。 男の子は病院に運ばれましたが、まもなく死亡が確認されました。警察によりますと、病院の医師の話から熱中症にかかったと見られています。 このパチンコ店では、おととし10月から敷地内に託児所を設けて子どもを無料で受け入れており、この母親も14日午後2時頃に子どもを預けに来ましたが、定員がいっぱいだったため、預かるのを断ったということです。

警察によりますと母親は駆けつけた救急隊員にパチンコをしていたと話したということで、警察では、母親が子どもを車の中に残したままパチンコをしていたものとみて調べています。

気象台によりますと14日の鹿児島県内は高気圧に覆われて気温が上がり加治木町に近い霧島市牧之原では、14日午後3時前に最高気温が平年よりおよそ4度高い21度9分と5月中旬並みまで気温が上がりました。

JAF・日本自動車連盟福岡支部の池田和人係長は「車の中の温度は直射日光の影響を最も受けやすく、強い日ざしが照りつければ短い時間で、一気に気温が上がる可能性があり注意が必要だ」と話しています。

パチンコ店によりますと、この店では、子どもを車内に放置されるのを防ぐため、おととし10月に、敷地内に託児所を設けて子どもを無料で受け入れています。

14日午後2時頃に、死亡した男の子の母親が託児所に「子どもを預けられないか」と相談に来たということですが、15人の定員がいっぱいだったため、預かりを断ったということです。 この店では、店内に託児所の利用を促すポスターを設置しており、この母親は以前にも託児所を利用していたということです。

鹿児島の夏は早いねぇ。

WILLCOM D4が欲しい

http://www.willcom-inc.com/ja/corporate/press/2008/04/14/index.html

驚くなかれ。なんとWindows Vistaが動くのだ。しかもAeroまで動く。コレはすばらしい

チップセットは US15Wを使っている。

用途は本当にさまざまだ。例えば、東方程度のゲームなら余裕で動くので、ゲームパッドを使って、外でゲームをするとか、USBハブを使ってキーボードとマウスを使い、FPSゲームをするとか、USBの外付けHDDを使い、アニメを観るだとか。

しかし、4亀の記事を見ると、Aeroはかろうじて動く程度らしい。残念。

2008-04-13

ICEBOXが売っていた

近所のファミリーマートに、ICEBOXが売っていた。私はこれに目がないのだ。

2008-04-12

求職中

まじめに仕事を探している。色々迷ったが、やはりプログラマとして生き、常に最先端の技術を追いかけ、プログラマとして死にたい。C++だ。Boostを仕事で使えるようなところで働きたい。

というわけで、京都市で、C++の文法とWindows以外何も知らない未経験の高卒を雇おうという奇特なところがありましたら、ご連絡くだされば無常の喜びに存知奉り。
とりあえず、来週あるところの面接に行く。問題は、C++が自由に使えるかどうかだが(C++と謳いながら、テンプレート禁止というところがあるらしい。にわかに信じられないが。)

給金に関しては、最低自給を満たしてくれれば何も申しません。ただし、あらまほしきはThe Programmer's Bill of Rightsでございます。

ひとつ、すべてのプログラマは、二つのモニタを有すべし
ふたつ、すべてのプログラマは、高速なPCを有すべし
みっつ、すべてのプログラマは、マウスとキーボードを、己の自由意志の元に選ぶべし
よっつ、すべてのプログラマは、快適な椅子を有すべし
いつつ、すべてのプログラマは、高速なインターネット回線を有すべし
むっつ、すべてのプログラマへは、静かなる職場をたぶべし

なお、重ねて申すことの候。
C++ Programmer shall have Boost as standard library.
C++プログラマは、Boostをもて標準ライブラリとすべし

x264のスレッドをWindowsネイティブに書き換えることについて

x264のソースコードを読んだが、pthreadからWindowsネイティブに書き換えても、それほど早くならないだろうと思われる。原理にはこうだ。

フレームごとにスレッドをつくる。スレッドは、そのフレームのみをエンコードして終了する。スレッド数の上限に達したら、一番古いスレッドが終了するまで待つ。

メインはpthread_createと、pthread_joinだし、Condition Variableなども使っているのだが、これをVistaでサポートされたAPIに置き換えても、劇的に速度が上がったりはしないだろう。ユーザモードで実装されているからだ。OSのサポートがあれば早くなる代物でもない。

マルチスレッドのエンコード速度をこれ以上上げるためには、スレッドプールを使わなければならない。これなら、WindowsのAPIを使うことで、ネイティブで実装する利点があるかもしれない。

とはいっても、どんどんスレッドプールにポストできないので、あまりWindowsの提供しているスレッドプールAPIを使う利点が見当たらないというか。

2008-04-11

MT bot prototypeを試してみた

ひろゆき氏も大絶賛のMT bot prototypeを試してみた。

http://zoome.jp/bookworm/diary/12

http://zoome.jp/bookworm/diary/12

x264の連中と言い争ってきたが、POSIXの連中とは話がかみ合わない

POSIXがすべてであると思っている連中とは、話が成立しない。はっきり言う。POSIXは独自規格である。Win32 APIとなんら変わらないのだ。hitoとは私の事。

00:08 (hito) when VC's project file are up to date?
00:10 (marnik) pengvado: so in a 720 25 fps progressive stream
00:10 (marnik) time_scale should be 50 and tick 1?
00:10 (marnik) because 25 fps progressive is 50 fields per second?
00:17 *T_RAY join #x264 (n=T_RAY@66.195.171.51)
00:17 (Gabriel_B) VC projects for win32 should be up to date, once you apply this: http://mailman.videolan.org/pipermail/x264-devel/2008-April/004361.html
00:18 (hito) still using nasm?
00:20 (hito) has anyone actually using nasm? it couldn't build x264's asm file.
00:21 (Quazgaa) you have to use yasm
00:21 (hito) i agree with that.
00:22 (hito) but if so, why they don't change project file to use yasm?
00:22 (Quazgaa) oh, you are talking win32 stuff, who cares about that ;)
00:23 (hito) me :(
00:23 (pengvado) nasm Works For Us
00:23 (pengvado) you need a recent version, but then old yasm doesn't work either
00:24 (pengvado) Gabriel_B: of course I haven't tried it, but I can tell just by looking that the patch breaks Release64
00:24 (pengvado) not that it was working before the patch
00:24 (Gabriel_B) really?
00:25 (Gabriel_B) hummm....was win64 supposed to work?
00:25 (Dark_Shikari) lol
00:25 (JEEB) lol
00:25 (marnik) anyone on my last question?
00:25 (pengvado) not really, last I heard of it was maybe a year ago when squid_80 was updating
00:26 (pengvado) marnik: yes
00:26 (Gabriel_B) so anyhow, win64 was already further broken since you reorganised asm code
00:27 (hito) I've never build win64 since i use 32bit Vista.
00:28 *microchip_ quit (Remote closed the connection)
00:28 *microchip_ join #x264 (n=microchi@78-23-99-124.access.telenet.be)
00:28 (pengvado) hito: and you never wished your cpu was 15% faster?
00:28 (Dark_Shikari) there should be a doom9 rule that if you post a certain number of consecutive retarded threads
00:28 (Dark_Shikari) you get banned
00:28 (Dark_Shikari) "3NC0D3_Y0_A$$" seems to be working very hard at this
00:28 (iive) pengvado: what kind of error is produces when sse2 does unaligned access?
00:28 (marnik) great
00:28 (JEEB) the nickname says it all < Dark_Shikari
00:28 (marnik) thanks
00:28 (Dark_Shikari) lol
00:29 (iive) segfault or bus error
00:29 (Dark_Shikari) iive: I've gotten segfaults on Windows
00:29 (marnik) what version of x264 should i use? I am using 20070924, read through the changelog, should i update for speed/quality/stability or stick to that version?
00:30 (Dark_Shikari) you should generally update =P
00:30 (Quazgaa) update :x
00:30 *T_RAY quit (Read error: 104 (Connection reset by peer))
00:30 (Dark_Shikari) speed has gone up probably over 20% in the past month
00:30 (hito) pengvado: maybe i ll use 64bit Windows 7.
00:30 (marnik) cool
00:30 (Quazgaa) i update every time i rip something ;)
00:30 (JEEB) I try to keep up with jarod's builds <_<
00:30 (marnik) and when using x264 with vlc to encode, does it matter what version of vlc i use?
00:31 (marnik) i mean, 0.8.6f vlc, should work with the latest x264?
00:31 (Dark_Shikari) well, I wouldn't encode with VLC unless I absolutely had to do streaming
00:31 (Dark_Shikari) but I assume it would work
00:32 (marnik) i absolutely have to do streaming :)
00:32 (JEEB) How do you encode via CLI x264 via VLC o_O
00:32 (Dark_Shikari) you use libx264 in vlc
00:32 (JEEB) ah
00:32 (JEEB) alrighty
00:38 (Gabriel_B) pengvado: here it is: http://pastebin.com/m4385fd34
00:39 (Gabriel_B) it doesn't fix win64, but doesn't break it further
00:41 (hito) speaking of win32. i really want rename fix for win32.
00:42 (Dark_Shikari) it already works fine on win32
00:42 (Dark_Shikari) what you want is rename fix for *MSVC*
00:42 (hito) no it doesn't
00:42 (Dark_Shikari) I know it does, because I'm using it right now
00:42 (Dark_Shikari) and I already proved that it works fine
00:42 (hito) C99 spec say it "implementation-defined"
00:42 (Dark_Shikari) Yes, and when compiled with gcc, it works fine
00:42 (Dark_Shikari) Since MSVC support has been broken for over a month now and nobody has really cared
00:43 (Dark_Shikari) I don't think its that important
00:43 (Gabriel_B) What's the problem with msvc?
00:43 (Gabriel_B) I am using it right now
00:43 (Quazgaa) its the devil
00:43 (Dark_Shikari) Its rename function does not overwrite the target file
00:43 (Dark_Shikari) apparently
00:43 (JEEB) does mingw have speed problems with the win32 build?
00:43 (Dark_Shikari) (according to hito)
00:43 (Dark_Shikari) if by "Speed problems" you mean "its too fast", maybe
00:43 (JEEB) alrighty then
00:44 (JEEB) I was thinking why people want to build a certain app "native to win32" with MSVC
00:44 (Gabriel_B) well, if someone could explain me what is the faulty behavior, it could perhaps fix it
00:44 (pengvado) mingw is native win32
00:44 (JEEB) ah
00:44 (pengvado) cygwin is what's non-native
00:44 (JEEB) alright, I stand corrected then
00:44 (Dark_Shikari) and x264 uses mingw even under cygwin
00:45 (hito) according to ANSI C and C99 spec, whether rename() overwrite file or not is "implementation-defined"
00:45 (hito) POSIX spec says it overwite.
00:45 (Dark_Shikari) that's one reason we like POSIX.
00:45 (hito) MSVC's rename function doesn't overwite file.
00:46 (Gabriel_B) hito: and what is the erroneous behavior that the user would notice?
00:46 (pengvado) and x264 defines rename to be unlink,rename
00:46 (Dark_Shikari) it doesn't overwrite the second pass file
00:46 (pengvado) what's the problem?
00:46 (Dark_Shikari) e.g. if you have a twopass file in the directory
00:46 (Dark_Shikari) and run another encode
00:46 (Dark_Shikari) or a third pass
00:46 (hito) if i want to multi pass encode, it doesnt overwrite log file
00:46 (JEEB) now why would POSIX be against the ANSI C specs <_<
00:46 (Dark_Shikari) JEEB: it isn't
00:46 (pengvado) does C99 also say it's implementation-defined whether unlink unlinks its file?!
00:46 (Dark_Shikari) lol
00:46 *herrwaldo join #x264 (n=waldo@ip-81-11-224-63.dsl.scarlet.be)
00:46 (Dark_Shikari) I would think its far more likely that MSVC breaks the specs ;)
00:47 (Gabriel_B) this is starting to look like a friday afternoon discussion
00:48 (pengvado) or not. man 2 unlink says it isn't even in c99, only posix. so if msvc is known to not be posix, yes, it probably does not unlink the target of unlink.
00:49 (pengvado) JEEB: what's against what?
00:49 (Gabriel_B) I think that msvc is said to be posix, but is known to not be posix
00:49 (pengvado) if c says implementation define, and posix defines something, it's just being an implementation
00:53 (hito) The question is whether x264 rely on POSIX(sadly standard doesn't mention about thread and such) or standard C spec.
00:53 (pengvado) x264 relies on the intersection of gcc, mingw, and linux
00:54 (pengvado) standards compliance and other compilers is just gravy
00:56 (hito) so i must modify rename function every time i build...
00:57 (pengvado) I'm still interested to know what msvc does with unlink() other than delete something
00:59 (Gabriel_B) want a good laugh? Here is the msvc doc for unlink: "This POSIX function is deprecated beginning in Visual C++ 2005. Use the ISO C++ conformant _unlink instead."
01:00 (pengvado) oh, right. every since standard compliant function in msvc is preceded by one or more _.
01:01 (hito) i think unlink is a posix function
01:01 *myrdred quit ("KVIrc 3.2.6 Anomalies")
01:01 (pengvado) and msvc says posix is deprecated
01:01 (hito) i can't find it in C99 spec.
01:01 (pengvado) so yes, you can edit it every time you want to compile
01:05 (hito) there are standard C library and POSIX C library. POSIX is NOT a standard C and vice versa.
01:05 (Gabriel_B) hito: do you mean that you noticed an unwanted behavior when using msvc, you know how to fix it, but did not reported your fix??
01:12 *Bombo_ join #x264 (n=bombo@dslb-084-060-235-183.pools.arcor-ip.net)
01:12 *backgroundman quit ("Leaving")
01:13 (Gabriel_B) I just tried --pass 3, and it works fine, even with msvc
01:14 (Gabriel_B) and unlink really removes the file
01:15 (Dark_Shikari) maybe its only the most recent versions of their compilers?
01:15 (hito) there is unlink in msvc for backward-compatibility.
01:15 (Gabriel_B) I'm using vc8, since this is the freely available version
01:16 *emtee quit (Read error: 104 (Connection reset by peer))
01:16 (Gabriel_B) anyhow, here it works fine
01:16 (Gabriel_B) hito: which compiler are you using?
01:16 (hito) VC8 and VC9
01:16 (hito) Express
01:18 (Gabriel_B) and on your side, the "stock" x264 version doesn't properly unlink ?
01:18 (Gabriel_B) with vc8??
01:19 (Gabriel_B) wondering how you fixed it to also work on your side...
01:20 (hito) thats weird.
01:21 *Bombo quit (Read error: 110 (Connection timed out))
01:21 *nick Bombo_ → Bombo
01:22 (Gabriel_B) paste your fix, that might give us indications regarding what is happening
01:22 (hito) i just use MoveFileEx
01:23 (hito) its not portable
01:24 (Gabriel_B) that's definitively a win32 function
01:24 (hito) yes.
01:24 (hito) in your windows. MSVC rename overwrite file?
01:26 (Gabriel_B) no, as mentionned within the doc
01:26 (Gabriel_B) but x264 is using unlink in win32 case
01:27 (Gabriel_B) #define rename(src,dst) (unlink(dst), rename(src,dst)) // POSIX says that rename() removes the destination, but win32 doesn't.
01:27 (Gabriel_B) perhaps, for a yet unknown reason, you don't get that define?
01:28 (hito) i ll write it.
01:28 (hito) but in that code which runs first?
01:28 (Gabriel_B) unlink, then rename
01:29 (hito) unlink? or rename?
01:29 (Gabriel_B) I tried it under the debugger
01:29 (Gabriel_B) and witnessed the stat file vanishing upon unlink
01:31 *Gabriel_B quit (Read error: 104 (Connection reset by peer))
01:32 (hito) oh uh
01:33 (hito) i wonder does he come back.
01:36 (JEEB) I guess as soon as he resets
01:47 *moonwatcher join #x264 (n=lg@89-138-180-132.bb.netvision.net.il)
01:50 (hito) its 1:49 AM in japan. perhaps i should take a nap.
01:50 (hito) #define rename(src,dst) !MoveFileEx( src, dst, MOVEFILE_REPLACE_EXISTING )

unlinkはPOSIXの独自規格だ。それにしてもいまだにプリプロセッサのマクロを多用するとは、なんだかなぁ。

まあそれでも、英語は実に便利な言語だと思う。敬語だとか言うわけの分からない文法がないからだ。

2008-04-09

サウスパーク貼り付けテスト

次回のサウスパーク予告

2008-04-08

Extreme Torch Relay

http://torchrelay.beijing2008.cn/en/journey/paris/news/n214296587.shtml

このように、終始和やかな雰囲気で、フランスはパリの聖火リレーは執り行われました。中国人しか映ってない気がするけど、たぶん気のせい。

エクストリーム聖火リレー

追記
4月9日に行われる、サンフランシスコのエクストリーム聖火リレーのルートが変更されたようです。サンフランスシスコの市長によると、変更後のルートは公開しないとのこと。次のエクストリーム聖火リレーは「かくれんぼ」になった模様。

Boost.Range

Boost.Rangeは結構いろんなところで使われているけれど、ドキュメントが分かりにくいのではないか。

仕組みはとても簡単で、その思想は、「イテレータを扱うときに、二つの変数を使うのがうっとしいから、ひとつにまとめましょう」ということだ。iterator_rangeクラスは、外から見ると、まるでSTLのコンテナのように振舞う。例えばbeginやendというおなじみの関数があるし、イテレータの種類の違いによって、例えばランダムアクセスイテレータならば、operator []関数も用意されている。だから、STLのコンテナのように使ってよい。(イテレータ部分のみだけ)

とはいえ、既存のC++のコードとも共存したい。そこで、boost::beginやboost::endのような関数も用意されている。

まあともかく、使ってみようと、既存のコードをRangeで書き直そうとしたが、どこかを書き間違えたらしく、コンパイルが通らない。しかもエラーは、このおれの書いたコードのおかしい箇所ではなく、boost/range以下のヘッダファイルを指し示すのだから、さっぱりわからない。
方法を変える事にした。イテレータを使っているコードを人間が修正しようとするから、ミスが起こるのだ。既存のイテレータを使っているコードは完璧に動くのだから、ラッパでも用意してやればいい。ということで、既存のイテレータのコードへのRangeのラッパを用意して、実際の処理は既存のコードに丸投げしてみた。うまく動いた。

実際、Rangeとイテレータで同じ実装を二度書くのも馬鹿馬鹿しいし、やはりこういうのが一番いいのかな。便利だし。

2008-04-07

優秀なスナイパーになる条件

http://www.recordchina.co.jp/group/g17456.html
ぽっちゃりした内気なガンマニアであること。
射撃で抜群の成績を持つこと。
視力が2.0以上であること。
忍耐力など強い精神を持っていること。
共産党の政治方針を支持していること。

最後の項目は、支持していなければ政治犯として生きたまま臓器を摘出されて外貨獲得の手段にされるから問題ないとして、なんだかデジャヴが……。

http://www.youtube.com/watch?v=ysRLZIlcQsU

2008-04-04

POSIXとC99のrenameの違い

x264というH.264のエンコーダがあるが、この実装に、不具合ではないかと思う挙動がある。マルチパスのログファイルを出力し終えて、リネームする際に、Cのrename関数を使っている。このとき、リネーム先のファイルが存在した場合、常に上書きするというAssumptionがある。これはおかしいのではないか。

まずは規格を参照されたし。
POSIX renamel
C99 rename

POSIX規格では、renameは上書きするとなっている。
C99(renameの仕様はANSI Cから変わっていないはず)では、"implementation-defined"、となっている。
やれやれ、問題は複雑だ。そもそもx264の開発者には、*unix信奉者がとても多い。現にMSVCのrenameは失敗すると言ったら、「糞MSが標準規格に沿ってないんだ」と返された。そういう連中を相手に、「それはPOSIXだけの独自規格なんだよアホ」、とconvinceしなければならぬのか。

2008-04-03

東方花映塚 山田対霊夢

dannmaku(弾幕) shooting game "touhou kaeiduka"(東方花映塚)
山田対霊夢
http://zoome.jp/bookworm/diary/11

You need Flash Player

2008-04-02

x264のAQを試してみた。

dannmaku(弾幕) shooting game "touhou kaeiduka"(東方花映塚)
http://zoome.jp/bookworm/diary/10

You need Flash Player

Monty Pythonが面白い

モンティパイソンがとても面白い。例えば有名な、SPAMの歌など

あるいは、勇敢なるロビン卿の歌など。

勇敢なるウソップ卿の歌