4 ms·

I love nim, but I disagree with the "quick compilation" point here. The compilation is horrendously slow. (by default it compiles down to C, then to exe from th

I love nim, but I disagree with the "quick compilation" point here. The compilation is horrendously slow. (by default it compiles down to C, then to exe from there).

boongeheYOE 4y ago
In comparison to languages like Rust and C++ it compiles pretty fast. Or maybe you built the compiler in debug mode.
nimmer 4y ago
It's much faster than C++, Rust, Go and many others.
- hahaitsfunny 4y ago
  No, it is not - Nim's compiler backend is extremely complex and full of cruft. I've been around Nim for 7+ years now and there's a reason the compiler was hard forked. Nim's compiler is definitely not speedy, and this is why so much effort has been spent on incremental compilation, which tmk, still isn't working - https://github.com/nim-lang/Nim/issues/19757 https://github.com/nim-lang/Nim/issues/19757.
- zimpenfish 4y ago
  I'm assuming this must be for huge projects? I just compiled my toy project (detecting anomalous parity in integers) in nim 1.6.6 (4.23s), go 1.17.7 (2.43s to create both aarch64 and x86_64 binaries), zig 0.8.0-dev.1140 (2.04s to create aarch64 and x86_64 binaries) and C via clang 13.1.6 (0.14s). nim's compilation is 175% of Go, 207% of zig, and 3021% of clang.
  - Rochus 4y ago
    Thanks for the data; that's what I call an elegant rebuttal.
  - nimmer 4y ago
    No, even small files. You must have issues with your setup. Are you sure your compiler is not built in debug mode?
    - zimpenfish 4y ago
      How would I check that? I installed it through homebrew via https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/nim.rb https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/... which doesn't seem to mention debug mode anywhere?
      - dom96 4y ago
        Run `nim -v`, if it's not in debug mode you should see "active boot switches: -d:release".
        zimpenfish 4y ago
        Looks like it isn't in debug mode after all. $ nim -v Nim Compiler Version 1.6.6 [MacOSX: arm64] Compiled at 2022-05-05 Copyright (c) 2006-2021 by Andreas Rumpf active boot switches: -d:release -d:nimUseLinenoise
  - machinekob 4y ago
    how are u compiling (optimization, custom compilation flags etc.?) In my case https://github.com/mratsim/Arraymancer https://github.com/mratsim/Arraymancer big project compile under your 4.2s so or you have like 10k+ lines of codes with macros or you just pass some debug flags to compiler :D
    - zimpenfish 4y ago
      Compilation command is: nim c -d:release --passC:"-flto" --gc:markAndSweep --out:ap ap.nim I will add that once it's been run a few times, it does go a bit quicker (down to ~0.7s) but the Go also gets quicker (down to 0.28s for two outputs when files are cached.)
cb321 4y ago
As with most things, "it depends". If you compile very macro compile-time virtual-machine heavy code that can be slow. If you compile to the c++ backend then that backend process can be slow. If you invoke some macro that generates mountains of Nim code translated to continents of C code it can be slow. If you use the default `nim.cfg` that has gcc -Og it can take a lot longer than gcc -O0, for example. Meanwhile, if you use the `tcc` backend even without incremental compilation it can be close to immediate feedback: $ touch foo.nim $ /usr/bin/time nim c foo.nim CC: ../usr/lib/nim/lib/std/private/digitsutils.nim CC: ../usr/lib/nim/lib/system/dollars.nim CC: ../usr/lib/nim/lib/system.nim CC: foo.nim Hint: gc: refc; opt: none (DEBUG BUILD, `-d:release` generates faster code) 36891 lines; 0.154s; 39.434MiB peakmem; proj: /tmp/foo.nim; out: /tmp/foo [SuccessX] 0.24user 0.02system 0:00.27elapsed 101%CPU (0avgtext+0avgdata 44360maxresident)k 0inputs+0outputs (0major+13676minor)pagefaults 0swaps (I point my default backend compiler to tcc in my $HOME/.config/nim/nim.cfg.) There are some more details in this nim forum thread: https://forum.nim-lang.org/t/8677 https://forum.nim-lang.org/t/8677 Unless your standards are "single digit milliseconds per file like tcc itself, please!", 240 ms is not so bad. (EDIT: And this is just on some 2016-era Intel i7-6700k box, not some liquid helium cooled 10 GHz whatever.)

I love nim, but I disagree with the "quick compilation" point here. The compilation is horrendously slow. (by default it compiles down to C, then to exe from there).

boongeheYOE 4y ago

In comparison to languages like Rust and C++ it compiles pretty fast. Or maybe you built the compiler in debug mode.

nimmer 4y ago

It's much faster than C++, Rust, Go and many others.

hahaitsfunny 4y ago
No, it is not - Nim's compiler backend is extremely complex and full of cruft. I've been around Nim for 7+ years now and there's a reason the compiler was hard forked. Nim's compiler is definitely not speedy, and this is why so much effort has been spent on incremental compilation, which tmk, still isn't working - https://github.com/nim-lang/Nim/issues/19757 https://github.com/nim-lang/Nim/issues/19757.
zimpenfish 4y ago
I'm assuming this must be for huge projects? I just compiled my toy project (detecting anomalous parity in integers) in nim 1.6.6 (4.23s), go 1.17.7 (2.43s to create both aarch64 and x86_64 binaries), zig 0.8.0-dev.1140 (2.04s to create aarch64 and x86_64 binaries) and C via clang 13.1.6 (0.14s). nim's compilation is 175% of Go, 207% of zig, and 3021% of clang.
- Rochus 4y ago
  Thanks for the data; that's what I call an elegant rebuttal.
- nimmer 4y ago
  No, even small files. You must have issues with your setup. Are you sure your compiler is not built in debug mode?
  - zimpenfish 4y ago
    How would I check that? I installed it through homebrew via https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/nim.rb https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/... which doesn't seem to mention debug mode anywhere?
    - dom96 4y ago
      Run `nim -v`, if it's not in debug mode you should see "active boot switches: -d:release".
      - zimpenfish 4y ago
        Looks like it isn't in debug mode after all. $ nim -v Nim Compiler Version 1.6.6 [MacOSX: arm64] Compiled at 2022-05-05 Copyright (c) 2006-2021 by Andreas Rumpf active boot switches: -d:release -d:nimUseLinenoise
- machinekob 4y ago
  how are u compiling (optimization, custom compilation flags etc.?) In my case https://github.com/mratsim/Arraymancer https://github.com/mratsim/Arraymancer big project compile under your 4.2s so or you have like 10k+ lines of codes with macros or you just pass some debug flags to compiler :D
  - zimpenfish 4y ago
    Compilation command is: nim c -d:release --passC:"-flto" --gc:markAndSweep --out:ap ap.nim I will add that once it's been run a few times, it does go a bit quicker (down to ~0.7s) but the Go also gets quicker (down to 0.28s for two outputs when files are cached.)

cb321 4y ago

As with most things, "it depends". If you compile very macro compile-time virtual-machine heavy code that can be slow. If you compile to the c++ backend then that backend process can be slow. If you invoke some macro that generates mountains of Nim code translated to continents of C code it can be slow. If you use the default `nim.cfg` that has gcc -Og it can take a lot longer than gcc -O0, for example. Meanwhile, if you use the `tcc` backend even without incremental compilation it can be close to immediate feedback: $ touch foo.nim $ /usr/bin/time nim c foo.nim CC: ../usr/lib/nim/lib/std/private/digitsutils.nim CC: ../usr/lib/nim/lib/system/dollars.nim CC: ../usr/lib/nim/lib/system.nim CC: foo.nim Hint: gc: refc; opt: none (DEBUG BUILD, `-d:release` generates faster code) 36891 lines; 0.154s; 39.434MiB peakmem; proj: /tmp/foo.nim; out: /tmp/foo [SuccessX] 0.24user 0.02system 0:00.27elapsed 101%CPU (0avgtext+0avgdata 44360maxresident)k 0inputs+0outputs (0major+13676minor)pagefaults 0swaps (I point my default backend compiler to tcc in my $HOME/.config/nim/nim.cfg.) There are some more details in this nim forum thread: https://forum.nim-lang.org/t/8677 https://forum.nim-lang.org/t/8677 Unless your standards are "single digit milliseconds per file like tcc itself, please!", 240 ms is not so bad. (EDIT: And this is just on some 2016-era Intel i7-6700k box, not some liquid helium cooled 10 GHz whatever.)