Java MIDPのVMの現況
あと、前の記事に、はてなスターをくださった方々ありがとうございます。m(_ _)m
それと、id:kensuu (nanapi)の http://rocketstart.co.jp/media/press/20101129.html すごいですね!
Java MIDP 実装 on HTML5 and Flash@Firefox Developers Conference 2010
jQuery の作者の John Resig さんなど外国の方がいらした関係で、スライドがすべて英語です。
最近、携帯電話 の Java の MIDP の処理系を HTML5 および Flash で実装しています。それのプレゼンです。 http://orto-app.com/ でαバージョンを公開しましたので、よかったらご覧ください。IE8でみると、Flashで動きます。全体として、だいぶ、バグが多いのです。ごめんなさい。(画面転送が半分くらいのアプリでしか動いていません)。アプリももっといろいろ動くようにしたいです。
作っているのは、
- MIDP の処理系。Java class ファイル → JavaScript, ActionScript のコンパイラ
- MIDP の画面転送
この2つを作っています。画面転送は、遅延も小さくして、遠隔でもゲームができるクオリティで作ろうと目指しています。MIDPの処理系の方は高速化もがんばっていまして、パソコンでしたら十分な速度で動いていると思います。
僕の発表時間が1分短くなった関係もあり、最後の方が話せなかったので、コントロールフローグラフについてブログで補足させてください。
goto などで分岐が出てこないのを基本ブロックといいます。最後のページのスライドですが、分岐が出てこないということを利用して最適化をかけることができます。Java ニーモニックで、iload というのはローカル変数読み出してをスタックに積む命令ですが、単純に実装すると、stack は JavaScript の Array になりますが、Array.push() や Array.pop() は時間のかかる処理です。
しかし、Java のスタックの何番目に積むかという、スタックの深さは、実行パスに関係なく、静的に決まらないといけないという規約になっています。そのため、この部分は、JavaScript のローカル変数を代わりに使うことができます。それが Optimized JavaScript の部分です。
そして、基本ブロック内は分岐が出てこないことがわかっているので、2行目の localVars1 = stack1 の stack1 はその前をみると stack1 = localVars2 しているので、localVars2 が localVars1 にくるととがわかります。その処理をしたのが、More Optimized JavaScript です。
この JavaScript が僕のコンパイラで生成されているのですが、ブラウザの JIT コンパイラで x86 に変換された(厳密にはイメージです)結果が一番下の JIT x86 で、結果として、C言語で同じようなコードを書いた場合と同じような x86 になり、高速化することができます。
という話を、2分でしようと思ったのですが、時間不足で全く伝わる形で説明できなくてごめんなさい。
あと、スピーカーとか関係なく、普通にじゃんけんに勝って、マウスパッド with John Resign のサインをいただきました!ありがとうございます。m(_ _)m
Chrome 9の2Dアクセラレーションは遅くなったりする!
id:revulo さんに教えてもらったのですが(Thanks!)、id:mindcat さんの
掲載されている、Chrome 9 のベンチマークが2Dアクセラレーションを無効にしているようなので、有効にしてみました。2Dアクセラレーションは --enable-accelerated-2d-canvas を実行時の引数につけると有効になります。デフォルトは無効です。
マシン環境は以下の通り。ちょっと古くてごめんなさい。
- OS: Windows XP
- CPU: Pentiume 4 3.2GHz (1コア)
- GPU: NVIDIA GeForce 7600 GS
- Browser: Chrome 9.0.574.0 canary build
項目名 | アクセラレーションあり | アクセラレーションなし | 速くなっている |
---|---|---|---|
hline | 20.1 (0.668) | 33.7 (1.12) | |
vline | 20.0 (1.33) | 29.7 (1.98) | |
line | 14.9 (2.49) | 19.1 (3.18) | |
rect | 19.7 (3.93) | 24.6 (4.93) | |
fill_rect | 17.5 (3.51) | 19.8 (3.97) | |
lines | 29.3 (3.66) | 38.5 (4.81) | |
arc | 9.97 (2.49) | 12.1 (3.02) | |
fill_arc | 9.95 (1.42) | 11.6 (1.66) | |
bezier | 8.49 (2.83) | 9.50 (3.17) | |
fill_bezier | 6.40 (1.60) | 6.94 (1.74) | |
quad | 11.8 (2.95) | 13.9 (3.47) | |
curves | 18.4 (3.68) | 24.8 (4.95) | |
fill_curves | 12.1 (1.52) | 16.2 (2.03) | |
stroke_star | 4.29 (0.613) | 6.81 (0.973) | |
fill_star | 8.27 (0.689) | 11.4 (0.949) | |
transform | 0.209 (1.04) | 0.283 (1.42) | |
image | 5.93 (19.8) | 3.49 (11.6) | ○ |
image_scale | 5.94 (7.42) | 1.30 (1.63) | ○ |
image_rotate | 0.896 (2.99) | 0.234 (0.780) | ○ |
linear_gradient | 2.93 (1.47) | 3.89 (1.94) | |
radial_gradient | 0.164 (0.546) | 0.181 (0.603) | |
text | 1.50 (2.50) | 1.87 (3.12) | |
clip | 2.14 (2.67) | 3.03 (3.79) | |
Total Score | 1.57 | 1.81 |
CPU や GPU のバランスで結果が変わる可能性は高いと思います。特に、Windows 7 で変わる可能性もかなりあります。ちなみに、Chrome 7 と 9 の差は、ほぼありませんでした。
image 関係3つ以外は遅くなっています。ただし、image_scale と image_rotate はすごく速くなっています。
http://ie.microsoft.com/testdrive/Performance/FishIETank/Default.html というマイクロソフトのベンチマークがありますが、これは、image_scale のベンチマークです。IE9 はいち速く GPU 採用をし、GPU で速くなるのは、image_scale なので、マイクロソフトのベンチマークは image_scale ベンチマークがたくさんあります。個人的に思うのは、実際に
今のところ、GPU使っても必ずしも速くならないというのは要注意ですね。でも、マシン・OS依存ぽいなぁ…。
SubversionからGitに移行するときの注意点
自分へのメモです。SubversionからGitに移行するときの注意点。
git-svn(1) にしたがって、Subversion から Git に移行できるのですが、
git svn clone Subversionのリポジトリ
Gitは色々なツールが、リポジトリ内は CR+LF ではなく、LF であることを期待しているみたいなので、上の方法で Subversion 内が CR+LF だと、Gitのリポジトリ内も CR+LF になってしまい、トラブルが起きます。
なので、上の方法で移行した後、gitattributes(5) の When text=auto normalization is enabled in an existing repository あたりに書かれている、
$ echo "* text=auto" >>.gitattributes $ rm .git/index # Remove the index to force git to $ git reset # re-scan the working directory $ git status # Show files that will be normalized $ git add -u $ git add .gitattributes $ git commit -m "Introduce end-of-line normalization"
でリポジトリ内を全て LF で統一すると、良いみたいです。Windows では普通にインストールすると有効になっている事が多いですが、.git/config の autocrlf が true になっていると、リポジトリ内は LF でも、取り出すと CR+LF に変換されます。
あまり確証はないのですが、rm .git/index したら、.git/tortoisegit.* も消した方がいいと思います。TortoiseGit の Show log で復活します。
なんか、一部の Windows 用の Git ツールが autocrlf を無視して CR+LF でコミットしていくみたいなので、コミットなどをする時は、msysgit (Git for Windows) で必ず行うみたいなルールにしておいた方がいい感じがします。改行コードがおかしくなった時は、上の方法で直ります。
また、日本語ファイル名対応版は、UTF-8ファイル名対応版 Git for Windows にあります。
amachangによるFacebookマーケティングの成果
id:amachangをきっかけに、Facebookが盛り上がりました。盛り上げに貢献した人は、まぁ、色々たくさんいて、俺の名前を出せ!と言われると際限ないので、amachang の名前だけ出しておきます。ごめんなさい。
昨日、「同時ログオン会」というのがあり、その成果。まず、これが、この1年のTwitterでの言及数です。日本を対象にした場合、アルファベットの「Facebook」よりもカタカナの「フェイスブック」の方がより適切な結果が出ます。
緩やかに上昇傾向ではある物の、10月に突出していますね。途中、穴があるのは Google のデータ欠損のはずです。
そして、その10月の詳細データ10月12日に盛り上がっています。
10月11日を見ると、10月11日23時の1006ブックマークされたフェイスブックが面白い - IT戦記が盛り上げの直接的なきっかけになっています。ブログ界ではもう少し前から別な人が紹介し、たくさん、はてなブックマークはされているんですが、なぜか社会全体には影響は及ぼしていません。
また、ITmedia に10月13日に ねとらぼ:登録159万人 Facebook、日本で流行の兆し - ITmedia NEWS という岡田有花さんの記事が出て、147ブックマークされましたが、流行に乗っただけで、特にムーブメントは作り出していません。
そして、個人的に一番びっくりなのは、「同時ログオン会」それ自体が開催されるときは、全然、話題になっていません。面白いお祭りがあるときは、Twitterでも「同時ログオン会やってるよー」的な投稿をする方がたくさん出るので、必ず Twitter に波及するんですが、このお祭り自体は、話題になりませんでした。うーん。
さて、ブログによる話題は、普通は一過性になり、定着することはなく、定着するかどうかは、Facebook自体およびmixiなどとの差によって決まると思うんですが、どうなるんでしょう?
以上、amachang 頑張ったねー!という報告レポートでした(笑)。amachang、フェイスブックネタ、まだ、続きあるの?
OracleのAndroid訴訟は実効性あるの?
OracleがAndroidの処理系はJavaの特許を侵害しているとして、訴えています。
その7つの特許のうち、3つは日本でも出願されていて、
出願番号 | 公開番号 | 発明の名称 |
---|---|---|
特願平05-339905 | 特開平06-230976 | 参照をリゾルブする方法および装置 |
特願平10-346523 | 特開2000-029706 | クラスファイルのプリプロセシング及び パッケ―ジングのための方法及び装置 |
特願平11-098306 | 特開2000-035893 | デ―タ処理システムの配列の静的初期化方法、 デ―タ処理方法、並びにデ―タ処理システム及び その制御手順をコンピュ―タに実行させるプログラムを記憶した コンピュ―タ読み取り可能な記憶媒体 |
の3つです。そして、それら全てが日本では特許として成立していません。http://www.ipdl.inpit.go.jp/Tokujitu/tjsogodb.ipdl?N0000=101 から見られます。(文献種別をAにして、公開番号を入力してください。平06=1994)。拒絶理由は http://www.ipdl.inpit.go.jp/Tokujitu/pfwj.ipdl?N0000=118 から読めます。(種別をA:特許公開にして、公開番号を入力してください)。
例えば、特開平06-230976 は Java を作った James Gosling が1993年に出願した特許です。内容は、
- C++なら、オブジェクトのフィールドアクセスのさい、「ポインタ+8」みたいに、数字の足し算でアクセスします
- Java の場合、クラスファイル上は、「y」とかフィールド名が文字列で書いてあって、それをJITコンパイル時などに「ポインタ+8」に変換します。
このワンステップ踏む分が特許だと思います。特許の文章はややこしく、間違っていたらごめんなさい。特許の図を見るとわかりやすいです。
そして、10年後の2003年に拒絶理由がでて、弁理士と、あーだ、こーだとやりとりしています。理由の一つ(理由6)が、こんなの「進歩性がない」と言うことだと思います。
こんな、威力のない特許でオラクルはGoogleを訴えて何をしたいのでしょう?
ここから憶測。100%憶測です。
水鉄砲程度の威力しかない特許ですが、驚かせるには十分なのかもしれません(笑)
そして、Oracleとしては、Javaの資産を、Googleに買い取って欲しいのではないでしょうか?「Oracleから買い取らないと、面倒くさいことになるよ」という意思表示として、水鉄砲でGoogleを脅かしたのではないかという気がします。
よー、わからん。
AmebaなうをRSSに変換するのを改良しました
Amebaなうは2017年11月6日にサービス終了しました。 https://ameblo.jp/staff/entry-12307556515.html
AmebaなうをRSSで購読できるようにしました - yukobaのブログ で書いた、AmebaなうをRSSに変換するサービスですが、少しだけ改良しました。
- livedoor Readerなどに対応。
- メッセージの画像をRSSにも埋め込みました。
1はRSS中の<guid>が全て同じだと、livedoor Readerで正しく表示されないため、?dummy= というのをつけました。本当は、Amebaなうのメッセージには全てアドレスがついているので、それを使うのが正当なんですが、手抜きしています。