Re:Comparison of C++17, Go, and Java for a next-generation s...
by ezoe on Thursday April 23, 2020 @06:37PM
(#22962369)
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. Especially so if the data type is trivial so the simple byte by byte memcpy is suffice.
[ Parent
| on HN ]
Re:Comparison of C++17, Go, and Java for a next-generation s...
by gpderetta on Thursday April 23, 2020 @06:49PM
(#22962471)
> contagious
normally I wouldn't point out an obvious autocorrect mistake, but this is really season-appropriate (or, better, inappropriate) :).
Re:Comparison of C++17, Go, and Java for a next-generation s...
by ezoe on Thursday April 23, 2020 @07:27PM
(#22962827)
Oh that's... not intended really.
Re:Comparison of C++17, Go, and Java for a next-generation s...
by TwoBit on Friday April 24, 2020 @01:14AM
(#22964872)
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 s...
by josefx on Friday April 24, 2020 @02:19AM
(#22965209)
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?