I randomly came across a plea from the developer of the "mold" linker, asking for help with funding and/or license acquisition; and considering going to a split personal/commercial license otherwise. I know "choosenim" currently uses GNU ld 2.27 from 2016: given the increase in dev-targets & tooling changes the past 6 years, it may be worth looking into this?
For reference, I have the following configuration in ~/.config/nim/config.nims
if findExe("mold") != "" or findExe("ld.mold") != "":
switch("passL", "-fuse-ld=mold")
On my oddball little project, the build time goes from 30 seconds to about half that in 15 seconds. Nim is a much faster build than that one, even with the default linker, so it may not make much difference, but it still saves waste.
It would be a shame to end the conversation with this, as it is a good proposal, so I investigated it in more detail. The following was added to config/config.nims from the Nim compiler devel branch and compared before the change. (I am ashamed to admit that my last post seemed completely amateurish, so I have made a few corrections.)
when defined(linux) and findExe("mold").len > 0:
switch("passL", "-fuse-ld=mold")
when defined(macosx) and findExe("ld64.mold").len > 0:
switch("passL", "-fuse-ld=ld64.mold")
Nim devel 1st: $ time ./build_all.sh real 7m5.153s user 6m30.020s sys 1m1.229s
Nim devel 2nd: $ time ./build_all.sh real 7m3.367s user 6m10.247s sys 0m56.155s
Nim(changed) 1st: $ time ./build_all.sh real 6m45.184s user 6m12.736s sys 0m54.609s
Nim(changed) 2nd: $ time ./build_all.sh real 6m46.392s user 6m15.836s sys 0m56.464s
Obviously completed faster. about 15sec. The environment used is a laptop with Ubuntu 22.04 WSL and a power-saving AMD Ryzen 5800U CPU. The version of mold is 1.7.0. (I also tried to see if Nim would compile with an older version. The version I used was ver 1.0.3 installed by apt install mold on Ubuntu 22.04, but I was able to link it successfully.)
I think that suddenly changing the default linker of the C processing system has a large impact, so I think that individual developers need to put in the above settings and verify them. I don't know how many committers there are, but even assuming 20, that would save 90 hours a year if they compile 3 times a day. Of course, it doesn't mean that they are doing nothing while waiting for the compile, but even a few seconds of waiting time for a busy Nim compiler developer can be reduced, which has its own impact.
Using "mold" will change the SHA1 of the binary, so the executable created will be different from the default linker, but since it does not change the compiler code, the impact should be minor.
Other notes: I compiled mold's main with a different Makefile and -march=native, but it was too heavy and went out of control, so I did not try it.
Sorry to take up so much time with the Nim developers, but I think it's a good suggestion and would like to send a pull request, what do you think? If there are any comments such as "This pattern case is missing and needs to be further verified," or "The linker change to release build is hasty and should be limited to debug first," we would like to correct it.
I have sent a PR to the mold side to ask them to include it in the README.md. I don't know if it will be merged yet. https://github.com/rui314/mold/pull/886
Of course, Mr.Yardanico is right, it is not good to be deeply dependent on a particular processing compiler or linker, but I would also like to lighten the burden on the Nim developer a bit.
Obviously completed faster. about 15sec.
I saw this thread a week ago and have set mold as the default for my Gentoo box now. Note that mold does not work with glibc and the Linux kernel, see https://wiki.gentoo.org/wiki/Mold
Actually mold seems to generate smaller executables, maybe by 2%, for Gentoo-LTO.
For your ./build_all.sh: Note that this command is generally only needed for the first fresh install. Updates can be done with
cd Nim
git pull
./koch boot -d:release
./koch tools
And that takes only a few seconds. That update procedure is a bit hidden in the documentation, but I assume devs know it.
For Nim app builds, I have seen no benefit of mold. My sdt app takes now 25 seconds with or without mold, with recent devel compiler. I think one year ago it was only 12 seconds. This proves again the observation that software is always becoming slower.
I don't know how many committers there are, but even assuming 20, that would save 90 hours a year if they compile 3 times a day.
Most times the compiler is compiled is in debug mode with a cache which means at most it takes ~20s. I did try mold on multiple projects with my 5600x and I have not noticed any substantial differences in compile time(Likely cause Nim is really eating the compile time). Though I have been known for doing bad benchmarks before.
@Stefan_Salewski : Are you comparing a --mm:orc with a --mm:refc build? That could be the reason for the drastic difference in compile time. Devel now defaults to orc a year ago it did not.
Thank you for taking the time to reply.
Stefan_Salewski >And that takes only a few seconds. That update procedure is a bit hidden in the documentation, but I assume devs know it. Thank you for letting us know. I had imagined that the difference in link times would be more pronounced with differential builds, but apparently I need to verify with a little more precision. Thank you for immediately pointing out the less-than-realistic nature of my benchmark.
ElegantBeef >Most times the compiler is compiled is in debug mode with a cache which means at most it takes ~20s. I did try mold on multiple projects with my 5600x and I have not noticed any substantial differences in compile time Thank you for trying it in different environments.. I will only send a PR if I see a concrete and clear difference after more verification. Thank you all for your valuable time.
What's a little peculiar in my environment is that I have a RAM disk in it, but I'm wondering if the RAM disk has any effect since nimcache uses the same directory in the full build of the Nim compiler itself, but it doesn't seem to make a clear difference in different environments.
In any case, you are right that Nim compiles very fast even with gcc ld or clang lld, so there is not much point in actively changing it.
When I can verify it more correctly and with more patterns, or when the situation changes, we may suggest it again.
that would save 90 hours a year if they compile 3 times a day.
I've heard that "programs are run more often than they are compiled," so I'd be more likely to use it if I know how this affects the execution time of the program.