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

51–60 of 190 posts

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

#51

Post by ken »

etse wrote: post #44
DeathArrow wrote: post #30

Earlier quoted context omitted.

True. C# and Java constantly beat Swift on speed.

Sorry about the naive question, but if the memory management overhead is worse in Swift, is the hardware it runs on typically better? I'm assuming some of this because I've noticed Android devices tend to require more CPU/memory compared to iOS devices in the same generation.

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...

Lattner on Swift (2016): "...while it is true that modern GC's can provide high performance, they can only do that when they are granted much more memory than the process is actually using. Generally, unless you give the GC 3-4x more memory than is needed, you’ll get thrashing and incredibly poor performance..."

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

#52

Post by gumby »

zmower wrote: post #40

"We have not performed a detailed comparison against the original version of elPrep implemented in Common Lisp, but based on previous performance benchmarks, the Go implementation seems to perform close to the Common Lisp implementation." LMFAO.

Why would that be funny?

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

#53

Post by lpghatguy »

shrimp_emoji wrote: post #42

No Rust smh

It was mentioned in the article and was not considered a candidate due to a specific API requirement:

> Other mature programming languages with support for reference counting include Objective-C, Swift, and Rust [50]. However, in its algorithm for duplicate marking, elPrep requires an atomic compare-and-swap operation on reference-counted pointers, which does not exist in those languages, but exists in C++17.

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

#55

Post by thelazydogsback »

Rochus wrote: post #22
JoeSmithson wrote: post #13

Earlier quoted context omitted.

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.

I think this applies to any kind of advanced software development or programming languages, not only C++. There may be many reasons why scientists who are not computer scientists feel more comfortable with Go than with C++, but performance is certainly not one of them.

It depends on your definition of "wrong". You can mess up your domain logic with any language, but the chances of messing up perf (and even some ref vs. copy semantics that effect logic) in C++ are vastly greater than in GC'd langs. I've ported C++ code to C# with much perf gain, due to c'tors of every kind getting called all over the place. Doing it right in C++ is too much cognitive overload -- at least for me. If you're writing inner game loops or device drivers, I feel I need to pay for this complexity - for any LOB apps, I can't see choosing C++, or even Rust for that matter.

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

#56

Post by flumpcakes »

etse wrote: post #44
DeathArrow wrote: post #30

Earlier quoted context omitted.

True. C# and Java constantly beat Swift on speed.

Sorry about the naive question, but if the memory management overhead is worse in Swift, is the hardware it runs on typically better? I'm assuming some of this because I've noticed Android devices tend to require more CPU/memory compared to iOS devices in the same generation.

Apparently the custom processors used in iOS devices are actually some of the fastest out there in that form factor.

Designed by apple (I think using ARM instruction set) and made using some of the latest, most advanaced, process nodes by TMSC.

If you look at raw benchmarks, they handidly beat the best Qualcom/"android SOC" chips out there.

I think this changes very rapidly - given the market segment of high end phones has a yearly turn around. However, I did read an article today that claimed the "cheapest iPhone" (the new SE model) is faster than the most expensive android phone currently out there.

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

#58

Post by vvanders »

benhoyt wrote: post #45
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…

They address that somewhat in the discussion section: > C++ provides many features for more explicit memory management than is possible with reference counting. For example, it provides allocators [35] to decouple memory management from handling of objects in containers. In principle, this may make it possible to use such an allocator to allocate temporary objects that are known to become obsolete during the dealloca…

That's not even the real benefit you get. What you really get is the ability to specify memory locality which easily has a 10-30x performance impact.

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

#59

Post by ken »

shigeo wrote: post #32
pizlonator wrote: post #29

Very surprising result. I wouldn’t have bet that this is what would have happened. But anyone working on language perf should take note even though it’s just one result from one team and one application. Of course they probably used C++ in a not great way and probably use Go in a better way. But maybe that is caused by something in Go that encourages good behavior or at least encourages the kind of behavior that Go o…

> I wouldn’t have bet that this is what would have happened. Which part of the results are you referring to? It's well-known that reference counting has significantly lower throughput that tracing garbage collectors, so the fact that C++ is outperformed here isn't surprising at all.

As a Lisp programmer, I confess that when I see a performance shootout between Go, Java, and C++, I don't expect to hear the result that Go won -- and that its performance is on par with their old Common Lisp program.

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

#60

Post by tomp »

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…

> elPrep is an open-ended software framework that allows for arbitrary combinations of different functional steps in a pipeline, like duplicate marking, sorting reads, replacing read groups, and so on; additionally, elPrep also accommodates functional steps provided by third-party tool writers. This openness makes it difficult to precisely determine the lifetime of allocated objects during a program run

> Phase 1 allocates various data structures while parsing the read representations from BAM files into heap objects. A subset of these objects become obsolete after phase 1.

> Therefore, manual memory management is not a practical candidate for elPrep,

TL;DR: it's non-deterministic which objects will be garbage when so some for of dynamic memory management is needed.

If you disagree, what would you use instead?

Post reply on HN