javaプログラムの最適化スレッド

■掲示板に戻る■ ■過去ログ倉庫めにゅーに戻る■

1 名前： デフォルトの名無しさん 投稿日： 2001/07/02(月) 19:24: sunの糞コンパイラに任せていないで
自分たちで最適化しようぜ的スレッドです。

テクニックを疲労してくれ

参考資料
http://www.google.com/search?hl=ja&safe=off&q=java+%8D%C5%93K%89%BB%81@%83o%83C%83g%83R%81%5B%83h&lr=
2 名前： デフォルトの名無しさん 投稿日： 2001/07/02(月) 19:27: -O
3 名前： デフォルトの名無しさん 投稿日： 2001/07/02(月) 19:27: 疲れきってます。
4 名前： デフォルトの名無しさん 投稿日： 2001/07/02(月) 19:28: エクセルソフトのJETってどうよ？
5 名前： デフォルトの名無しさん 投稿日： 2001/07/02(月) 19:28: native
6 名前： デフォルトの名無しさん 投稿日： 2001/07/02(月) 19:29: -O オプションは付けても付けなくても
ほとんど速度は変わらないって聞いたけど・・・
7 名前： デフォルトの名無しさん 投稿日： 2001/07/02(月) 19:40: javacよりもjavaコマンドのオプションのほうが重要ﾏｼﾞﾚｽ
8 名前： デフォルトの名無しさん 投稿日： 2001/07/02(月) 19:58: JITならわかるけどjavaインタープリタで
違いは出るのか？
9 名前： デフォルトの名無しさん 投稿日： 2001/07/02(月) 20:04: ひとまずRetroGuardはﾃﾞﾌｫでしょうね
10 名前： デフォルトの名無しさん 投稿日： 2001/07/02(月) 20:58: >>2
javacの-Oオプションは単なるダミーだ。騙されちゃダメだぞ。
11 名前： デフォルトの名無しさん 投稿日： 2001/07/02(月) 20:59: for (int i = 0; i < 1000; i++) よりも
for (int i = 999; i >= 0; i--) のほうが速いとか
そういう話でいいですか。
12 名前： デフォルトの名無しさん 投稿日： 2001/07/02(月) 21:22: for (int i = 999; i != 0; i--)
のほうがよくない？
13 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 00:08: 要は０と比較するかどうかだから、同じと思われ。こんなんでました。

public void hoge()
{
for(int i = 0; i < 1000; i++);
// 0 0:iconst_0
// 1 1:istore_1
// 2 2:goto 8
// 3 5:iinc 1 1
// 4 8:iload_1
// 5 9:sipush 1000
// 6 12:icmplt 5
for(int j = 999; j >= 0; j--);
// 7 15:sipush 999
// 8 18:istore_2
// 9 19:goto 25
// 10 22:iinc 2 -1
// 11 25:iload_2
// 12 26:ifge 22
for(int k = 999; k != 0; k--);
// 13 29:sipush 999
// 14 32:istore_3
// 15 33:goto 39
// 16 36:iinc 3 -1
// 17 39:iload_3
// 18 40:ifne 36
// 19 43:return
}

ていうか、空ループの削除すらしないとは恐るべしjavac！！
14 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 00:12: ●　旦＜age！！
＜■Ｖ
／　＞
15 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 00:17: 良ＨＰ晒しあげ

ttp://www.asahi-net.or.jp/~dp8t-asm/java/tips/SpeedOptimizationByCodingIndex.html
16 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 00:19: >>13
どうせJITかHOTSPOTがやるんじゃないの？＜最適化
17 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 00:20: javaはマルチプラットフォームだから
下手に最適化しないでコンパイルするようになっている
って話だけど、本音としてはただ手抜きしているだけじゃない？

空のループ消したり、重複分の計算を共通式で置き換えたり
するくらいだったら、どのプラットフォームにも
マイナスにならないと思うのだが・・・。
18 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 00:21: 最適化機能がよわいから簡単に逆コンパイルされちゃうんだよね
19 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 00:24: 空ループまで再現されるもんな。（藁
20 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 00:25: javacアホ決定
Borlandあたりがもう少しマシなjavaコンパイラ作ってくれないかな？
21 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 00:27: なんでバイトコードコンパイルで最適化せにゃならんのよ。
JITでやってるなら、それでいいじゃん。
やってるかどうか知らんけど。
22 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 00:33: なんでJITに任せる必要があるんだよ！！
実行時に毎回最適化するなんて無駄だろ？
それにすでにバイトコードに変換されたものより
ソースファイルの段階でコンパイルしたほうが
最適化しやすいんじゃない？
23 名前： 22 投稿日： 2001/07/03(火) 00:34: > ソースファイルの段階でコンパイルしたほうが
> 最適化しやすいんじゃない？

