Jon Gjengset

This looks great, and is a good idea. I'd love to have @xacrimon's input on this too. I don't think having the benchmarker be nightly-only is a problem.

Ah, you mean if we start listing concurrent maps in the README on this repo? Yes, I agree that that should probably be noted!

That's really interesting — do you have plots anywhere (throughput on y, #cpus on x)? Are you using a `git` dependency? And crucially, are you re-using guards/`HashMapRef`s, or are you...

@domenicquirl ^

My guess is that we (for some reason) generate significantly more garbage than contrie. That _shouldn't_ be the case, and I don't think there's a fundamental reason why we would,...

When you say "as fast", what are you measuring? I am more interested in the scaling as the number of threads go up than the performance at lower core counts....

Interesting.. I mean, it could be that Java's `ConcurrentHashMap` just doesn't scale that well :p In some sense, that was part of what I wanted to find out by porting...

Yeah, that certainly looks a lot like we're generating some unnecessary garbage that ends up hampering scalability. It _also_ suggests that crossbeam-epoch does not handle large amounts of garbage produced...

Interesting, what assert is erroneous? The code is pretty closely modeled after the libcuckoo benchmark, including the asserts. I'm not sure I follow why you would need to prefill differently...

That assert should definitely be correct as long as the assumption that the keys are distinct as the documentation specifies. The whole benchmark relies on that assumption. The default prefill...