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

181–190 of 190 posts

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

#181

Post by movedx »

59nadir wrote: post #145
movedx wrote: post #129

Earlier quoted context omitted.

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

That being said if the time invested in learning C++ and the extra time needed to write it and optimise it doesn't exceed the performance of the same solution written in (optimised) Go by a factor larger than the time invested then it's not the right choice overall.

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

#182

Post by dataangel »

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…

The problem with that idea is that he actually used more advanced features to make it worse (any_cast). This is not how you would do it if you picked up a beginner C++ book and read the first few chapters.

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

#183

Post by dataangel »

59nadir wrote: post #146
pansa2 wrote: post #137

Earlier quoted context omitted.

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…

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

Look forward to all your users ignoring your return codes and never calling valid() on your objects that can only signal construction failed that way.

Also the impact of exceptions on performance is overblown, even in high perf situations:

https://news.ycombinator.com/item?id=20342183

Throwing is slow, but throwing is supposed to be rare. Don't use it as flow control.

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

#184

Post by adev_ »

kouteiheika wrote: post #179
adev_ wrote: post #171

Earlier quoted context omitted.

> 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. It is NOT garbage. It is more than sufficient for the 99% of devs that need key in hand data structure and good enough performance (Meaning faster than 99% of over programming languages already). If what you need is sub micro-second perf, then yes, redefined your data-structure. BTW…

> It is more than sufficient for the 99% of devs that need key in hand data structure and good enough performance (Meaning faster than 99% of over programming languages already). I really don't get this argument. If you don't need pedal-to-the-metal performance then why are you using C++ in the first place? (Unless, of course, your answer is "legacy code".) C++ is being touted as being high performance, but basically…

> I really don't get this argument. If you don't need pedal-to-the-metal performance then why are you using C++ in the first place? (Unless, of course, your answer is "legacy code".)

There is many other things that pure compute-bound CPU performance that can drive you to a GC-less language like C++. Fine grain memory usage is one of them, latency control is an other.

> `std::regex`'s performance is bad. , `std::unique_ptr` doesn't optimize as well as a plain pointers

std::regex is not defendable, specially when there is much better implementation already available (https://github.com/hanickadot/compile-time-regular-expressio...)

However, do you have any bench / source for std::unique_ptr ? You are the first one I hear giving critics on it.

> Do you, though? Rust already replaced their standard hash map implementation with a completely different one which was faster, so it shows that it can be done.

Rust does not have 25 years of code base behind him. We can talk to that again when he gets 10 years more.

C++ can not afford to randomly break API on one of its core STL component just to hypothetically gain few bit of performance.

It can be done, but it should be done with a depreciation process and an alternative implementation, like it has been done for auto_ptr -> unique_ptr.

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

#185

Post by steveklabnik »

adev_ wrote: post #184
kouteiheika wrote: post #179

Earlier quoted context omitted.

> It is more than sufficient for the 99% of devs that need key in hand data structure and good enough performance (Meaning faster than 99% of over programming languages already). I really don't get this argument. If you don't need pedal-to-the-metal performance then why are you using C++ in the first place? (Unless, of course, your answer is "legacy code".) C++ is being touted as being high performance, but basically…

> I really don't get this argument. If you don't need pedal-to-the-metal performance then why are you using C++ in the first place? (Unless, of course, your answer is "legacy code".) There is many other things that pure compute-bound CPU performance that can drive you to a GC-less language like C++. Fine grain memory usage is one of them, latency control is an other. > `std::regex`'s performance is bad. , `std::uniqu…

Rust didn't break the API of HashMap. The trick is that the STL decided that certain algorithmic requirements were a part of the interface. For std::map, the case here is that it must be sorted. Its API also means you can't be polymorphic over a hashing strategy. This constrains possible valid algorithms. Rust made the opposite choices.

And so they did exactly what you say, for that reason. std::unordered_map is a better comparison.

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

#186

Post by cppbert »

movedx wrote: post #180
llm wrote: post #143

Earlier quoted context omitted.

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

> 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 my point is: it didn't. And it didn't because of the learning curve involved. It's only the better solution if the knowledge is invested in ahead of time, and if the gains don't outweigh those you'd get from Go by an amount that greatly exceeds the ti…

but your point is just not correct - i know go, Java and C++ very well and i don't understand why the C++ code isn't just like the Java code - there is absolutely no need for this deep nested, ugly, container parties that are not in the Java code at all

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

#187

Post by cppbert »

movedx wrote: post #181
59nadir wrote: post #145

Earlier quoted context omitted.

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…

That being said if the time invested in learning C++ and the extra time needed to write it and optimise it doesn't exceed the performance of the same solution written in (optimised) Go by a factor larger than the time invested then it's not the right choice overall.

you are just wrong - someone without any good C++ knowlegde except porting the Java port plain to C++, ported it by using every crude feature and wild combination of shared-ptr, container nesting in a way you will nearly not find in any open source or tutorial project - its not about the ease of go, the the benchmark results are just wrong in so many ways

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

#188

Post by aw1621107 »

adev_ wrote: post #184
kouteiheika wrote: post #179

Earlier quoted context omitted.

> It is more than sufficient for the 99% of devs that need key in hand data structure and good enough performance (Meaning faster than 99% of over programming languages already). I really don't get this argument. If you don't need pedal-to-the-metal performance then why are you using C++ in the first place? (Unless, of course, your answer is "legacy code".) C++ is being touted as being high performance, but basically…

> I really don't get this argument. If you don't need pedal-to-the-metal performance then why are you using C++ in the first place? (Unless, of course, your answer is "legacy code".) There is many other things that pure compute-bound CPU performance that can drive you to a GC-less language like C++. Fine grain memory usage is one of them, latency control is an other. > `std::regex`'s performance is bad. , `std::uniqu…

> However, do you have any bench / source for std::unique_ptr ? You are the first one I hear giving critics on it.

Chandler Carruth talks about this at CppCon 2019 [0]. From a quick review he says part of the reason std::unique_ptr isn't zero-cost right now is:

- Objects passed by value (like std::unique_ptr) are passed on the stack instead of in registers, and changing that will be an ABI break

- No destructive move means extra temporaries will be created/retained

[0]: https://youtu.be/rHIkrotSwcc?t=1046

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

#189

Post by beached_whale »

gpderetta wrote: post #159
beached_whale wrote: post #111

Earlier quoted context omitted.

A copy in function arguments often is not expressed by the compiler and often allows more optimizations.

For relatively small objects with no internall allocation, definitely yes. Otherwise only a qualified yes: if you are copying it anyway in the body, pass by value allow moving object into and actually avoid copies, but the code linked doesn't use move at all anywhere. As they seem fairly versed in C++, the only reason for doing that is that they want their code to be modificable by non-programmers, so they want to us…

Def a qualified yes. The pass by value will often allow the compiler to deal with less as a pass by ref/ptr makes it more pessimistic. You see this play out in trying to get the auto-vectorizer going by copying N values to a local buffer in the loop prior to operating in them.

The optimizer in c++ compilers are really good at inlining and if it's a single TU more so. So the size isn't the issue in those cases too. In addition, on the other size most optimizers have a form of return value optimization that elides the copy/move on the return value.

Where they often get hit up or lacking is heap allocations. They seem to hide a lot and only some compilers can elide a heap allocation.

Use after move is interesting. Many cases of move are not necessary anyways (returning an automatic storage object) but the complexity of the code already would be on part with using std::move. I don't think an optimizer will do that one even if it is that last usage.

Post reply on HN