[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[jfriends-ml 10797] Re: More Java Pitfalls を 読む会第 4 回議事録
村山＠NETGENEです．
＃少し話題になった名前＠所属って書き方は，レオナルド=ダ=ヴィンチも
＃似たようなものですね．
＃＃「レオナルド＠ヴィンチ村」って意味だそうだから．
> > ・i++ > i=i+1 は本当か？
> Sun J2SE SDK1.4.2のjavacでコンパイルしたJavaバイトコードでは、
> i++の場合
> iinc 1, 1
>
> i+=1の場合
> iinc 1, 1
仕様書を見れば分かりますが，こちらは3byte命令．
> i = i + 1の場合
> iload_1
> iconst_1
> iadd
> istore_1
>
> となり、確かにi++の方がバイトコード上は効率が良い結果となります。
こちらは1byte命令 * 4 = 4byte．
なかなか興味深い結果ですね．
ちろんこうなるのはバイトコード=コンパイラの癖の問題で，別のコンパイラを
使えば異なる結果になる可能性もあります．
＃ちなみに，まずないとは思うけど，もしこれが
＃「iload 1，bipush 1，iadd，istore 1」
＃だったら，同じ処理であるにも関わらず2+2+1+2=7byteになる．
＃bipushの代わりにsipushを使うと，さらに1バイト無駄になる．
この場合でもJITで変換すると大抵はRISCの一命令に変換されるでしょうから，
最適化された場合の処理速度は同じになるでしょう．組込みの場合はメモリ
の関係であまり複雑な最適化はできず，結果はVMの実装によって変わると
思います．
＃若干の速度差よりも「1バイト大きくなる」ということの方が重要かも．(^^;
完全に単純に実装されたインタプリタの場合ならば，多分前者の方が
早くはなるんでしょう．ただiload_<n>にせよiinc にせよ頻繁に使われる
命令なので，インタプリタといえども最適化されている可能性が高い．
となると，実際にどちらがどの程度早いのかは，ちょっと分かりません．
＃たしかアプリックスのFTT3なんてのが，インタプリタの最適化技術
＃だったと思う．詳細は不明．Jeode，IntentJTEの他，SUNの組込み用
＃HotSpotなどは，インタプリタ実装ではない．
ちなみに，picoJavaIIアーキテクチャのフォールディング機構の場合でも，
おそらく速度は(ほぼ)同じになります．前者はフォールディングできない命令
なので，一命令で一クロック．後者は4命令フォールディングして，4命令で
一クロック．内部アーキテクチャがRISCベースである限り，おそらくこれは
避けられない性質と言えるでしょう．
あと，重要な問題として「Javaで書かれたプログラム」の実行時間は，
必ずしも「バイトコードのみで決まるわけではない」ということがあります．
GCやメソッド呼び出し等を除いたとしても，プログラムによっては
ボトルネックはグラフィックや通信等になるかもしれません．その
場合はバイトコードの性能を数％上げることは，ほとんど無意味です．
1byte削ることに意味があるというのも，どうかとは思うけど．．．．
＃MaxOS X for Java Geeksの訳本もついに登場のようですね．
--
村山敏清 株式会社ネットジーン 〒164-0001
東京都中野区中野3-33-3 インツ中野ビル 5F
E-mail:murayama@xxxxxxxxxxxxx
TEL:(03)5328-3670 FAX:(03)5328-3673
http://www.netgene.co.jp/