4 ms·
> performance like Rust I've just looked at some benchmarks, and even though Nim claims C-like performance, that never seems to be confirmed by independent tes
by MrBuddyCasino 5y ago
> performance like Rust
I've just looked at some benchmarks, and even though Nim claims C-like performance, that never seems to be confirmed by independent tests. It is usually a bit behind C / C++ / Rust / Crystal, and roughly on-par with Golang.
Fast enough for sure, but "half the speed of C" would be more honest it seems?
- michaelsbradley 5y agoMaybe so, but sometimes benchmarkers forget to employ compiler options like: nim c -d:danger -d:lto --opt:speed ymmv https://nim-lang.org/faq.html https://nim-lang.org/faq.html https://nim-lang.org/docs/nimc.html https://nim-lang.org/docs/nimc.html Also, --gc:arc and --gc:orc are going to bring a stronger game to the table as they continue to mature (already pretty far along).
- carlmr 5y agoDo these activate -funsafe-math on the underlying C compiler? Because if so that's not a fair comparison, since this breaks a lot of code.
- shirleyquirk 5y agono, -d:danger turns off runtime bounds/overflow checks, assertions, and debug info, and passes '-O3 -fno-ident' to the C compiler
- carlmr 5y agoAh ok, that's fair then.
- MrBuddyCasino 5y agoNothing says "realistic benchmark" quite like the "-d:danger" flag.
- michaelsbradley 5y agoIf you're going into production with Nim code and execution speed is a top concern, you're probably going to remove all the safety belts after thoroughly testing, valgrind'ing, etc., i.e. you're probably going to opt for -d:danger instead of -d:release. But maybe not, depends on the project I guess.
- goodpoint 5y agoIt's the normal compilation flag for performant code. The word "danger" is scary, but it's simply disabling debugging code: debug assertions, full stacktraces, extra safety checks.
- MrBuddyCasino 5y agoI suppose the makers of Nim named that flag for a reason - giving up memory safety by disabling bounds/overflow checks should be never be the default for networked software in a production setting, so benchmarking in that mode would paint an unrealistic picture. What you want are comparable compiler flags across languages, say "optimized for performance, yet retaining safety" and "go as fast as possible and disable all brakes". Which, to be fair, is the default for C anyway, but this is not a desirable default. I'm sure you can similarly game Rust bechmarks by using "unsafe".
- dom96 5y agoI'm sure Rust also has a way to disable bounds/overflow checks for speed. Do benchmarks utilise it?
- formerly_proven 5y agoRust should be able to elide more checks than most other languages without impacting safety.
- dom96 5y agoThat's the assumption, but that doesn't mean it's the case. Certainly bounds checks are impossible to prove at compile-time.
- shirleyquirk 5y agowhich benchmarks? I play the language benchmark game sometimes and I can always get within 10% of the fastest contender. Beating the fastest contender,though, is rarely possible without using the unsafe subset of Nim, hence `-d:danger`
- MrBuddyCasino 5y agoI've digged some more, and indeed in numeric tests Nim is often close to C. Its hard to find good data though, with documented compiler flags and recent versions.
- shirleyquirk 5y agoThere are definitely slow bits of the Nim stdlib; json parsing for example. String-heavy code is easy to make slow in Nim, too.
- MrBuddyCasino 5y agoYes the benchmark against Crystal was heavy on strings (json & base64) and Crystal seems to do better there. Whats the reason, Nim using refcounting?