Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparison of C++17, Go, and Java for a next-generation sequencing tool

bmcbioinformatics.biomedcentral.com

Post reply on HN
Print view View original

11–20 of 190 posts

Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool

#11

Post by vardump »

jolmg wrote: post #9

> Based on our benchmark results, we selected Go as our new implementation language for elPrep, and recommend considering Go as a good candidate for developing other bioinformatics tools for processing SAM/BAM data as well. They don't seem to take into account that their results depend on their own proficiency in each programming language.

> They don't seem to take into account that their results depend on their own proficiency in each programming language.

If they're going to implement it as well, then that's perfect. They now know which language they should be using with their proficiency.

In some other team, Java might have been #1. The overall best results with a great team would almost certainly be achievable by using C++.

But this is what worked for them.

Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool

#12

Post by Rochus »

def-lkb wrote: post #8
beering wrote: post #5

Earlier quoted context omitted.

Yeah, further down in the article they track down the gap between cpp and Go/Java to the ref-counting deallocation work. I'm not a cpp expert, but it seems surprising to me that GC would beat ref-counting in any scenario.

That might seem counter-intuitive, but tracing GC is the fastest way to manage memory in general (arbitrary life time, graph shapes and allocation patterns). It permits really fast allocation, defragmentation and is sometime the only way to manage memory (cyclic datastructures for which reachability cannot be known directly from program text). Reference-counted GC on the other hand is notoriously slow, incomplete, an…

In C/C++ we have the possibility to avoid dynamic allocation altogether and to use system features like memory mapping. If we use C++ the same way as Java (everything dynamically) it's not too surprising the result is not (much) faster than Java.

Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool

#13

Post by JoeSmithson »

Rochus wrote: post #6

I had a quick look at the C++ source code provided at https://github.com/ExaScience/elprep-bench/tree/master/cpp . As suspected, everything is dynamically allocated and no memory mapping (see e.g. http://man7.org/linux/man-pages/man2/mmap.2.html ) is used. No wonder this is slow and eats a lot of memory. At the moment I have no information about why this design was chosen, if there is a justification for it, or if th…

The problem with C++, for a lot of people, is not that it's impossible to do it right, but that it's easy to do it wrong.

Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool

#14

Post by mcguire »

beering wrote: post #5
adrian_b wrote: post #4

Earlier quoted context omitted.

It seems that the performance was dominated by memory management, so the comparison is not between the languages per se, but between their current garbage collectors, and respectively the reference counting implementation for C++.

Yeah, further down in the article they track down the gap between cpp and Go/Java to the ref-counting deallocation work. I'm not a cpp expert, but it seems surprising to me that GC would beat ref-counting in any scenario.

"With reference counting, objects are recognized as obsolete due to their reference counts dropping to zero. Deallocation of these objects leads to transitive deallocations of other objects because of their reference counts transitively dropping to zero. Since this is an inherently sequential process, this leads to a similar significant pause as with a stop-the-world garbage collector."

There are three primary performance penalties for reference counting:

1. This, where dropping one link causes a deallocation chain.

2. A typical heap implementation will leave live objects scattered throughout memory, leading to cache issues.

3. Maintaining the reference counts may cause writes to memory, leading to other cache issues, plus atomicity.

Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool

#16

Post by jolmg »

vardump wrote: post #11
jolmg wrote: post #9

> Based on our benchmark results, we selected Go as our new implementation language for elPrep, and recommend considering Go as a good candidate for developing other bioinformatics tools for processing SAM/BAM data as well. They don't seem to take into account that their results depend on their own proficiency in each programming language.

> They don't seem to take into account that their results depend on their own proficiency in each programming language. If they're going to implement it as well, then that's perfect. They now know which language they should be using with their proficiency. In some other team, Java might have been #1. The overall best results with a great team would almost certainly be achievable by using C++. But this is what worked…

Yes, for them that's great, but their statement sounds like they're suggesting their results would apply for everyone.

Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool

#18

Post by vardump »

jolmg wrote: post #16
vardump wrote: post #11

Earlier quoted context omitted.

> They don't seem to take into account that their results depend on their own proficiency in each programming language. If they're going to implement it as well, then that's perfect. They now know which language they should be using with their proficiency. In some other team, Java might have been #1. The overall best results with a great team would almost certainly be achievable by using C++. But this is what worked…

Yes, for them that's great, but their statement sounds like they're suggesting their results would apply for everyone.

Funny how people think what works for them works for everyone... so easy to fall into that trap even with the best intentions.

Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool

#19

Post by Magnap »

nemetroid wrote: post #17

I think the original title is better, although dropping "full-fledged next-generation" would be an even better choice. > A comparison of three programming languages for a full-fledged next-generation sequencing tool

"next-generation sequencing" is a term of art in this case

Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool

#20

Post by zwieback »

The fact that gc is well suited to this application isn't suprising but what I thought was interesting was that subtracting the time to do the deallocation from the C++ benchmark brought it into line with Go. In other words, ignoring mem management, for this application, Go and C++ performed on par.
Post reply on HN