Comparison of C++17, Go, and Java for a next-generation sequencing tool
bmcbioinformatics.biomedcentral.com
Comparison of C++17, Go, and Java for a next-generation sequencing tool
1–10 of 190 posts
Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool
#2the source code: https://github.com/ExaScience/elprep-bench
Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool
#3TLDR: 1. Go, 2. Java, 3. C++17.
Java was slightly faster than go but used significantly more memory. C++17 was slower than both and used more memory than go.
I’m still reading for more details on the implementations, but the results are certainly not what I would’ve predicted.
Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool
#4TLDR: 1. Go, 2. Java, 3. C++17. Java was slightly faster than go but used significantly more memory. C++17 was slower than both and used more memory than go. I’m still reading for more details on the implementations, but the results are certainly not what I would’ve predicted.
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++.
Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool
#5TLDR: 1. Go, 2. Java, 3. C++17. Java was slightly faster than go but used significantly more memory. C++17 was slower than both and used more memory than go. I’m still reading for more details on the implementations, but the results are certainly not what I would’ve predicted.
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.
Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool
#6I 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 the developers only knew this option. Maybe I can find some hints in the paper. From what I've seen up to now it can be savely assumed that with optimal use of data structures and system functions the C++ results are at least one order of magnitude better.
Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool
#7the source code: https://github.com/ExaScience/elprep-bench
That has the Java and C++ versions. Here's the Go version:
Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool
#8Earlier 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.
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, and exhibit lots of bad performance patterns (that can be somehow managed by taking some elements of tracing GCs).
The drawback is that tracing GCs are very hard to implement, to tune, and sometimes not all of the benefits are available at the same time. And because they are so counter intuitive, programmers in general have a hard time understanding their runtime behavior... Even GC experts struggle (the skills required range from low-level hardware to control theory, otherwise performance at scale is unpredictable).
Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool
#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.
Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool
#10Earlier 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.
Refcounting can mess with caches in multithreaded scenarios, so results aren't really surprising to me. It also generates unnecessary work to maintain counters on all writing threads, while concurrent tracing GC batches all its actions on separate thread.