ソースファイルの段階で最適化したほうが
最適化しやすいんじゃないか？

の間違いです
24 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 00:35: >>13
VJ++で最適化コンパイルした結果
public void hoge(){
//maxstack 2
//maxlocal 2
iconst_0
istore_1
Label1:
iinc 1 1
iload_1
sipush 1000
if_icmplt Label1
sipush 999
istore_1
Label2:
iinc 1 -1
iload_1
ifge Label2
sipush 999
istore_1
Label3:
iinc 1 -1
iload_1
ifne Label3
return
}

>>21
JITで実行される可能性の方が少ないと思われる。
25 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 00:39: >>24

なんだ。結局javacのコードとたいして
変わらないんじゃん。
このスレ、

「なんでjavaは最適化に消極的なのか？」

に変えようぜ
26 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 01:08: みみっちい最適化してるうちに、
CPUの速度向上がその最適化の結果を軽く吹き飛ばしてしまうから。
27 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 01:09: >>25
最適化せずに、より多くの情報を残しておく方が、
JITが最適化しやすいらしい。
#まあ所詮そんのは幻想なんだけど
#まともにインライン展開すらしやしないし

いつかできると言われている、
理想JITコンパイラに期待しましょ。
その時のために最適化はしないでおきましょ。
28 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 01:13: >>26
そんな甘ったるい思考してるから
いつまでたってもJavaは使えないんだよ。

VC++の鬼のような最適化の、爪の垢でも煎じて飲め。
29 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 01:27: >>28
使えるかどうかと、実行速度の関係は、もはや強い相関があるとは言えない気がする。
30 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 01:28: >>26
そのセリフ一昨年聞いた。変わってねーな。
31 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 01:31: gcjってどうなの？
誰か試した人いる？
32 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 02:26: JITで最適化とかゆーとるわりに、
バイトコード短くしたほうが明らかに速度上がるんだよな。
感覚的には、バイトコードのサイズに正比例って感じ。
33 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 02:31: 適当に下のコードJava 1.3.1で実行したら、延々と終了せず。
ひょっとしなくても律儀に空ループ回ってると思われ。
Sunご自慢の偉大なるHotSpot様は一体何をやっているのか？

public class Hoge {
　　public static void main(String[] args) {
　　　　for (long i = 0; i < 1000000000000000L; i++);
　　}
}
34 名前： どうなの？ 投稿日： 2001/07/03(火) 03:05: http://gcc.gnu.org/java/
35 名前： shige 投稿日： 2001/07/03(火) 04:29: こうやってPerlユーザが馬鹿にされて、コケにされて、侮辱されて、（当然のことだ）
顔を真っ赤にして耐えている姿を想像するだけで俺の気分は爽快になる。

