On Tuesday, 26 June 2018 at 02:53:22 UTC, Nathan S. wrote:
With LDC2 the times for vibe.utils.hashmap and memutils.hashmap
are suspiciously low, leading me to suspect that the optimizer
might be omitting most of the work. Here are the figures
without optimizations enabled.
== Speed Ranking using DMD (no optimizations) ==
95 msecs built-in AA
168 msecs vibe.utils.hashmap
182 msecs jive.map
224 msecs memutils.hashmap
663 msecs containers.hashmap w/GCAllocator
686 msecs containers.hashmap w/Mallocator
== Speed Ranking using LDC2 (no optimizations) ==
68 msecs built-in AA
143 msecs vibe.utils.hashmap
155 msecs jive.map
164 msecs memutils.hashmap
515 msecs containers.hashmap w/GCAllocator
537 msecs containers.hashmap w/Mallocator
Did you by chance also benchmark it with other languages like
C++, Go or Rust?
BTW I'm not sure what your plans are, but are you aware of this
recent article?
https://probablydance.com/2018/05/28/a-new-fast-hash-table-in-response-to-googles-new-fast-hash-table
There were also plans to lower the AA implementation entirely
into D runtime/user space, s.t. specialization can be done
easier, but sadly these plans stagnated so far:
https://github.com/dlang/druntime/pull/1282
https://github.com/dlang/druntime/pull/1985
