3 ms·
> I was expecting with Nim effectively compiling to C as an intermediary. C has nothing to do with performance, runtimes and libraries do. Nim has runtime over
by MisterTea 5y ago
> I was expecting with Nim effectively compiling to C as an intermediary.
C has nothing to do with performance, runtimes and libraries do. Nim has runtime overhead whereas C and Rust do not.
- samwillis 5y agoQuite true, although my (possibly naive) assumption was that with it being a statically typed language and these being "simple" algorithmic benchmarks the gap would be closer. Not expecting it to match Rust or C in performance, just surprised at the size of the gap. Would be interesting to see what the generated C is like from the Nim code.
- MisterTea 5y ago> Would be interesting to see what the generated C is like from the Nim code. Just did a few quick tests. A hello world in nim is a one liner: echo "hello world" It compiles to a 102136 byte binary on Linux. A hello world c program consisting of a single printf is 16696 bytes.
- shirleyquirk 5y agohttps://hookrace.net/blog/nim-binary-size/ https://hookrace.net/blog/nim-binary-size/ gets hello world to parity(17k) with `-d:release --opt:size` and `strip`, and then shows how to get that down to 150 bytes.
- xigoi 5y agoDid you compile it in release mode?
- arc619 5y ago...both Rust and C have runtimes: https://blog.mgattozzi.dev/rusts-runtime/ https://blog.mgattozzi.dev/rusts-runtime/
- mratsim 5y agoThe runtime overhead is type-specific. If you don't use automatically managed types like seq/string and ref, there is no GC underneath. And even then, the GC is just reference counting so no difference from Rust Rc/Arc.