8 ms·
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
by rjurney 17y ago
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=fasta&p1=java-2&p2=java-2&p3=java-2&p4=java-2 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.
- gaius 17y agoJava 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.
- rjurney 17y agoYeah... the table shows that memory usage is another story entirely :)
- fauigerzigerk 17y agoWait 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.
- igouy 17y ago> 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 ?
- fauigerzigerk 17y agoYou'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.
- blub 17y agoI'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%.
- rjurney 17y agoYou'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.
- igouy 17y ago> And if you'll notice, Java smoked the gcc C benchmark Notice that there are 2 gcc C programs.
- ilyak 17y agoSpeed is logarithmic. 20% is logarithmic-speak is "tiny".
- blub 17y agoWe have two numbers: X, and Y, which is 20% larger than X. Where is the logarithm?