4 ms·

While I can't make a general comment, for some applications such as videogame engine development, std::unordered_map for example is not a perfectly fine class.

While I can't make a general comment, for some applications such as videogame engine development, std::unordered_map for example is not a perfectly fine class. Its linked-list-based memory layout means it is extremely CPU cache-unfriendly, making it incur an inordinately high amount of cache misses. [0] As you have a budget of 6ms per frame for 165 FPS, and you often need to iterate over many thousands of entities in each frame, std::unordered_map for one is a non-starter. In general, when discussing which language features to use, I would keep in mind that something can work well for an application that is fairly straightforward and has modest performance requirements, while being a complete no-go for a different use case. I'm not saying we should throw C++ in the bin, but I also think many people have their reasons for saying some C++ features are more trouble than they're worth. [0]: https://stackoverflow.com/questions/42588264/why-is-stdunordered-map-slow-and-can-i-use-it-more-effectively-to-alleviate-t https://stackoverflow.com/questions/42588264/why-is-stdunord... (Edited to remove the bit about std::vector, as this argument does not apply to it.)

ericbarrett 6y ago
You’re right about std::unordered_map but std::vector storage is guaranteed to be continuous[1]. [1] https://en.cppreference.com/w/cpp/container/vector https://en.cppreference.com/w/cpp/container/vector
- vladharbuz 6y ago
  You're right! I realised my mistake and edited my post in the meantime.
- ncmncm 6y ago
  unordered_map is usually fine if you keep the loading below 0.5. It is also fine if you don't care, as for example during program start-up. BTW, vector is contiguous, not continuous.
qalmakka 6y ago
Still, it's not ok to just blanket ban them. If they're not efficient enough for certain high performance areas, just don't use them there. I don't see why, for instance, they can't be used along with more efficient implementations, for instance in areas where parallelism and memory locality are not that important (for instance, for a menu or to hold settings). I feel that banning them altogether may lead people to implement stuff from scratch even when they don't need it, creating another possible source of bugs and vulnerabilities.
kllrnohj 6y ago
Sure but the argument against STL wasn't performance but rather that it can allocate at all. So optimal unordered map implementations, like Google's absl::flat_hash_map or Facebook's F14 would be similarly banned as they internally allocate. I'd definitely recommend those libraries over std::unordered_map for sure, but it's not like std::unordered_map is unusably slow or broken, either. It's fairly comparably to Java's HashMap that everyone uses without thinking about it.
- BenFrantzDale 6y ago
  You can use pmr and then do no allocation in std containers.
jcelerier 6y ago
> As you have a budget of 6ms per frame for 165 FPS, and you often need to iterate over many thousands of entities in each frame, std::unordered_map for one is a non-starter. that's when you use one of the two hundred alternative implementations which keeps the same API but offer different performance compromises & tradeoffs : https://martin.ankerl.com/2019/04/01/hashmap-benchmarks-02-01-result-CtorDtorEmptyMap/ https://martin.ankerl.com/2019/04/01/hashmap-benchmarks-02-0... If you prototyped with std::unordered_map you'll likely just have to change a couple types and add the relevant includes here and there, rerun your benchmarks, and tada.

ericbarrett 6y ago

You’re right about std::unordered_map but std::vector storage is guaranteed to be continuous[1]. [1] https://en.cppreference.com/w/cpp/container/vector https://en.cppreference.com/w/cpp/container/vector

vladharbuz 6y ago
You're right! I realised my mistake and edited my post in the meantime.
ncmncm 6y ago
unordered_map is usually fine if you keep the loading below 0.5. It is also fine if you don't care, as for example during program start-up. BTW, vector is contiguous, not continuous.

qalmakka 6y ago

Still, it's not ok to just blanket ban them. If they're not efficient enough for certain high performance areas, just don't use them there. I don't see why, for instance, they can't be used along with more efficient implementations, for instance in areas where parallelism and memory locality are not that important (for instance, for a menu or to hold settings). I feel that banning them altogether may lead people to implement stuff from scratch even when they don't need it, creating another possible source of bugs and vulnerabilities.

kllrnohj 6y ago

Sure but the argument against STL wasn't performance but rather that it can allocate at all. So optimal unordered map implementations, like Google's absl::flat_hash_map or Facebook's F14 would be similarly banned as they internally allocate. I'd definitely recommend those libraries over std::unordered_map for sure, but it's not like std::unordered_map is unusably slow or broken, either. It's fairly comparably to Java's HashMap that everyone uses without thinking about it.

BenFrantzDale 6y ago
You can use pmr and then do no allocation in std containers.

jcelerier 6y ago

> As you have a budget of 6ms per frame for 165 FPS, and you often need to iterate over many thousands of entities in each frame, std::unordered_map for one is a non-starter. that's when you use one of the two hundred alternative implementations which keeps the same API but offer different performance compromises & tradeoffs : https://martin.ankerl.com/2019/04/01/hashmap-benchmarks-02-01-result-CtorDtorEmptyMap/ https://martin.ankerl.com/2019/04/01/hashmap-benchmarks-02-0... If you prototyped with std::unordered_map you'll likely just have to change a couple types and add the relevant includes here and there, rerun your benchmarks, and tada.