matrixmultiply VS Programming-Language-Benchmark

The matrixmultiply crate from the ndarray author (https://github.com/bluss/matrixmultiply) is one such implementation. It uses the same algorithm as the BLIS project (https://www.cs.utexas.edu/users/flame/pubs/TOMS-BLIS-Analytical.pdf) to partition the problem and exploit the cache hierarchy. It isn't as well tuned as eg. Intel MKL or BLIS, but the results are very respectable.

Do you plan to support integers as native types? I know there is an issue for the crate matrixmultiply for that, it seems it can be problematic because of overflow.

There's a famous crate [matrixmultiply](https://github.com/bluss/matrixmultiply) for matrix-matrix multiplication in Rust. But it's a bit slow for me.

In my benchmarks, Nim is faster than Rust:

- multithreading runtime (i.e Rayon vs Weave https://github.com/mratsim/weave)

- Cryptography: https://hackmd.io/@gnark/eccbench#Pairing

- Scientific computing / matrix multiplication: https://github.com/bluss/matrixmultiply/issues/34#issuecomme...

There is no inherent reason why a Nim program would be slower than Rust.

I found Zig implementation of json parsing is interesting. The code is free from hidden control flow !.

https://github.com/hanabi1224/Programming-Language-Benchmark...

It appears helloworld is the only test with any repeats, and it only has 5 repeats. https://github.com/hanabi1224/Programming-Language-Benchmark...

Here's the measurement code, it appears to be significantly more complicated than a simple fork/exec/wait loop but that could just be all the C# getting in the way: https://github.com/hanabi1224/Programming-Language-Benchmark... Nevertheless you are probably right that the bulk of this 1.8ms is in the executable under test, and it truly is just bloat. Running `hyperfine ./empty-main-function` from rustc on my Mac gives 0.8ms.

Is faster... on code that has been optimized to hell and back 5 times over and no longer resembles anything like normal code written in the language.

Seriously, this is the code for the top program. I'm reasonably sure 99% of C++ programmers could not decipher it without spending significant amounts of time on google: https://github.com/hanabi1224/Programming-Language-Benchmark...

I appreciate that fair benchmarks across languages are a hard problem, but this is not a good solution to it. Any reference to this data as a comparison between "programming languages and compilers" needs to come with a giant disclaimer that it's comparing them at something you almost certainly don't use them for, and is very far from their main use case.

I also appreciate that this is a repetitive comment the likes of which always come up when this benchmark is mentioned... but I really don't see another way to avoid people misinterpreting it. Very few people are going to spontaneously click through to the code.