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

Re:Comparison of C++17, Go, and Java for a next-generation s... by benibela on Thursday April 23, 2020 @06:40PM (#22962397)

>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% faster than the fastest map in the FreePascal standard library. And the best map of 45 Pascal maps is only 30% faster than std::unordered_map. Only 10 maps are faster, and 35 maps are slower.

[ Parent | on HN ]

Re:Comparison of C++17, Go, and Java for a next-generation s... by alexhutcheson on Thursday April 23, 2020 @10:03PM (#22963896)

Try absl::flat_hash_map and/or F14FastMap[2].

[1] https://abseil.io/docs/cpp/guides/container#hash-tables

[2] https://github.com/facebook/folly/blob/master/folly/containe...

[ Parent | on HN ]

Re:Comparison of C++17, Go, and Java for a next-generation s... by saagarjha on Thursday April 23, 2020 @06:50PM (#22962481)

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.

[ Parent | on HN ]

Re:Comparison of C++17, Go, and Java for a next-generation s... by TwoBit on Friday April 24, 2020 @01:19AM (#22964902)

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.

[ Parent | on HN ]

Re:Comparison of C++17, Go, and Java for a next-generation s... by IshKebab on Friday April 24, 2020 @04:23AM (#22965790)

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

[ Parent | on HN ]

Re:Comparison of C++17, Go, and Java for a next-generation s... by gpderetta on Thursday April 23, 2020 @06:48PM (#22962452)

Depends what you do. If you populate it only once and then you do a bunch of lookups, assuming a low load factor, you'll be paying for a modulo operation and an extra indirection, not great but not terrible either. If you do a lot of inserts and removal or your load factor is high, then the performance is going to be not great.

[ Parent | on HN ]

Re:Comparison of C++17, Go, and Java for a next-generation s... by benibela on Friday April 24, 2020 @07:06AM (#22966726)

My benchmark is one insert, multiple lookups, repeat.

I have no use for deletions. Although when I want to make a general benchmark, I probably should measure it once, too

[ Parent | on HN ]

Re:Comparison of C++17, Go, and Java for a next-generation s... by FpUser on Thursday April 23, 2020 @08:58PM (#22963498)

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

[ Parent | on HN ]

Re:Comparison of C++17, Go, and Java for a next-generation s... by benibela on Friday April 24, 2020 @06:15AM (#22966445)

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.

[ Parent | on HN ]

Re:Comparison of C++17, Go, and Java for a next-generation s... by FpUser on Friday April 24, 2020 @06:01PM (#22973375)

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.

[ Parent | on HN ]