When elements are inserted one after another in a HashSet, newly allocated HashMap.Entry are allocated sequentially (in a TLAB), but end up being stored at random positions in the HashMap’s array. HashSet’s (= HashMap’s) iteration goes over the array sequentially, but it means jumping over HashMap.Entries, allocated at random positions in TLAB.
System.gc() may actually fix that, read the Alexey Shipilev’s post for details.
LinkedHashMap links the entries in the allocation order, and iterates in the same order, it means that it scans TLAB memory sequentially.
Degradation is observed when a “recreated” set is iterated, as far as I can see. Possible reason might be that GC scans arrays in decreasing order (I don’t know and don’t assert that!), So GC might put objects in not very favourable order again.
Anyway, it’s all just assumtions. Both of your benchmark results might be completely misleading, affected by some bugs or contribution factors that we didn’t consider yet. Only study of perfasm with cycle as well as cache miss counts could help to answer those questions for sure.
Fastutil has additional implementations.
In particular, a hash set without chaining, but open addressing.
Can you include these in your benchmark? It would be interesting to see the differences even without the primitive specializations that make fastutil attractive.
JavaScript only preserves insertion order for non-numeric properties. The actual iteration order is:
Numeric properties in ascending order.
String properties in insertion order.
Symbols.
ES 3 however described objects as “unordered”. A few years ago Firefox used insertion order for all properties and V8 browsers the current behavior. It seems ES6 finally established the iteration rules as it was causing quite a few bugs. http://2ality.com/2015/10/property-traversal-order-es6.html
HashSet jumps over the memory randomly. Locality could be a big contribution factor. See https://shipilev.net/jvm-anatomy-park/11-moving-gc-locality/
It would be interesting to see how do benchmark results change if
System.gc()is called right before the iteration.HashSet jumps over the memory randomly.
Can you elaborate?
When elements are inserted one after another in a HashSet, newly allocated HashMap.Entry are allocated sequentially (in a TLAB), but end up being stored at random positions in the HashMap’s array. HashSet’s (= HashMap’s) iteration goes over the array sequentially, but it means jumping over HashMap.Entries, allocated at random positions in TLAB.
System.gc() may actually fix that, read the Alexey Shipilev’s post for details.
LinkedHashMap links the entries in the allocation order, and iterates in the same order, it means that it scans TLAB memory sequentially.
I modified my code so that I call gc after creating the sets. It seems to only have a small effect. Calling the gc can even have a negative effect.
I tried recreating a new hash set from the previous hash set in the hope that the data would be allocated in the right order…
No luck:
See https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/blob/master/2018/03/13/src/main/java/me/lemire/microbenchmarks/hash/OrderHash.java
Degradation is observed when a “recreated” set is iterated, as far as I can see. Possible reason might be that GC scans arrays in decreasing order (I don’t know and don’t assert that!), So GC might put objects in not very favourable order again.
Anyway, it’s all just assumtions. Both of your benchmark results might be completely misleading, affected by some bugs or contribution factors that we didn’t consider yet. Only study of perfasm with cycle as well as cache miss counts could help to answer those questions for sure.
That’s work for me by the way 😀
Fastutil has additional implementations.
In particular, a hash set without chaining, but open addressing.
Can you include these in your benchmark? It would be interesting to see the differences even without the primitive specializations that make fastutil attractive.
Pull Requests invited!
JavaScript only preserves insertion order for non-numeric properties. The actual iteration order is:
Numeric properties in ascending order.
String properties in insertion order.
Symbols.
ES 3 however described objects as “unordered”. A few years ago Firefox used insertion order for all properties and V8 browsers the current behavior. It seems ES6 finally established the iteration rules as it was causing quite a few bugs. http://2ality.com/2015/10/property-traversal-order-es6.html
JavaScript only preserves insertion order for non-numeric properties. (…) Numeric properties in ascending order.
Can you please type this in your favorite JavaScript console:
(Update: I had pasted Swift code initially.)
I executed test on my pc and it show the following results
Benchmark (gc) Mode Cnt Score Error Units
collectionUtils.OrderHash.scanHashSet false thrpt 5 39,380 ± 1,357 ops/s
collectionUtils.OrderHash.scanHashSet true thrpt 5 38,749 ± 0,897 ops/s
collectionUtils.OrderHash.scanHashSet2 false thrpt 5 55,521 ± 15,549 ops/s
collectionUtils.OrderHash.scanHashSet2 true thrpt 5 64,839 ± 3,105 ops/s
collectionUtils.OrderHash.scanLinkedHashSet false thrpt 5 141,776 ± 23,246 ops/s
collectionUtils.OrderHash.scanLinkedHashSet true thrpt 5 143,821 ± 1,604 ops/s
why is that scanHashSet2 is almost twice as fast as scanHashSet?
it depends on the way it was filled?