自分の作業レポジトリをMercurial Queueに移行した

いまいちMercurial Queue (以下MQ) の使い方がわからなかったので使ってなかったのだけど、週末に自分の作業用のレポジトリをMQに移行した。その際のメモ。

1. 現在使っている自分自身のハードディスク内のレポジトリからパッチをすべて作成し直す。

バグ毎にパッチを再作成。追加ファイルの場合は、先にhg addしておかないと、パッチの中に入らないので注意

2. hg cloneをやるか、hg revertをやって、レポジトリをきれいにする。

hg revertをやった場合は、*.origファイルができてしまうので、hg cloneで別のディレクトリにレポジトリのクローン使った方が楽(時間はかかるけど)

3. hg qinitの実行

.hg/patchesというディレクトリが作成される

4. hg qimport -n <パッチの名前> <パッチのファイル名>をすべてのパッチに対して実行してパッチをインポート

先ほどできた.hg/patchesの中にパッチファイルが作成される。hg qimportだとパッチが当てられた状態にはならないので、必要に応じてhg qpushでパッチを当てる。-aオプションを使えば全部のパッチを当ててくれる。

思ったより簡単だった。hg pushなどをする時には、hg qpopでパッチを取り除いておけばいいだけ。

あと注意点として、hg qrefreshでパッチファイルを更新する際、追加・削除のファイルがある場合は、hg qrefreshする前に、hg addやhg removeなどを実行しておくこと。この動作にちょっと悩んだ。

TraceMonkeyの話パート2

AdobeというかMozillaというかFirefox 3.1に入るJavaScript JITの話の続き

mozilla-centralにコードは入ったのだけど、常用にできる状態では当然ない(もちろんデフォルトでOFFにされている)。NanoJIT自体は、x86 / x86_64 / ARM (Thumb) をサポートしているのだけど、x86 以外は確実に落ちるはず。もともとtracemonkey自体は、tamarin-tracingのnanojitのコードをmozillaのactionmonkeyに持ってきているんだが、ようやくx86だけは動く状態なだけ。x86_64とかARMは、ただコードがあるだけだし (ARMがあるのはFlash LiteがARM上で動くからだったはず)、x86_64のコードなんてCalling Convertionから間違っているからね。

Nanojitのコードを追っかけたい人は、mozilla-centralの方じゃなくて、tracemonkey側を追っかける必要がある。現在こっちのツリーでバグフィックスしまくりなので。

TraceMonkey (JavaScirpt JIT)のコードが入ったわけだが

nanojitと呼ばれているJavaScriptのJITエンジンのコードが、Firefox 3.1a2に入ったわけだが、ベンチの結果を見るとブレがある。

ちなみに、x86用のみで、x86_64は、以下のように変更すれば、有効にできる。

diff --git a/js/src/Makefile.in b/js/src/Makefile.in
--- a/js/src/Makefile.in
+++ b/js/src/Makefile.in
@@ -82,19 +82,22 @@ PACKAGE_FILE = js.pkg
 # other modules which are always built shared. Failure to do so results in
 # the js code getting copied into xpinstall and jsd as well as mozilla-bin,
 # and then the static data cells used for locking no longer work.
 
 ifndef JS_STATIC_BUILD
 FORCE_SHARED_LIB = 1
 endif
 
+ifeq ($(OS_TEST),x86_64)
+DEFINES += -DAVMPLUS_AMD64
+NANOJIT_ARCH = i386
+ENABLE_JIT = 1
+else
 ifeq (86,$(findstring 86,$(OS_TEST)))
-ifeq (64,$(findstring 64,$(OS_TEST)))
-else
 DEFINES += -DAVMPLUS_IA32
 NANOJIT_ARCH = i386
 ENABLE_JIT = 1
 endif
 endif
 
 ifeq ($(OS_ARCH),Linux)
 DEFINES += -DAVMPLUS_LINUX -DLINUX

なお、nanojitの日本語でかかれた話は、http://dodgson.org/omo/t/?date=20080506に書いてあるのがおすすめ。

WebKit(SquirrelFish)もMozillaもJITをランディングしてきたけど、Microsotはどうするのだろうねぇ。IE6の後にインドに左遷されたスクリプトエンジンだし(だから独占はイノベーションを生まないんだ)。インド人仕事じゃ高速な実装できるはずないから、Microsoft Rearchくらいから出してくるんだろうけどさ

jemallocのパフォーマンス

Firefox 3でJavaScriptの速度向上に寄与しているのは、jemallocが要因の一つなんだけど、x64でjemallocのビルドテストができるようになったので、それでベンチマークをとってみた。

3.0と3.1のツリーの違いがあるけど(3.1もチューニングの段階まできてないし)、予想通り、jemallocを有効にしただけでx86よりもJavaScriptのベンチマークの結果が良くなった。

iPhoneのアクセスポイントもバレたようで

予想通り、iPhoneのAPN名やパスワード等の情報を破られているようだ。NTT Docomoからリリースされればおもしろいことになっていたと思うけど、そういうことを嫌うDocomoなので、iPhoneがDoCoMoからリリースされる可能性はやっぱり低いね。

Firefox MOD?

2chのスレッドを見てたら、Firefox MODビルドというものがあるのかということを初めて知った。 そこで、人気になってるのは、mmoy / ayakawa / tete の三つらしい。

