On Tuesday, 26 June 2018 at 03:45:27 UTC, Seb wrote:
Did you by chance also benchmark it with other languages like
C++, Go or Rust?
= Not reusing hashtables, optimizations enabled =
79 msecs Rust std::collections::HashMap
90 msecs Go built-in map
177 msecs C++ std::unordered_map (whichever
On Tuesday, 26 June 2018 at 14:33:25 UTC, Eugene Wissner wrote:
Tanya hashes any value, also integral types; other hashtables
probably not.
Your intuition is correct here. Most of the tables use
`typeid(key).getHash()`, which for `int` just returns `key`.
= Built-in AA =
General case:
On Tuesday, 26 June 2018 at 09:03:10 UTC, Eugene Wissner wrote:
It seems it doesn't work with a branch in dub.sdl. I just
replaced the files in ~/.dub/packages.
And to make tanya perform better than built-in AAs in the first
test, define a hash function:
size_t hasher(int e)
{
return e;
BTW the output is formatted so you can get a sorted list of times
across all trials by piping the output through `sort -n`. That's
also why the tests reusing maps start with ( instead of [, so
they will be grouped separately.
It seems it doesn't work with a branch in dub.sdl. I just
replaced the files in ~/.dub/packages.
On Tuesday, 26 June 2018 at 04:17:44 UTC, Nathan S. wrote:
On Tuesday, 26 June 2018 at 03:45:27 UTC, Seb wrote:
Did you by chance also benchmark it with other languages like
C++, Go or Rust?
I didn't since I was evaluating hashtable implementations for
use in a D application.
BTW I'm not
On Tuesday, 26 June 2018 at 03:45:27 UTC, Seb wrote:
Did you by chance also benchmark it with other languages like
C++, Go or Rust?
I didn't since I was evaluating hashtable implementations for use
in a D application.
BTW I'm not sure what your plans are, but are you aware of this
recent
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
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
Benchmark code:
dub.sdl
```
name "hashbench"
description "D hashtable comparison."
dependency "emsi_containers" version="~>0.7.0"
dependency "memutils" version="~>0.4.11"
dependency "vibe-d:utils" version="~>0.8.4"
dependency "jive" version="~>0.2.0"
//dependency "collections" version="~>0.1.0"
10 matches
Mail list logo
