NIM
https://programming-language-benchmarks.vercel.app/problem/helloworld
Now in all seriousness, looking around the benchmarks on the page, once can see Nim performs quite well all around, and by well I mean fast & with low memory usage; not to mention often times with far less code than the alternatives. So, congrats!
The numbers on that page seem sloppy, incomplete, and probably misleading - at least for Nim, but probably for more. It seems like this is honestly more of a libc/OS benchmark than a PL one. E.g.: ....
E.g., using tim out of bu, just copy-pasting that program and compiling with glibc and musl on Linux on a 2016 vintage i7-6700k (Gentoo Linux, a 6.5 kernel, glibc-2.38, etc.) as root (for chrt):
chrt 99 taskset 0xE env -i /usr/local/bin/tim -n100 '' './helloGLIBC>/dev/null' './helloMUSL>/dev/null'
(2.1298 +- 0.0041)e-04
(5.633 +- 0.068)e-04 ./helloGLIBC>/dev/null
(2.830 +- 0.086)e-04 ./helloMUSL>/dev/null
Then using @Vindaar's Measuremancer and a little wrapper program I alias to *a*, we can subtract off the overhead..
$ a (5.633 +- 0.068)-(2.1298 +- 0.0041)
3.503 +- 0.068
$ a (2.830 +- 0.086)-(2.1298 +- 0.0041)
0.700 +- 0.086
Since that is ()*1e-4, that means it's about 70 +- 9 microseconds, not 1200 microseconds. My machine may be faster than their test server, but there is no way it is anything like 17X faster. I also got a manual time of 66 usec out of bu/ru and it said 1.5 MB memory, not 1.0, though there are many ways to define/measure memory use (RSS, PSS, etc.).
And notice that GLIBC takes a whopping (3.503 +- 0.068)/(0.700 +- 0.086) = (5.00 +- 0.62)X more time than MUSL. So, that's why it's mostly a libc measurement.
Further that page has clang-compiled taking 2.9 ms while "presumably gcc-compiled" taking 1.2 ms which is a kind of bonkers 2.5X difference that makes me suspect the explicitly clang built binary came from different/weaker nim &| C compiler options. Although it could also have to do with the clang variant reporting 2.9 +- 2.0 ms which is kinda stupid inaccurate (see bu/doc/tim.md for more details).
That said, it's nice these bench hosters are covering Nim as the Debian/formerly Alioth guys seem to decline for whatever reasons.
If someone wants to be coached into learning low-level cryptography to smoke the secp256k1 benchmark with Constantine (https://github.com/mratsim/constantine), there's quite a few things that can be done, and you start with a good baseline and comprehensive tests:
For 2000 inputs, the fastest in Rust takes 147ms on their 2.8GHz Xeon Platinum hence 73500ns
Constantine generic baseline takes 48315ns on my i9-11980HK @ 2.60GHz (Turbo 5GHz).
Here are the following optimizations that can be added on top:
I've outlined 8 steps to be unbeatable speedwise on secp256k1 benchmark, a conservative expected speedup would be 2x over Rust implementation (current top) but I wouldn't be surprised by a 3x.
The benchmarks might be quite imperfect, sure, but we've got at least some guiding elements.
Plus, in the case of someone who's never heard of Nim before, stumbling upon it while looking at the top of those rankings is good marketing.