>Then of course I remembered that std::map is a red-black tree, i.e. ordered, whereas the Go map is not. Change out std::map for std::unordered_map and C++ pulled ahead, 20% faster than the Go code.
Even that's surprising, since std::unordered_map is notoriously slow (and impossible to optimize given weirdly exposed implementation details in it's API)
And Java is 2x faster than golang in this benchmark when I ran it. Many benchmarks are to be taken with a grain of salt.
golang:
7.76 real 8.67 user 0.08 sys
Java:
3.74 real 3.58 user 0.46 sys
public class Test {
public static void main(String[] args) {
final int numOfStrings = 100_000;
final int numIters = 1_000;
var numStrings = new String[numOfStrings];
for (int i = 0; i < numStrings.length; i++) {
numStrings[i] = Integer.toString(i);
}
for (int i = 0; i < numIters; i++) {
var strToInt = new java.util.HashMap<String, Integer>(numOfStrings);
for (final var s : numStrings) {
strToInt.put(s, s.length());
}
}
}
}
What's happening is that the std::unordered_map was a mistake. Many parts of it's API prevent implementing it efficiently (For example, every insertion requires allocation, even if you reserve). It's widely regarded, within and outside the standards committee, as a very unfortunate mistake.
swisstable (absl::flat_hash_map) is a popular choice right now for the hash table to use for C++ code that cares about performance. There are other choices as well (dense_hash_map, F14FastMap, etc), But honestly most choices these days are worse than std::unordered_map (well, boost::unordered_map is probably just as bad, since std's implementation was taken wholesale from boost without any thought!)
You aren't reading it correctly. The OP was saying it's not fair unless you compare against an unordered map. The update is referring to an ordered map which is much slower than an unordered. The GO math implementation, which is an unordered map, is still significantly slower than the C++ unordered map.
>Then of course I remembered that std::map is a red-black tree, i.e. ordered, whereas the Go map is not. Change out std::map for std::unordered_map and C++ pulled ahead, 20% faster than the Go code.