Hi Isaac,

Thanks for your insight comments. Why would you think that I want to make Java look slow?

This is a fair competition with fair rules -- every language uses the very same algorithm. I know that the algorithm can be adjusted/optimized specifically for each language, but that's not the point. The idea is, if we used another algorithm which *did* require that we use dynamic arrays everywhere, to compare how each language does the job in regards to performance. Hence I didn't try to think if I can optimize the algorithm in any language (not that I can for all of them). I tried to explain that by "The correctness of the implementation is not so important, as we just want to check how fast the languages perform". Which in plain English means -- we try to use the very same usage pattern, as if the task really required it. So let's pretend that we really needed the boxing/unboxing, just as we did for the other languages -- all languages do the same algorithm complexity using the same (dynamic) structures.

Note that your optimizations also apply to C++.

I did wanted to compensate for the interpretation/compilation of the program -- that's why each test was performed 10 times, the very same way, during a single program execution. My expectations was that the interpretation/compilation time of the program will be a negligible part of the 10x execution. And I've stated this - "The times include the interpretation/parsing phase for each language, but it’s so small that its significance is negligible". I just ran a test with 10x execution (original) and it finished in 9,017 total *CPU* seconds. A 100x execution finished in average 7,979 (12% faster) seconds (divided by 10) -- we have about 10% difference, indeed, but not what you demonstrated.

Isn't System.nanoTime() returning the wall-clock time?

Last questions -- Can I force Java to run only compiled code? Can I save the compiled code and execute it pretty much as I execute a compiled C++ binary?

Cheers.
--Ivan

On 19.6.2012 г. 21:39 ч., Isaac Gouy wrote:

Hi

The code I posted to your blog was garbled by the text box, so I've attached it to this email.

1) The ordinary Java translation of your Python program is SimplePrimes.java


In your Python implementation of the Sieve of Eratosthenes, there is never any change to the size of the array s -- the algorithm only requires a fixed size array, but Python doesn't provide a fixed size array. Java does provide a fixed size array and that is what every Java programmer would use to implement the Sieve of Eratosthenes.

In your Python implementation, there is a change to the size of the array res -- and the SimplePrimes.java program also uses a variable size array for res.



On my quad core machine your PrimeNumbersBenchmarkApp Java program showed --

real    0m8.983s
user    0m18.425s
sys    0m0.476s

On my quad core machine SimplePrimes.java showed --

real    0m3.156s
user    0m4.388s
sys    0m0.204s




2) The SimplePrimesWarmed.java program shows how performance increases after the JVM optimizes the program, and switches of interpreted to compiled code --


3.100350
2.293438
2.136179
2.188416
2.190429
2.196120
2.189274
2.112263
2.109705
2.110209

The same effect can be seen for your PrimeNumbersBenchmarkApp java program --

13.772833
5.338382
5.486536
5.566288
5.569079
5.554750
5.567980
5.554167
5.594199
5.649297



3) If you want to make Java look slow, then force your program to run using just interpreted code :-)

$ time java -server -Xint PrimeNumbersBenchmarkApp
Found 664579 prime numbers.
Found 664579 prime numbers.
Found 664579 prime numbers.
Found 664579 prime numbers.
Found 664579 prime numbers.
Found 664579 prime numbers.
Found 664579 prime numbers.
Found 664579 prime numbers.
Found 664579 prime numbers.
Found 664579 prime numbers.

real    1m50.003s
user    2m10.532s
sys    0m0.560s




4) Your blog post says -- "The benchmarks here do not try to be complete, as they are showing the performance of the languages in one aspect, and mainly: loops, arrays with numbers, basic math operations." -- but what is really being shown for your Java program is unnecessary Integer boxing/unboxing.


best wishes, Isaac