34 ms·

> Often if I think I need an unordered map it turns out to be wrong for some subtle reason. Huh. This hasn’t been my experience. I very rarely need maps to be

> Often if I think I need an unordered map it turns out to be wrong for some subtle reason. Huh. This hasn’t been my experience. I very rarely need maps to be ordered. In recent years, the only case I can remember is when serializing to TOML and wanting the keys to be written in a specific order. There have been the occasional other case where insertion order is what I wanted, but I almost never need ordering in map keys. > I prefer this because it means I don’t have to decide whether I need an ordered map or an unordered map. I’m the opposite, I prefer to be given a choice so I can make the tradeoffs when I want to or need to. If you don’t want to choose, you are free to always choose ordered map, but even if ordered map is the default, there should always be a choice to use unordered map. It’s been very rare that I started with the wrong one and had to change. When I write python or JavaScript I typically don’t care and will just use whatever is the default, but when I write C++, I very much do care and the vast majority of cases use phmap’s flat_hash_map, which has superior space and speed over std::map and std::unordered_map. For ordered maps I use tsl::ordered_map but that still comes at a cost over flat_hash_map and its unordered variants.

zarzavat 2y ago
As a rule I’m happy to sacrifice cycles for determinism, because non-deterministic bugs are disproportionately wasteful of developer time. As much as possible I want my code to give the same results from one run to the next. Some sources of non-determinism are unavoidable, but e.g. unordered maps and unstable sorts both have deterministic alternatives that are almost as performant. Maps are such a common data structure that eliminating unordered maps has a big impact on whole program reproducibility.
- saagarjha 2y ago
  Picking a tool without thinking about it is a surefire way to get runtime bugs.
- dkersten 2y ago
  I agree with sibling commenter. If I need determinism, I choose the deterministic container. If I don’t know whether I need determinism or not, I don’t understand the problem well enough yet. Regarding wanting your code to produce the same results from one run to the next, so do I, and I get this by using appropriate data structures. If iterating a map is producing non-deterministic results then I’m doing something wrong, because that means that the order of iteration matters. It’s just that it’s not that common in my code that this is the case. Where I need specific order, more often than not, a list (array/vector) has been a more appropriate structure. Sometimes an ordered map is indeed the correct structure, but ordered map doesn’t by itself give you the determinism you desire, you also need to ensure that the insertion order is itself deterministic and consistent between runs, and that the order is maintained during processing/data manipulation between insertion time and iteration time. Typically a better approach, in my opinion, is to process the data in whatever form makes sense (eg unordered) and then when you reach a point where order matters, that’s where you sort by the order you require, rather than trying to make sure that you insert in the correct order and don’t lose that order somewhere in the process. Of course it’s valid to think about the steps and say “if I use an ordered map, this set of operations maintains the order, so I can omit the sorting” and that’s a good optimisation, but that should, in my opinion, be a conscious decision based on analysis if the problem, your solution, and your requirements.

zarzavat 2y ago

As a rule I’m happy to sacrifice cycles for determinism, because non-deterministic bugs are disproportionately wasteful of developer time. As much as possible I want my code to give the same results from one run to the next. Some sources of non-determinism are unavoidable, but e.g. unordered maps and unstable sorts both have deterministic alternatives that are almost as performant. Maps are such a common data structure that eliminating unordered maps has a big impact on whole program reproducibility.

saagarjha 2y ago
Picking a tool without thinking about it is a surefire way to get runtime bugs.
dkersten 2y ago
I agree with sibling commenter. If I need determinism, I choose the deterministic container. If I don’t know whether I need determinism or not, I don’t understand the problem well enough yet. Regarding wanting your code to produce the same results from one run to the next, so do I, and I get this by using appropriate data structures. If iterating a map is producing non-deterministic results then I’m doing something wrong, because that means that the order of iteration matters. It’s just that it’s not that common in my code that this is the case. Where I need specific order, more often than not, a list (array/vector) has been a more appropriate structure. Sometimes an ordered map is indeed the correct structure, but ordered map doesn’t by itself give you the determinism you desire, you also need to ensure that the insertion order is itself deterministic and consistent between runs, and that the order is maintained during processing/data manipulation between insertion time and iteration time. Typically a better approach, in my opinion, is to process the data in whatever form makes sense (eg unordered) and then when you reach a point where order matters, that’s where you sort by the order you require, rather than trying to make sure that you insert in the correct order and don’t lose that order somewhere in the process. Of course it’s valid to think about the steps and say “if I use an ordered map, this set of operations maintains the order, so I can omit the sorting” and that’s a good optimisation, but that should, in my opinion, be a conscious decision based on analysis if the problem, your solution, and your requirements.