[GR-60803][Native Image] For loop performance in native image is not good

[akashKarmakar02]

Describe the Issue

I was testing performance in native-image. so i decided to test for loop
graalvm 23.0.1 os: linux arch: x86_64
Code:

class Main {
  public static void main(String[] args) {
    for (int i = 0; i < Integer.parseInt(args[0]); i++);
  }
}

native image compilation command: native-image -O3 -march=native Main

time output:

Using the latest version of GraalVM can resolve many issues.

• I tried with the latest version of GraalVM.

GraalVM Version

java 23.0.1 2024-10-15
Java(TM) SE Runtime Environment Oracle GraalVM 23.0.1+11.1 (build 23.0.1+11-jvmci-b01)
Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 23.0.1+11.1 (build 23.0.1+11-jvmci-b01, mixed mode, sharing)

Operating System and Version

Linux fedora 6.12.6-200.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Dec 19 21:06:34 UTC 2024 x86_64 GNU/Linux

Troubleshooting Confirmation

• I tried the suggestions in the troubleshooting guide.

Run Command

./main 99999999
java Main 99999999

Expected Behavior

native-image should have run faster

Actual Behavior

native image is 5 times slower

Steps to Reproduce

1. create java file with

class Main {
  public static void main(String[] args) {
    for (int i = 0; i < Integer.parseInt(args[0]); i++);
  }
}

2. compile it with java and native image native-image -O3 -march=native Main
3. and run them

Additional Context

No response

Run-Time Log Output and Error Messages

No response

[oubidar-Abderrahim]

Thank you for reporting this, we'll take a look into it shortly

[wirthi]

Hi @akashKarmakar02

thanks for your report.

Let me mention that this is a particularly unrealistic benchmark . You have a tight loop in Java's main method, and do all the work there. This might e.g. allow for on-stack replacement in the JIT case, but we don't do that in native-image (real-world applications are typically bigger than just one method). In essence, the JIT compiler can basically see that you don't to anything reasonable work (there is no output, no result, no exceptions - when the input is an Integer, that is!), and optimize away almost everything you do, as it realizes that you do the same thing in each loop iteration. In a static compiler like native-image, that is harder to achieve, as we don't know what the input (arg[0]) is, we would need to compile different alternatives.

I tried to replicate your findings on my machine; I do get different values but the ballpark is the same. I am using our latest version (master branch) on Ubuntu Linux, amd-64. graalvm-jdk-25+4.1

$ time /graalvm/graalvm-jdk-25+4.1/bin/java Main 99999999

real	0m0,698s
user	0m0,786s
sys	0m0,059s

and

$ time ./main-default 99999999

real	0m6,230s
user	0m6,228s
sys	0m0,002s

This means more than a 10x slowdown. But let's try to improve on that:

First you can build the image with -O3 (native-image -O3 Main). This brings down execution time by a factor of 2:

$ time ./main-o3 99999999

real	0m3,734s
user	0m3,729s
sys	0m0,006s

Then, you should also use PGO (profile guided optimization) to further improve performance (see https://www.graalvm.org/latest/reference-manual/native-image/guides/optimize-native-executable-with-pgo/ - note that PGO implies -O3):

$ time ./main-pgo 99999999

real	0m2,168s
user	0m2,164s
sys	0m0,005s

Still not as fast, but significantly better than the initial version. The takeaway is: have a realistic benchmark that actually uses the calculations you do; and for native-image, use PGO for best performance.

[akashKarmakar02]

Hi @wirthi

Thanks for the help i was also able to get similar result using PGO. and the exam they have there ran faster then jvm. so i was a great think to learn.