JAVA faster than C++ now?

Performance Tuning
#1

I have done a little benchmrak comparison between JAVA and C++, with same piece of code, it turns out that JAVA always beats c++ for by small mount. Does it conclude that Java is now faster than C++ ;D?


//compiled with g++ 4.6.3
#include <iostream>
#include <ctime>

int main(){
 	 clock_t begin = clock();  

	double *numbers;
	numbers = new double[32000000];
	double  sum = 0;
		for(int i = 0; i < 32000000;i++){
		  	numbers[i] = 3141592654.987654321/i;
		sum+= i/3.141592654987654321/(i+3.14159269876)/(3.14159269876 -i)/(35343.34534 -i)/(3343443242.33 -i)/numbers[i];
		
	}


	clock_t end = clock();
	double elapsed_secs = double(end - begin) / CLOCKS_PER_SEC;
	std::cout << sum << "\n" ;
	std::cout << elapsed_secs;

  	return 0;
}



//compiled with java 1.6.27
public class test{

	public static void main(String[] args){
		long time = System.currentTimeMillis();
		
		double[] numbers = new double[32000000];
		double  sum = 0;
		for(int i = 0; i < 32000000;i++){
		  numbers[i] = 3141592654.987654321/i;
		sum+= i/3.141592654987654321/(i+3.14159269876)/(3.14159269876 -i)/(35343.34534-i)/(3343443242.33 -i)/numbers[i];
		
		}
		System.out.println(sum);
		System.out.println(System.currentTimeMillis() - time);
	}
}
#2

Java have faster memory allocator than default c++ one. How things change if you just measure loop time? What was optimization level with c++?

#3

It depends on a ton of things, like C compiler flags and JVM runtime flags, and ofcourse, actual algorithms.

Java wins a few benchmarks, C wins most. (that’s as detailed as I’m gonna go)

#4

[quote]How things change if you just measure loop time? What was optimization level with c++?
[/quote]
If I exclude the array allocation part in the benchmark, Java wins even more :slight_smile: (before it was 1.623s s vs 1.514s, now it becomes 1.624s vs 1.414s, it looks like dynamic array allocation in c++ takes virtually no time)

The java version is running under server VM. The c++ version is compiled with g++ and without any flags. I am using windows7 64bits by the way.

#5

at least use -O2 or -O3, and enable MMX/SSE

#6

The array in your C++ code is not dynamic - it’s on the stack - “allocation” is essentially just a register add or sub.

If you’re not passing any flags to GCC it isn’t optimizing at all. Release code is typically compiled with -O2, often -O3. Beating unoptimized C++ isn’t really that impressive.

#7

Maybe it’s me showing how n00bish I am, but my understanding was:


double arr[123]; // stack allocated
arr = new double[123]; // heap allocated

I’d say he’s doing heap allocation and thus ‘dynamic’, given that he uses ‘new’.

Having said that, an aggressive compiler would remove the entire array, as each element is written into, then directly read from, never to be used again, so it could just as well be a register read/write.

#8

I have tried to compile my program with -O2 -mmmx -msse -msse2, but it makes no difference in performance.

Maybe it’s just the code I wrote is very hard for g++ to exploit.

#9

Nope - you’re correct, of course.

I was half listening to someone talking here, and scanned the code very quickly. Seeing a local array of small, static dimension, I must have skipped past the “new”. It would never have occurred to me to use “new” in such a case.

I need to learn to pay full attention when posting!

#10

It’s not “now”. I remember read an article on early 2000 that showed Java is faster, but ofc I then found out it really depends on the test case/stress.

#11

I found this link. Java vs. C++

It’s too old, I’m searching for a new one.

#12

This stackoverflow question seems interesting.

C++ performance vs. Java/C#

#13

Funny how you say NOW when you use a version of Java that is already balding :s

#14

Gad’s not this again.

  1. Writing benchmarks that mean anything is a skill and quite difficult to get right when you know what you’re doing.
  2. Never draw generalized conclusion from a well written benchmark.
  3. Ignore poorly written benchmarks.
#15

Java wins mostly because you don’t have to do any work – what most people do.

In real commercial applications C++ might be faster because a lot of effort is put to hand tuning most of the code.

This is just like manual vs auto driving.

#16

I can’t comment on the C code, but with java I wouldn’t be using System.currentTimeMillis for benchmarking. The resolution of this timer on some systems is notoriously low, with Windows being somewhere around 16ms. When you’re looking at result around 1 - 2 seconds, this is significant.

#17

To the OP:

Your forgot a delete[].

#18

Sigh: numbers should be transformed away. It dead. See points #1 & #3 above.

#19

Try to remove pointless array. Does this change stats?

#20

Your code could easily be optimized by a compiler to:


      // double[] numbers = new double[32000000];
      double  sum = 0;
      //for(int i = 0; i < 32000000; i++) {
      int i = 32000000 - 1;
      do
      {
        // numbers[i] = 3141592654.987654321/i;
        sum+= i/3.141592654987654321/(i+3.14159269876)/(3.14159269876 -i)/(35343.34534-i)/(3343443242.33 -i) / (3141592654.987654321/i);
      } while(i-- != 0);
}

Which would save time because there is no need to allocate the array, write to memory inside the loop, and because comparing registers to zero after doing an arithmetic operation is free.

You should write the contents of numbers to a file. (This does not need to be timed.) It would make optimizing it away impossible. You could also compare the binary values of the double precision numbers. The C++ code may be doing something different and thus produce slightly different numbers.

Edit: Ignore the reverse order optimization I mentioned. It is something Java would probably do that C++ wouldn’t if your numbers were integral types, but Java is not allowed to do so for floating point numbers because it would produce different end results.

Would anyone else be surprised if Java was slower than C++ for code fragments that were just plain number crunching? It’s almost as if there is a persistent myth that Java is slow or people don’t understand that the Hotspot JRE contains an optimizing compiler that produces native machine code. :clue: