忍者ブログ
  • 2017.09
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 2017.11
Cより速いjava (3)
本稿はjavaとcのパフォーマンス分析から始まったシリーズ「スタバに行ってコーヒーを飲もう」の

最終稿です。きっと(笑)

第1稿目では仮想メソッドがインラインになることによるパフォーマンスアップ。

第2稿目ではコンパイル単位が関数だという分析を行っていました。

だっておかしいやん。

インラインしちゃったら再利用できないよ。

そんな声が聞こえてきそうな第3稿目。

インラインされた関数はどうなる。どうする。これからの政治。(おぃ


class B extends bench { int get() { return 1;} }
class C extends bench { int get() { return 2;} }
class D extends bench { int get() { return 3;} }
 
abstract public class bench {
  abstract int get();
  public static void main(String args[]) {
    bench f[] = {new B(), new C(), new D()};
    int sum=0;
    for(int i=0;i<args.length;i++)
    {
      sum += bench.test(f[Integer.parseInt(args[i])]);
    }
    System.out.println(sum);
  }
 
  static int test(bench f) 
  {
    int sum=0;
    forint i=0; i<1000000000; i++ )
    {
      sum+=f.get();
    }
    return sum;
  }
 
}


ケース1:java bench 0 0 → 0.1 s
ケース2:java bench 0 1 → 1.5 s

はい、見事にインラインされた関数はリコンパイル対象になりますね。。
引数のクラスの型に基づいて別関数としてコンパイルされるのかな?
これで第1稿と第2稿で矛盾は発生しなくなりますね♪

そしてさらにパラメータを変えると

ケース3:java bench 0 1 0 → 1.5 s
ケース4:java bench 0 1 1 → 1.5 s

3回目の呼び出し時には前回呼び出した関数が再利用されていることが
分かります。。

これって・・javaの起動が重たい所以な気が。。

なにはともあれ、Cより速いこともありえることは確か。
その全貌を掴むのは意外に難しいみたいですね。

今回見つけたjavaがCより速くなるケース。

「暗黙のジェネリック」

と名づけましょう(笑)
PR
【2011/12/11 09:01 】 | java | 有り難いご意見(2) | トラックバック(0)
                                    
<<SpinLock vs pthread_mutex | ホーム | Cより速いjava (2)改訂版>>
有り難いご意見
無題
動的最適化所以のものなので
本当にLRUかって調べてみるとか

とっ言ってみるヾ( ̄。 ̄ ボソッ

 要する何回で忘れるかなんて♪

さらなるデータ依存による最適化が必要なのでしょうか?
【2011/12/11 15:43】| URL | ゼンガイチ #2ac02652f5 [ 編集 ]


無題
vm設定で変わりそうな。。

時間計測を行って選ぶなんてしてたら処理遅そうな気が。

かと言って、選び直しても負けつづけそう(笑)
【2011/12/11 17:01】| | nwpfh #29ef1c77e8 [ 編集 ]


貴重なご意見の投稿














虎カムバック
トラックバックURL

<<前ページ | ホーム | 次ページ>>