Ruby万歳。俺にこんな快楽を与えてくれたRubyに幸いあれ。
36 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 08:13: >>35
このスレでいいのか……？
37 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 08:49: >>36
「javaプログラムの最適化スレッド」
いいと思いますＹＯ！
38 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 21:30: でもたぶん、このスレだと陵辱されるのはキミだＹＯ！
39 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 21:31: こんなスレ削除依頼出そうぜ！
40 名前： デフォルトの名無しさん 投稿日： 2001/07/03(火) 21:35: 35==39
無視して続行しましょう。
顔を真っ赤にして侮辱に耐えてくれ。萌え～
41 名前： shige 投稿日： 2001/07/03(火) 22:20: みんなでPerlユーザを苛めよう！
みんなでPerlユーザをこの板から追い出そう！
42 名前： shige 投稿日： 2001/07/03(火) 22:26: みんなで叫ぼう！
「Perl使いは死ね！」「Perl使いは死ね！」「Perl使いは死ね！」「Perl使いは死ね！」
「Perl使いは死ね！」「Perl使いは死ね！」「Perl使いは死ね！」「Perl使いは死ね！」
43 名前： オプションの名無し 投稿日： 2001/07/04(水) 04:11: >> 33
i < 1000000000Lで計測しました。（-Oなし)
type | 1st | 2nd
gcc2.5.2 | 10.46s | 10.42s
java1.3 | 21.98s | 18.64s
ｲﾝﾀﾌﾟﾘﾀの単純ﾙﾌﾟｰで、これほどまでに速いのでは?
というか...当たり前でしょ？、ﾃｽﾂと呼ぶに値しない。ふっ..
> 13 >ていうか、空ループの削除
はぁ？最適化というよりもﾌﾟﾛｸﾞﾗﾑの意図を捻じ曲げる、創世記以前の産物.
RealTimeでﾋﾞｼﾞｰｳｴｲﾂやﾀｰｲﾐﾝｸﾞｺﾝｰﾃｷｽﾀに使われるかもしれない代物ですぜ。
44 名前： デフォルトの名無しさん 投稿日： 2001/07/04(水) 04:37: >>43
この人おもしろすぎ
氷魚ウォッチスレにリンク張ってもいいですか？
45 名前： デフォルトの名無しさん 投稿日： 2001/07/04(水) 12:16: いや、あまりおもしろくはないと思うぞ。
46 名前： デフォルトの名無しさん 投稿日： 2001/07/09(月) 00:17: じゃあそろそろ誰か結論をまとめてくれ。
47 名前： デフォルトの名無しさん 投稿日： 2001/07/09(月) 00:44: >>32
詳細キボーン
48 名前： デフォルトの名無しさん 投稿日： 2001/07/09(月) 00:48: >>47
アルゴリズムを工夫しろ、ということです。
49 名前： デフォルトの名無しさん 投稿日： 2001/07/09(月) 00:57: >>48
工夫してもどうにもならないのが、糞Javaということです。
50 名前： sunより 投稿日： 2001/07/09(月) 01:00: 空ループの削除はしません。

なぜなら、空ループでタイミングをとることも想定しているからです。
手間をかければ空ループの時間も厳密に計測できます。
これらが有効に生かされるのは、組み込み分野です。
51 名前： デフォルトの名無しさん 投稿日： 2001/07/09(月) 01:05: >>50
まぁ、そういう事だろうね。
スレッドでスリープかけるより資源が少しで済む。
52 名前： デフォルトの名無しさん 投稿日： 2001/07/09(月) 01:08: java固有の最適化って結局、小手先の事か？>1
53 名前： デフォルトの名無しさん 投稿日： 2001/07/09(月) 02:03: >>52
そりゃー、「Java固有」って言ってる時点で小手先だろ。
アルゴリズムの見直しによる最適化はJava固有の話じゃないからな
54 名前： デフォルトの名無しさん 投稿日： 2001/07/09(月) 03:06: >>50
Sunがそう言ってるんですか？
ソースをクレー、粘土をclay～

っていうかそれ、javacやJ2SEで空ループなくさない理由に
ならんと思いますけど。空ループウェイトなんて
Write Once, Run Anywhereの建前にも反するし。
55 名前： デフォルトの名無しさん 投稿日： 2001/07/09(月) 04:43: >>54
空ループの消去って最適化としてはあまり意味がないと思う。
逆にわざわざ空ループ作るからには、
何かしら意図があってやってるんだろうしね。

そんなのはどうでも良いから、
インライン展開、
サブルーチン展開、
コンスタントプールの最適化、
ローカル変数の最小割り当て、
即値の最適化、
privateメソッドのリネーム
とかもっと積極的にやってくれよ。ｺﾞﾗｧ
56 名前： デフォルトの名無しさん 投稿日： 2001/07/09(月) 09:09: >>55
classからの逆変換って結構多用されるから
最適化をしないのはそのあたりも一枚噛んでるかと。
57 名前： デフォルトの名無しさん 投稿日： 2001/07/09(月) 13:17: リバースエンジニアリングする人のために最適化しないわけですか？
58 名前： デフォルトの名無しさん 投稿日： 2001/07/10(火) 03:54: >>57
リバースエンジニアリングのために最適化しない
という認識でおおかた問題ありません。
59 名前： デフォルトの名無しさん 投稿日： 2001/07/10(火) 13:52: Cでなくアセンブラだけで組むような感じで、
javacを全く使わないか、あるいは一旦javacにはかせてから、
生のバイトコードを手で最適化してる人っているのかな？
( RetroGuardとかのツールの開発者じゃなくて、アプリケーションの開発者で)
60 名前： デフォルトの名無しさん 投稿日： 2001/07/10(火) 13:58: >>55
サブルーチン展開ってなに？
61 名前： デフォルトの名無しさん 投稿日： 2001/07/10(火) 14:03: >>60
小さいサブルーチンをそこに展開しちゃえば
関数呼び出し時のオーバーヘッドがなくなるから
ちょっぴり速くなる。

