How to work with hashmap from memutils properly?

[Siarhei Siamashka]

On Friday, 11 February 2022 at 19:04:41 UTC, Sergey wrote:
>> Is this an attempt to implement a high performance solution 
>> for the Benchmarks Game's LRU problem in D language?
>
> Yes. There is no D version there. And I'm just curious how fast 
> is D in those problems.

Dlang (LDC), Crystal, Rust and C++ (Clang) all can generate 
equally fast code. That's because they are using the same LLVM 
backend for generating code. If you encounter a significant 
performance difference, then there has to be a good reason for 
that. And figuring out what exactly causes this difference allows 
to fix the under-performing code in most cases.

A better question is how much effort is required to reach _peak_ 
performance using each of these programming languages? Or how 
much effort is required to reach _good enough_ performance?

Let's look at the benchmark results from that site:
* https://programming-language-benchmarks.vercel.app/d-vs-rust
* 
https://programming-language-benchmarks.vercel.app/crystal-vs-rust
* https://programming-language-benchmarks.vercel.app/d-vs-crystal

It may seem like Rust is kinda winning there. But is it a faster 
language? Or did some people just invest a lot of their time into 
creating better Rust code for these benchmarks? This time is not 
tracked and not compared for different languages, while it's 
probably the most important metric.

My personal opinion is that both Dlang and Crystal primarily 
focus on developer convenience and rapid development. Rust 
focuses on extreme safety at the expense of developer 
convenience. C++ is neither safe nor convenient, but at least 
it's fast and has excellent backward compatibility with the old 
code.

Does it make sense to spend time on improving D code on that 
benchmark site and reach performance parity with the other 
languages? I don't know.

> It is interesting finding about the size of the LRU. Already 
> seen your comment in the benchmark github.

Yes, I took a look and their initial implementation of the LRU 
benchmark for Crystal was initially written by somebody, who is 
apparently not very fluent with the language. This was difficult 
for me to ignore, so I had an impulse to fix it and this 
escalated into a kind of Rust vs. Crystal performance duel.

Now the size of the LRU cache has been changed to something more 
reasonable in that benchmark and hash tables are back in the game 
:-) You can try to contribute your D code to this benchmark site 
and then work on making it faster.

> Though version with memutils still not working :)

Do you suspect that it's a bug in 
https://github.com/etcimon/memutils ? I never heard about this 
library before. But associative arrays are important enough and 
it's reasonable to expect a decent implementation in the standard 
library without having to use some third-party magic sauce for 
that.