3 ms·

So I created a Gist: https://gist.github.com/AshKash/ebf1f70949e76439d6ffed9ccde337be https://gist.github.com/AshKash/ebf1f70949e76439d6ffed9ccde3... upped it

So I created a Gist: https://gist.github.com/AshKash/ebf1f70949e76439d6ffed9ccde337be https://gist.github.com/AshKash/ebf1f70949e76439d6ffed9ccde3... upped it to 10M ops and used .reserve to avoid unwanted allocs. Go 1.12 is 2X faster than C++. This was totally unexpected as I feel the basic algorithms are simple and there is not much you can do to make it faster. If you have know what is going on, please share.

apta 8y ago
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()); } } } }
yoklov 8y ago
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!)

apta 8y ago

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()); } } } }

yoklov 8y ago

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!)