Yesterday, Slashdot posted an article that linked to The Java Faster than C Benchmark (done by this guy). Now, I really don't care one way or another if Java can be made to be faster than C++. But, I did want to see the difference hardware makes with Java. So, I took his source for the ackermann class:
public class ackermann {
public static void main(String[] args) {
int num = Integer.parseInt(args[0]);
System.out.println("Ack(3," + num + "): " + Ack(3, num));
}
public static int Ack(int m, int n) {
return (m == 0) ? (n + 1) : ((n == 0) ? Ack(m-1, 1) :
Ack(m-1, Ack(m, n - 1)));
}
}And, I ran it on a Sun Fire V880 with 4 processors and 30G worth of RAM. I wanted to see how much faster it would run when compared to his machine's specs — a P4 with 512M of RAM.
But, when I ran it; it overflowed its stack:
smith@barra:~$ java -version
java version "1.4.2_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)
smith@barra:~$ time java -server ackermann 13
Exception in thread "main" java.lang.StackOverflowError
real 0m13.416s
user 0m13.300s
sys 0m0.070s
smith@barra:~$
Did he fudge results or is his Java compiled with the --really-big-stack option and mine isn't? Chuckie, can you weigh in on this one?
Even passing in an argument of 12 caused it to throw java.lang.StackOverflowError. The largest number it would work with was 11:
smith@barra:~$ time java -server ackermann 11
Ack(3,11): 16381
real 0m9.884s
user 0m9.750s
sys 0m0.070s
smith@barra:~$
Comments
Ok, first of all, use -Xss to update your stack size, ala 'java -Xss8192k ackermann 12'. Stack size is a run-time thing, not a compile time thing.
Second, I have no idea what 'java -server' does, I've never even seen that.
Third, you need to ditch those Sun boxes for a brand new
IBM p650:
awismar@at0801a:~$time /usr/java14/bin/java ackermann 11
Ack(3,11): 16381
real 0m1.816s
user 0m1.740s
sys 0m0.010s
Interesting 1.3.1 results:
awismar@at0801a:~$time /usr/java131/bin/java ackermann 11
Ack(3,11): 16381
real 0m1.336s
user 0m1.290s
sys 0m0.020s
Damn! Your shit ran way faster!
Are you using jikes? Does jikes make that much of a difference? Why is my Java so slooooow.
Send me a couple of those boxes.
From Frequently Asked Questions About the Java HotSpot VM:
Even running with the -Xss8192k, I still get a real bad time:
smith@barra:/a/celerra-dm1/fs04/homes/smith$ time java -server -Xss8192k ackermann 13
Ack(3,13): 65533
real 2m51.448s
user 2m50.450s
sys 0m0.080s
Compare that to the numbers he posted with his P4:
[keith@leak bench]$ time java -server -cp java ackermann 13
Ack(3,13): 65533
real 0m37.105s
user 0m34.530s
sys 0m0.170s
What's up with this crappy Sun Fire?
Sun blows, and the -Xss shouldn't help your time at all, merely allow your JVM the stack size it needs to complete the damn thing.
Plus, I'm using IBM's JDK on the p650, so that helps.
No jikes, just $javac ackermann.java, $time java ackermann...
I'm going to go grab IBM's JDK and see how much of a difference that makes.
Hmmm... okay, they don't seem to have a JDK for Solaris, which now that I think about it, makes perfect sense...
I don't know if you read my benchmark results, or just assumed what they said, but I got a StackOverflowError with the client JVM for the Ackermann as well. That's why there's no graph data or tabular data for the client JVM for the Ackermann test on my results page.
I thought I just posted this, but I don't think the post went through. I don't know if you read my benchmark results, but I got that same error for the Ackermann test with the client JVM. That's why there's no graph data or tabular data for it, and an asterisk next to the N/A in the results.
According to the Console run log, you were able to get a clean run with the -server option:
That was my mistake, you're right, you did use -server. I don't know why your stack overflowed and mine didn't.