Hacker News Reader

Comment by rjurney | Hacker News Reader

I was looking at doing BLAST searches on genetic data in Erlang and checked out the benchmarks for the algorithms on different languages. I was shocked to see the performance benchmark for FASTA on one of the benchmark sites: Java was only slightly slower than C++, about 20% off the mark. http://shootout.alioth.debian.org/u32q/fulldata.php?test=fas...

Found the url:

Java -server: 7.54 seconds

C gnu gcc: 9.33 seconds

C gnu gcc #4: 5.29 seconds

C++ GNU g++ #4 6.21 seconds

I'd always thought of Java as slow, from the early SWING days. Nope. Java is really fast. Not sure how globally applicable this is, but I thought it was neat. Considering what its features buy you... 20% for this algorithm is pretty cheap. Although for C I guess its a bit more.

View on HN

Java is fast if a) you have lots of memory and b) you can write off the VM startup time. Now memory is cheap and you can buy boxes off the shelf these days with 128G in, but at the point you run out and need to swap, your performance is destroyed. Of course this is true for all languages, but C (et al) won't hit that problem 'til much much later. That's clearly shown in the statistics.

As for point b, no-one is using Java to write command-line tools for that very reason.

Yeah... the table shows that memory usage is another story entirely :)

Wait a second... :-) gaius is completely right about the memory issues with Java and this is the major difference between Java and C++ nowadays.

But what you see in the shootout tables is irrelevant for applications that hold a lot of data in memory. These numbers comprise almost exclusively the JVMs own memory as the benchmark problems use almost no data. If you load gigs of data into memory the 15MB or so JVM baseline memory consumption becomes negligible.

My own experience is that Java uses about twice as much memory as C++ does. Where a lot of strings are used, Java's choice of UTF-16 for representing strings has a big effect on top of using references instead of values everywhere.

C#'s value types can help a lot to reduce memory consumption by the way.

> These numbers comprise almost exclusively the JVMs own memory as the benchmark problems use almost no data.

293,788KB ? 762,836KB ? 152,820KB ? 569,632KB ? 473,416KB ? 120,132 KB ?

You're right, I should've been more specific about which ones I mean, but if you look at the numbers they show exactly what I was explaining.

Those tests with very low memory usage show Java using 16 times as much memory as C++ because almost all of it is VM memory, whereas the tests using a lot of memory show Java using only around twice as much memory.

At least that's the general picture. I know very well that it depends hugely on what kind of data structures are being used and so on, so it's going to vary.

I've noticed a curious trend with managed language programmers: they tend to say that language X is almost as fast as C, or has C-like speed when in reality it is significantly slower. In your case, "slightly" means 20%.

You're correct - because for what you get for that 20%, it is very small :) And if you'll notice, Java smoked the gcc C benchmark. By more than 20% :)

Most 'managed language' programmers are happy to give up way more than 20% for the benefits they give over verbose assembly.

> And if you'll notice, Java smoked the gcc C benchmark

Notice that there are 2 gcc C programs.

And two Java as well. What the heck do they mean? What is GCC vs GCC #4?

I suspect GCC version 4, probably compared to GCC version 3, which only recently was superseded in "enterprise" Linux distros.

Speed is logarithmic.

20% is logarithmic-speak is "tiny".

We have two numbers: X, and Y, which is 20% larger than X. Where is the logarithm?

It's in axes, obviously.

You draw those X and Y according to them.

You have a simulation that will take either four days to run or five. That's not tiny. And that's not so rare a problem. Not everyone is doing web apps.

I remain skeptical of these micro benchmarks. Almost every time I've messed around with porting pieces of C++ to Java or C# and benchmarking it I get a large difference in favor of C++.

Yeah, who would do serious crunching using Java? Those Hadoop idiots!

Hadoop is a platform for traversing very large data sets. It is not really for "number crunching." One can use any language for the map/reduce pieces of Hadoop.

Actually, plenty of guys use Hadoop for CPU bound problems.

And the fastest way to use it this way is Java, which is what the number crunching users of Hadoop use. Which is to say that the emerging big data compute platform is Java. Which is to say that you're wrong.

Hadoop is not "for CPU bound problems." It's for huge data. There are much better frameworks for the problem of splitting a parallelizable computation across machines. Nobody would use Hadoop just for that.

Why would Java be the fastest way to do computations with Hadoop? You can use many languages for the map/reduce pieces. The fastest language would be fastest language, not necessarily Java.

Of course I'm talking about those subset of problems which are CPU bound and also use huge data.

As to why streaming is slow: I don't know. It just is. Check it out. C++ streaming performance is the pits.

Reply on news.ycombinator.com