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

141–150 of 190 posts

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

#141

Post by Leherenn »

pansa2 wrote: post #137
04091948 wrote: post #104

Earlier quoted context omitted.

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::”.

Array is great as far as I know.

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

#142

Post by DeathArrow »

DeathArrow wrote: post #30
aidenn0 wrote: post #15

I thought it was well known that reference counting is slower than all but the worst tracing GCs.

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

Before downvoting, please look at benchmarks.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://www.techempower.com/benchmarks/#section=data-r18&hw=...

https://github.com/frol/completely-unscientific-benchmarks

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

#143

Post by llm »

movedx wrote: post #129
kllrnohj wrote: post #124

Earlier quoted context omitted.

If you know Go and don't know C++ then yes absolutely use Go. If you're trying to do a performance comparison though it doesn't seem unreasonable to have "basic" familiarity with the languages being compared? None of the knowledge mentioned is "esoteric". We're not talking hyper optimized insane C++ optimizations here with custom allocators and specialized code generation with templates. We're talking "basic" memory…

> If you're trying to do a performance comparison though it doesn't seem unreasonable to have "basic" familiarity with the languages being compared? No. Because it's not just a performance comparison, really. Without realising it, it's also a learning test. The very fact they wrote sub-par C++ code, likely without realising it, and then proceeded to produce (sub-par?) Go code that was faster demonstrates the difficul…

they clearly want the performance - the algorithms (as you can easily see in the repo) are trivial, its just a huge amount of data to process

C++ can shine here - and still looking nearly like the go or Java-Code (due to the simple algorithm) but some one tried to write highly sophisticated code (there is no tutorial or book about C++ that teaches you to do it that way) with the result that C++ is far more slower then possible - we definitly not talking about 10% gain here

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

#144

Post by teleforce »

google234123 wrote: post #113

Ignoring the terrible C++, why would they bother to write the same program in three languages. I feel like spending 3x time on just one of them would have produced the best outcome.

In academic publication it is a convention to compare your proposed implementation with at least the other two comparable competitors (languages, framework, algorithm, scheme, etc). I think it is naturally intriguing and refreshing to see the performance comparison of programming languages by the the non-author of the languages themselves even though the implementations are probably not optimized to death.

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

#145

Post by 59nadir »

movedx wrote: post #129
kllrnohj wrote: post #124

Earlier quoted context omitted.

If you know Go and don't know C++ then yes absolutely use Go. If you're trying to do a performance comparison though it doesn't seem unreasonable to have "basic" familiarity with the languages being compared? None of the knowledge mentioned is "esoteric". We're not talking hyper optimized insane C++ optimizations here with custom allocators and specialized code generation with templates. We're talking "basic" memory…

> If you're trying to do a performance comparison though it doesn't seem unreasonable to have "basic" familiarity with the languages being compared? No. Because it's not just a performance comparison, really. Without realising it, it's also a learning test. The very fact they wrote sub-par C++ code, likely without realising it, and then proceeded to produce (sub-par?) Go code that was faster demonstrates the difficul…

The flip side to this is that for someone who knows roughly what a CPU does (you don't need in-depth knowledge to think about pre-fetching and branch prediction) C++ is going to be easier to use to leverage that. That's really the end of it.

I agree with you that writing C++ is harder than writing Go and that writing naïve C++ leading to disproportional pessimization of your program shows that it's not the right tool for people who lack the knowledge to use it.

At the same time it's really not hard to translate simple concepts into simple code for lower-level languages, that runs well on modern processors. Basic usage of (possibly) growable, homogenous arrays will get you far. Contrary to what most C++ app developers seem to think custom allocators aren't complicated either, and will guarantee that you get much better cache locality and memory management.

Most of these issues are made hard by people, including the premise of learning the basics of what you need to do for the processor to execute your code fast.

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

#146

Post by 59nadir »

pansa2 wrote: post #137
04091948 wrote: post #104

Earlier quoted context omitted.

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::”.

STL is mostly garbage, which is a big reason it's not used in places that actually need performance, both for build times and runtime.

Yes, it's embarrassing. I think it should be noted that the performance mantra is mostly for show with C++, though. The same people who spout it will also blatantly use pessimizing language features just because, when normal, procedural code would've done the job faster and ultimately simpler.

I think the performance overhead of a few things in C++ make sense, but in general you get performance in C++ by turning things off and abstaining from most of the features. Exceptions complicate mostly everything, so the best thing to do is to turn them off and not rely on anything that uses them, for example.

Modern C++ isn't fast and most of C++ wasn't even before the modern variant was invented. The C "subset" is.

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

#147

Post by icholy »

movedx wrote: post #128
comex wrote: post #125

Earlier quoted context omitted.

‘Esoteric’ is in the eye of the beholder. Even in Go you gain performance by avoiding boxing. > If I can get the same work done in Go and I can learn Go in a week versus months for C++17 (which is far more complex), why would I pick C++17? Because C++17 code if written well is likely to be much faster. If you don’t care about that, by all means stick with Go. But keep in mind that learning is a one-time cost, and you…

> Even in Go you gain performance by avoiding boxing. Go has boxing? > Because C++17 code if written well is likely to be much faster. I was hoping someone could prove this, actually. I don't have the means or the knowledge.

interfaces

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

#148

Post by gpderetta »

WesternStar wrote: post #105
cozzyd wrote: post #89

Earlier quoted context omitted.

why not just define std::dict or something like that that is better?

Because you should be able to find a good hash data structure for your language. You shouldn't be able to accidentally get a bad one. It should arguably be the first data structure you reach for.

I think the parent is proposing adding a better hash map to the standard library but with a different name to preserve backward compatibility.

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

#149

Post by IshKebab »

benibela wrote: post #80
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…

>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…

It's not very slow. It's faster than `std::map` and we lived with that for years!

It's just not as fast as some other implementations: https://tessil.github.io/2016/08/29/benchmark-hopscotch-map....

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

#150

Post by IshKebab »

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…

Maybe they wrote it really badly so someone will take offence and rewrite it for them!

Also in my experience `std::deque` is almost always slower than `std::vector`. In theory it shouldn't be, but copying contiguous data is so fast on modern CPUs that the reallocation of `std::vector` (or occasional front-insertion) is very cheap.

Post reply on HN