3 ms·

I think so, but I think the performance gap is a little larger than I was expecting with Nim effectively compiling to C as an intermediary. https://programming

• 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 ago
    Quite 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 ago
        https://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 ago
        Did 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 ago
    The 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.
• cogman10 5y ago
  C is an easy intermediary, C is a bad intermediary. The issue with targeting C is you ended up losing a lot of information about intent. Compilers looking at C have to put a lot of trust that what the programmer wrote was intentional (and thus, unoptimizable). Rust and C both end up faster than Nim because they are talking directly to the compiler. IDK enough about Nim to say if it could hit Rust/C speeds if it targeted the LLVM instead, but it would be a lot faster than it currently is targeting C.
  • masklinn 5y ago
    > C is an easy intermediary, C is a bad intermediary. > The issue with targeting C is you ended up losing a lot of information about intent. Compilers looking at C have to put a lot of trust that what the programmer wrote was intentional (and thus, unoptimizable). The same issue exists in C-sourced compiler backends, which is both GCC and LLVM. It’s not exactly a secret that anything which is not strongly exercised by standard C(++) codebases tends to be rather broken for any non-trivial use and takes years to fix (restrict/noalias being the poster child for this, at least in the context of Rust, I think it hasn’t gotten re-disabled yet so it might make a year).
    • cogman10 5y ago
      I think that has less to do with LLVM/GCC being C(++) implementations and more to do with the fact that the primary language compiled by these compilers is C and C++. Other languages that target these compilers aren't used nearly to the same level (maybe swift now?). The JVM, for example, doesn't see the same issue so much with non-Java languages. Mainly because (IMO) it's been hosting non-java languages for several years now.