undefined | Better HN

0 pointsMrBuddyCasino4y ago0 comments

> 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?

0 comments

michaelsbradley4y ago

Maybe 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/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).

MrBuddyCasinoOP4y ago

Nothing says "realistic benchmark" quite like the "-d:danger" flag.

goodpoint4y ago

It'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.

1 more reply

shirleyquirk4y ago

leaving (e.g.)runtime overflow checks turned on in the Nim code would not be a realistic comparison against C

michaelsbradley4y ago

If 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.

carlmr4y ago

Do 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.

shirleyquirk4y ago

no, -d:danger turns off runtime bounds/overflow checks, assertions, and debug info, and passes '-O3 -fno-ident' to the C compiler

1 more reply

shirleyquirk4y ago

which 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`

MrBuddyCasinoOP4y ago

I'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.

shirleyquirk4y ago

There are definitely slow bits of the Nim stdlib; json parsing for example. String-heavy code is easy to make slow in Nim, too.

1 more reply

j / k navigate · click thread line to collapse

0 comments

michaelsbradley4y ago

Maybe 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/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).

MrBuddyCasinoOP4y ago

Nothing says "realistic benchmark" quite like the "-d:danger" flag.

goodpoint4y ago

It'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.

1 more reply

shirleyquirk4y ago

leaving (e.g.)runtime overflow checks turned on in the Nim code would not be a realistic comparison against C

michaelsbradley4y ago

carlmr4y ago

Do 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.

shirleyquirk4y ago

no, -d:danger turns off runtime bounds/overflow checks, assertions, and debug info, and passes '-O3 -fno-ident' to the C compiler

1 more reply

shirleyquirk4y ago

MrBuddyCasinoOP4y ago

I'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.

shirleyquirk4y ago

There are definitely slow bits of the Nim stdlib; json parsing for example. String-heavy code is easy to make slow in Nim, too.

1 more reply

j / k navigate · click thread line to collapse