いうほど高速化は望めない上、これをやられると
あとでデバッグが面倒でたまらないのでやめてほしい。
62 名前： デフォルトの名無しさん 投稿日： 2001/07/10(火) 14:13: インライン展開でデバッグが面倒になったりはしないと思うが……。
63 名前： 62 投稿日： 2001/07/10(火) 14:15: じゃないな（あー、眠い）。なんつーかほれ、
開発中はインライン展開しなけりゃいいだけの話。
64 名前： 62 投稿日： 2001/07/10(火) 14:16: >>59
Javaでデモ作ってた人たちはやってたと思う。
バイトコードアセンブラ？はJasminとかあるでよ。
65 名前： 60 投稿日： 2001/07/10(火) 15:37: インライン展開とは違うのですか？
66 名前： 60 投稿日： 2001/07/10(火) 15:37: >>61
67 名前： 61 投稿日： 2001/07/10(火) 16:04: >>65
ただの言葉遊び。

Cとかだとインライン展開しろっていう指示子があったね。
68 名前： デフォルトの名無しさん 投稿日： 2001/07/10(火) 19:21: 指示しなくても、出来そうなら勝手にやってたね。

実情を知らないのが割り込んですまないが
javaの最適化って、いまのとこ、そんなにしょぼいもんなの？

同じコードがC++とjavaで速度が違うとかだと、
言語の特性もあるからあまり比較に成らんと思うけどね。

どっちかというと、作るコストの方を最適化したい感じだ。
69 名前： デフォルトの名無しさん 投稿日： 2001/07/10(火) 23:16: >>60
サブルーチン展開というのは、
javaのバイトコードのjsr命令を使ってメソッド内にルーチンを展開すること。
インライン展開より速度は劣るが、
メソッドコールよりも高速で、
メソッドを定義したりインライン展開するよりもコードサイズを縮小できる。

例えば、以下のメソッドをサブルーチン展開した場合、
void foo()
{
　:
　:
　boo();
　:
　:
　boo();
}

void foo()
{
　:
　:
　jsr boo
　:
　:
　jsr boo

boo:
:
:
　ret
}
70 名前： デフォルトの名無しさん 投稿日： 2001/07/10(火) 23:23: 60じゃないけどthx

つまり小手先テクニックね。
脱力した。
71 名前： デフォルトの名無しさん 投稿日： 2001/07/10(火) 23:27: >>70
小手先じゃないだろ？
メソッド定義やコールに、かなりの無駄が伴うJavaにとっては、
かなり重要なテクだぞ。
72 名前： デフォルトの名無しさん 投稿日： 2001/07/10(火) 23:44: つまり、javaの処理系がショボイのね。

gcc3.0に自前の最適化コード入れれば
javaのコードはそのままでいい感じに速くなるかもよ？
73 名前： デフォルトの名無しさん 投稿日： 2001/07/11(水) 00:23: javaソースからCソースに変換できるパーサを作ってほしい。
そうしたらgccなりVisualC++なりを使える。
74 名前： デフォルトの名無しさん 投稿日： 2001/07/11(水) 00:25: >>73
でもその時点でjavaの理想がいくつか失われるよね

ただのオブジェクト指向型言語になっちゃうよ。
75 名前： デフォルトの名無しさん 投稿日： 2001/07/11(水) 00:37: >>73
javaが誕生した当初、javacはcへのコンバータでした
76 名前： デフォルトの名無しさん 投稿日： 2001/07/11(水) 00:43: >>75
ほう。
ちょいと、javaしらべてみるかなー。
77 名前： デフォルトの名無しさん 投稿日： 2001/07/11(水) 00:51: GCJってどうなったの？
78 名前： デフォルトの名無しさん 投稿日： 2001/07/12(木) 00:42: あげ！