Linked by Thom Holwerda on Sat 8th Oct 2005 18:40 UTC, submitted by anonymous
Java Programmers agonize over whether to allocate on the stack or on the heap. Some people think garbage collection will never be as efficient as direct memory management, and others feel it is easier to clean up a mess in one big batch than to pick up individual pieces of dust throughout the day. This article pokes some holes in the oft-repeated performance myth of slow allocation in JVMs.
Thread beginning with comment 42379
To view parent comment, click here.
To read all comments associated with this story, please click here.
Simba
Member since:
2005-10-08

By the way, here are some tests I ran myself. I did not write the code, but I compiled it myself on my system. Tell me again that the benchmarks conclude Java is slow?

In the following tests, Java outperforms C on every test except for the "life" test. Tests were conducted with mingw gcc 3.4.2 on WinXP using -O2 optimization, and Java 1.5.0_04. Bigger numbers are better for all tests. Tests are averages throughout a range of sizes / numbers:

Fast Fourier Transform: C: 521.9 | Java: 528.4

Fibonacci: C: 249.6 | Java: 372.9

Life: C: 288.1 | Java: 150.8

Infilife: C: 359.1 | Java: 434.9

Again, in all tests with the exception of the Life test, Java performed better than C.

Reply Parent Score: 1

dmantione Member since:
2005-07-06

In the following tests, Java outperforms C on every test except for the "life" test. Tests were conducted with mingw gcc 3.4.2 on WinXP using -O2 optimization, and Java 1.5.0_04. Bigger numbers are better for all tests. Tests are averages throughout a range of sizes / numbers:

Fast Fourier Transform: C: 521.9 | Java: 528.4
Fibonacci: C: 249.6 | Java: 372.9
Life: C: 288.1 | Java: 150.8
Infilife: C: 359.1 | Java: 434.9

Again, in all tests with the exception of the Life test, Java performed better than C.


Your optimizations are different than shootout ones, which use -O3 -fomit-frame-pointer -funroll-loops ; but it shouldn't matter that much.

But for completeness, please retest with some more optimizations. For example the Fibonacci test is heavily dependant on the function call overhead. In other words it will depend heavily on optimizations that reduce the overhead. Try -fomit-frame-pointer and -mregparm=3 . -mfpmath=sse2 will help for FPU benchmarks, especially on a P4. Okay, Java can do these things automatically, which is a strong point of Java.

By the way, these test are from the *original* Shootout benchmark, which is much more flawed than the one you have criticised.

Reply Parent Score: 1

Simba Member since:
2005-10-08

"By the way, these test are from the *original* Shootout benchmark, which is much more flawed than the one you have criticised."

Yes, I found out they were flawed last night (although not as flawed as the ones I criticized because at least these ones did test on more than one value and did multiple repetitions), and redid them with some corrected versions I found. Here are the new results:

FFT: C: 69488 | Java: 62446
Life: C: 615405 | Java: 607263
Infilife: C: 6699 | Java: 19279

These new tests show C slightly ahead of Java on the FFT and Life tests, but the difference is statistically insignificant from a performance perspective. Java clearly blows C away though on the Infilife test.

"O3 -fomit-frame-pointer -funroll-loops"

I haven't tried this on all of the tests yes. I did try it on the FFT test, and it yielded no performance increase. In fact, the results were actually slightly worse on the FFT test with these optimizations turned on.

I mainly chose to do the tests with -O2 since this is the most common optimization that typical software is built with on gcc.

Also, to be entirely fair, it's possible I would get somewhat better results from C if I had access to Visual C++ to run these tests. It can probably do a better job of optimization on Win32 than GCC can.

Reply Parent Score: 1