Niall’s virtual diary archives – Thursday 17th July 2014

Thursday 17th July 2014: 7.22pm. Spent the last few weeks after work trying to write a concurrent_unordered_map which has safe erase and uses memory transactions. It's my fourth design iteration, and I've currently achieved a 2x insert/remove and a 9x find performance improvement over a spinlocked unordered_map on a 4 core Xeon. I tried turning on HLE for the spinlocks, and here's the weirdness:

Standard spinlocks:

=== Large unordered_map spinlock write performance ===
1. Achieved 13633747.046081 transactions per second
2. Achieved 13544875.833816 transactions per second
3. Achieved 13742823.204185 transactions per second

=== Large unordered_map spinlock read performance ===
1. Achieved 16797278.905991 transactions per second
2. Achieved 16649920.152696 transactions per second
3. Achieved 16447595.444534 transactions per second

With HLE:

=== Large unordered_map spinlock write performance ===
1. Achieved 7946766.102310 transactions per second
2. Achieved 7920644.458001 transactions per second
3. Achieved 7916474.781090 transactions per second

=== Large unordered_map spinlock read performance ===
1. Achieved 139226652.263855 transactions per second
2. Achieved 140339336.375345 transactions per second
3. Achieved 138829586.722212 transactions per second

Which is a 1.7x regression for writes, and a 1.2x regression for reads. The write regression is expected, after all it has to abort, but the read regression is an absolute surprise as no writes should be happening, so the lock should elide. I suppose with eight threads all running transactions we might actually be running out of resources or something ... still weird though.