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

131–140 of 190 posts

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

#131

Post by UncleMeat »

kllrnohj wrote: post #123
gpderetta wrote: post #92

Earlier quoted context omitted.

they heap allocate strings because their string_range implementation is a shared_ptr to the original string plus two indices. It might be somewhat worth it assuming the strings are large enough. But if most strings are small, passing them around by move-value would probably be an overall win. One would need to benchmark it.

In that case you'd still want a shared_string not a shared_ptr . The double pointer chases add up quick. Edit: It might help to keep in mind that string is essentially an alias for unique_ptr . As in, string is already heap allocated. They heap allocated a pointer to a heap allocation.

In my experience, this kind of error is the cause of 90% of the "wait, I thought C++ was supposed to be fast so why is it chugging compared to my Java implementation" problems. People turn everything into two dereferences.

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

#132

Post by alexeiz »

They use shared_ptr pervasively in their C++ implementation. It's not the best way to manage objects in C++ by far. The only thing that this performance comparison really tells me is that shared_ptr is worse than a modern GC. This is not really a surprising find.

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

#133

Post by oconnor663 »

thelazydogsback wrote: post #55
Rochus wrote: post #22

Earlier quoted context omitted.

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…

Rust certainly comes with its share of complexity, but it might be worth clarifying that Rust doesn't have this specific problem of implicit constructors called all over the place. Instead, everything uses move semantics by default.

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

#134

Post by brnt »

ezoe wrote: post #69

After quickly glancing the code, I concluded that they wrote C++ like there is no static type. It seems they faithfully ported the very dynamic nature of their existing code to C++ without thinking. Like what is this? https://github.com/ExaScience/elprep-bench/blob/master/cpp/f... auto alns = any_cast >>>(data); So the data is sam_alignment type inside shared_ptr inside deque inside another share_ptr inside god forbi…

Welcome to scientific programming :)

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

#135

Post by TwoBit »

ezoe wrote: post #79
RantyDave wrote: post #76

Earlier quoted context omitted.

What's wrong with unordered map?

It's implementation is buckets divided node based hash map. Theoretically, its order is good, but not that efficient in modern hardware where the memory access is heavily cached so the data locality is more important than saving the memory copy or memory size. Using the linked list to save some memory copy doesn't benefit at all and the overhead is far greater than simply copying the contagious large chunk of memory.…

So use unordered_map with an allocator that returns nodes from a small local memory?

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

#136

Post by TwoBit »

saagarjha wrote: post #86
benibela wrote: post #80

Earlier quoted context omitted.

>the unordered_map is very slow(it's a node based hash map, not suitable for the modern hardware) It is very slow? I wrote my app in FreePascal. I need a hashmap, but FreePascal has no real standard hashmap, so I have been benchmarking Pascal hashmaps for weeks/months. Today I added std::unordered_map for comparison. It will still take a day to run the benchmark, but so far it looks that std::unordered_map is 25% fas…

std::unordered_map is supposedly slow because it has fairly stringent iterator invalidation requirements. In my experience, unless you wring the most performance out of your code as you can, it's not a huge issue; it's generally faster than most casual implementations.

Yeah people here are dumping on it for being non-performance-optimal while ignoring that higher performing versions have restrictions and design limitations. unordered_map is fast enough for probably 98% of uses, and the other 2% may be better off finding a specialized version best for their particular case.

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

#137

Post by pansa2 »

04091948 wrote: post #104
tom_mellior wrote: post #96

Earlier quoted context omitted.

> They really like std::deque and use it everywhere even though the sizeof(T) is like a few dozen bytes at best so they should rather use std::vector. The data structure of deque is a list of array. while it can amortize the continious adding of the elements to front or back, since the element size is very small, they should rather use vector. Are you saying that access patterns (push/pop front/back) never matter and…

in CppCon 2016: Chandler Carruth “High Performance Code 201: Hybrid Data Structures"[1] he says: "but the standard deque data type is really quite bad. I wouldn't recommend anyone use it for anything. if you look at the implementation constraints, the constraints placed upon its iterators, and its invalidation constraints, it's painted into a very unpleasant corner and it has very few opportunities to be an efficient…

For a language whose purpose is high-performance, the std:: containers are an embarrassment. `deque` is slow, `map` is slow - so the language added `unordered_map` which is also slow...

Are any of the containers (other than `vector`) worth using in high-performance code?

I’m sympathetic to the game developers who I’ve heard say “we use C++, but nothing from std::”.

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

#138

Post by teleforce »

It seems that all the languages implementation in the benchmarking exercises are utilizing garbage collection (C++ using ref counting) it will be very interesting if someone extend this benchmark using D programming language, arguably the fastest language with GC. The fact that elPrep tool is using functional software architecture [1] and D natively supports functional programming makes me think this type of computing is very well suited for it.

[1] https://github.com/exascience/elprep

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

#139

Post by josefx »

TwoBit wrote: post #135
ezoe wrote: post #79

Earlier quoted context omitted.

It's implementation is buckets divided node based hash map. Theoretically, its order is good, but not that efficient in modern hardware where the memory access is heavily cached so the data locality is more important than saving the memory copy or memory size. Using the linked list to save some memory copy doesn't benefit at all and the overhead is far greater than simply copying the contagious large chunk of memory.…

So use unordered_map with an allocator that returns nodes from a small local memory?

To be useful that would require that the nodes are allocated in the order they appear in the map (and still has pointer overhead). Is that a given with an unordered map or does it break down the moment the map is rehashed?

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

#140

Post by llm »

movedx wrote: post #121
ezoe wrote: post #69

After quickly glancing the code, I concluded that they wrote C++ like there is no static type. It seems they faithfully ported the very dynamic nature of their existing code to C++ without thinking. Like what is this? https://github.com/ExaScience/elprep-bench/blob/master/cpp/f... auto alns = any_cast >>>(data); So the data is sam_alignment type inside shared_ptr inside deque inside another share_ptr inside god forbi…

> My conclusion, it's slow because they wrote C++ like a dynamic typed language Here's my conclusion without needing to look at the code: is C++17 so complicated a language that having to understand deeper concepts such as the ones you've mentioned means a reduced "time to market" for marginal gains over the same code written in Go? Or put another way: did you just further prove that Go is the better option because i…

that is really not the case here - the Java and C++ implementatios are very plain boring algorithm code (some maps,lists,searching) non of the fancy language features are use to reduce or optimize the code - its absolutely not a C++-is-hard-to-get-right-thing

the C++ code is just using rarely used features in over-wild combinations - as stated: it seems that someone tried to port highly dynamic script code 1:1 to C++ without any knowledge about C++ and that just make no sense, even porting the current Java-Code 1:1 to plain old C++ Code would result in a much better performing version of the algorithm

everything (even the simplest stuff) is FORCED to be heap-allocated (with huge amount of code), in case of deque and shared_ptrs even double or tripple times - without any benefit of doing it

i would bet that a more clean, less every-feature-using version of the C++ algorithm would beat the Java, go code by a huge factor

Post reply on HN