Comparison of C++17, Go, and Java for a next-generation sequencing tool • Hacker News Board

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

#171

Post by adev_ » Fri, Apr 24, 2020, 3:36 PM UTC

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…

> 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, you will very likely have to do that in any language anyway. Because it is impossible to design fast forever-living data structure. They (almost) all become obsolete when architectures evolve. Red-Black Trees where state of art DS, teached-at-school 10 years ago, they are useless garbage nowadays if you seek for performance.

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

#172

Post by SamReidHughes » Fri, Apr 24, 2020, 4:11 PM UTC

alexhutcheson wrote: post #120

WesternStar wrote: post #72

Earlier quoted context omitted.

We should break ABI on unordered map just to stop embarrassing ourselves in public and in front of new users.

It’s unfortunately not just ABI, but also API. The standard specifies that you can get iterations to specific buckets in O(1)[1], and also specifies bucket_count(), max_bucket_count(), bucket_size() (which is specified to be O(n)), and bucket(). Those functions and their specified performance make it effectively impossible to implement a standards-compliant std::unordered_map without using separate chaining. [1] http…

You can just remove those functions. The real problem is that the API break would invalidate iterators and create undefined behavior.

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

#173

Post by kllrnohj » Fri, Apr 24, 2020, 6:17 PM UTC

Leherenn wrote: post #141

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

Array is great as far as I know.

std::array is great except it's annoying to statically initialize. Really wish make_array or to_array were non-experimental a lot sooner (to_array finally did land in C++20 at least).

But yeah it does mean you can finally stop doing that silly `sizeof(a)/sizeof(a[0]);` trick.

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

#174

Post by kllrnohj » Fri, Apr 24, 2020, 6:21 PM UTC

pizlonator wrote: post #127

shigeo wrote: post #32

Earlier quoted context omitted.

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

Great point. Here’s the issue: there are tons of ways of doing reference counting in C++. Some go all-in with implied borrowing. Some make great use of C++’s various references. Some use the reference counting only for a subset of objects and rely on unique_ptr for hot things. So, there is no universal answer to how C++ reference counting compares to GC. There is a well known answer, that you’re probably referring to…

> there are tons of ways of doing reference counting in C++

There are but critically there are also a lot of ways to not do ref counting at all. C++ isn't a refcounted language, it's a language where you can use refcounting (shared_ptr), but you don't have to (unique_ptr, value types). It's not even recommended to be primarily refcounted.

They chose a really odd subset of C++ to use here (shared_ptr exclusively), very unorthodox and not something I've ever seen elsewhere or recommended.

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

#175

Post by FpUser » Fri, Apr 24, 2020, 10:01 PM UTC

benibela wrote: post #157

FpUser wrote: post #112

Earlier quoted context omitted.

Free Pascal actually does have hashmap. Check this for reference: https://wiki.freepascal.org/Data_Structures,_Containers,_Col...

But that lists like ten classes which map/hash in their name. None of them stands out, as being THE standard Pascal map to use for everything.

There are no silver bullets in the world. If I were you I would take a brief look at the code and it will be clear what's the difference.

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

#176

Post by techempower » Fri, Apr 24, 2020, 10:49 PM UTC

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…

Hashmaps Benchmarks: https://martin.ankerl.com/2019/04/01/hashmap-benchmarks-05-c...

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

#177

Post by voldacar » Fri, Apr 24, 2020, 11:02 PM UTC

imtringued wrote: post #167

voldacar wrote: post #46

This is not surprising. Parallel GC will almost always be faster than refcounting. If you wrote a C or C++ program to accomplish this task after carefully planning out exactly when stuff needs to get manually malloced/freed, you could outperform any of their approaches And like another commenter mentioned, if you're writing a program which streams a lot of data sequentially from disk, and where throughput is importan…

It doesn't require care. By default you just put stuff on the stack in C++. You have to go out of your way to use things like ref counting.

for complicated stuff involving multiple threads and shared memory, it's good to plan it out in advance in some way. but you are right that most data can just get stack allocated

if you look at their code it's like they have no clue that the stack even exists. seriously. they heap allocate EVERYTHING

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

#178

Post by voldacar » Fri, Apr 24, 2020, 11:03 PM UTC

gpderetta wrote: post #74

voldacar wrote: post #46

This is not surprising. Parallel GC will almost always be faster than refcounting. If you wrote a C or C++ program to accomplish this task after carefully planning out exactly when stuff needs to get manually malloced/freed, you could outperform any of their approaches And like another commenter mentioned, if you're writing a program which streams a lot of data sequentially from disk, and where throughput is importan…

well, there is careful planning and there is going out of the way to heap allocate everything.

Yeah i hadn't really looked into their c++ code when I wrote my comment. it looks like code written by someone who doesn't even know the stack exists. insane

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

#179

Post by kouteiheika » Sat, Apr 25, 2020, 4:08 PM UTC

adev_ wrote: post #171

59nadir wrote: post #146

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

> 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 every standard data structure besides `std::vector` is garbage for high performance, pedal-to-the-metal code. And not only data structures - `std::regex`'s performance is bad, `std::unique_ptr` doesn't optimize as well as a plain pointers, no vendor has a best-in-class `std::hash` implementation (they're neither DoS-safe nor the fastest), etc.

> BTW, you will very likely have to do that in any language anyway. Because it is impossible to design fast forever-living data structure. They (almost) all become obsolete when architectures evolve.

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.

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

#180

Post by movedx » Sun, Apr 26, 2020, 4:48 AM UTC

llm wrote: post #143

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…

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 time invested to net them, then it's not the better choice.