mmoyはたまにメールが来るので、Windows x64用のパッチとかを渡してる。(実際、mozilla-centralのツリーのものは、自分のハードディスクの中しかないんで、ブランチを公開しておこうかなぁと。)

ちなみにx64版がOfficialのx86版より若干遅いのはおそらく、jemallocが有効じゃないから。それを有効にすればJavaScript系のベンチが跳ね上がる。jemallocを有効にするためには、MSVCRTのソースをいじらないといけないんだけど、amd64版のCRTのソースは、Professional Edition以上にしか入ってないってことは最近初めて知った。エディションの比較にそういうことをちゃんとしてほしいんだが、DPEの奴らじゃそんな仕事はしないだろうなぁ。

あと、CairoのMMXが使えないのとJPEGデコーダー(IJG LIBJPEG)のISLOWがSSE2じゃないというところが若干遅くなるポイント。(アルファブレンディングなんて、地道にCPUで計算するんじゃなくて、すべてをGPUに任せた方が速いんじゃないかとずっと思ってはいるんだけど)。

JPEGのは、自分のツリー上ではSSE2版のコードを書いてあるので、それはDoneしてるのだけど(15%はデコーダーのスピードはアップする)、3.1のツリーでMichaelがJPEGデコーダーの部分に手を入れようとしてるので、それがcheck inされてから、ちょっといじらないといけない。(IFASTへの変更+α)

AP-945のベンチを見る限り、 SSE2のパワーが生かされるのは、Pentium 4またはCore 2 Duoだけのようだけど(SSE2の整数演算はMMXを二回実行してるだけだし)、Phenonmもここの記事を見る限り、AMDの以前のCPUとは違ってSSE2速そうだから、Phenonmをそろそろ買ってみようかなぁと。デスクトップなんて、Socket939のAthlon64 X2 3800+のままだし。

さてどうしようか

Optimization

OS X ハッキング! 286 "脱獄"後のお約束、各種ベンチマークを測定

今回使用したベンチマークテストは、描画や各種I/Oの測定は含まないものばかりだったが、1つハッキリしたことがある。それは、現状のままでは FlashやJavaを快適に利用するには厳しいということ。Appleの思惑のほか、ライセンスなどパフォーマンスとは直接関係しない問題が含まれるため、事態はそれほど単純ではない。しかし、移植が順調に進んだとしても (モバイルSafariとともに) 余裕でサクサク動くようになるとは考えにくい。

ARMの方を持つ気はないけど、Nokia N82 (ARM 11 Dual CPU / 332 MHz)でFlashやJavaなんてサクサク動く。Nokiaのケータイであれば、DSPを内蔵しているというのもあるけど、画面サイズの動画レベルであればストレスはない。この位のCPUパワーがあって、この画面サイズで、でもパフォーマンスが、、、って言っているのは(Appleが)最適化をまともにできないからでしょ。日本のケータイ(ARMがほとんど)だって、iPhoneくらいのパワーのCPU積んでないし。

日本のケータイはiPhoneを学ぶ必要はない

自腹でヨーロッパからNokiaのケータイを買っているような自分だけど、以下の発言は正直微妙。

404 Blog Not Found:iPhoneがガラパゴスケータイより劣っていていい理由
http://blog.livedoor.jp/dankogai/archives/51089462.html

iPhoneのようなやり方が通じるのは、一部のユーザーのための高機能ケータイのみ。それはほかのメーカーも含めてそうだ。

自分の使っているNokia N82なんて、PC接続でファームのアップグレードが簡単で、買ったときに比べれば、(iPhoneでだって動かない) Flash Liteが3にアップグレードされる(YouTubeも楽々)は、マップアプリであるNokia Mapもバージョン上がったりなどしてる。

アーリーアダプタ層以外には、そういうやり方をすれば、買ったときにまともに動かないという悪いイメージを持って、次の買い換えの時に悪い印象を持つだけ。一方、Nokiaの一般向け廉価モデルはアップグレードなんてなくて、(Bug Fixはあるけど) そのままの数年売られている。そういう売り方がNokiaのビジネスを支えているんだが。

だから個人的には、Appleのやり方はAppleの信者・イメージがあっての売り方であって、日本のメーカーがやるべきやり方ではない。学ぶものは、Nokiaや韓国メーカーのやり方。その方が自分たちにあっている

そもそも日本のケータイの伸び悩みは、そもそもドコモなどの日本のキャリアの戦略が時代に合わなくなっているだけで、そのキャリアにおんぶに抱っこだったケータイメーカーがコストの増大に耐えられなくなっていることが現在のいろいろなメーカーの撤退につながっている。キャリアに依存せずに自分たちで売るノウハウがないことが海外で失敗している理由。

たとえば、ドコモやauのCM見てると新しいケータイが出たということはわかるんだけど、どういうケータイが出て、どのケータイだとこういうことができる・できないという商品説明の基本がないので、何売りたいかわからない。なぜ自分たちでブランド作りができないのか歯がゆく思う

彼らがこのチキンレースから抜け出したいのであれば、自分たちのブランドを確立して、キャリアに依存しない売り方をやらないと、その泥沼からは一生はい上がれないかと。そんなとこ