Some other alternatives, also haven't hearded about this one:
- SN DBS - https://www.snsystems.com/ - Used by a lot of game developers, to spread mostly compilation (but also shader compile, or custom jobs).
- IncrediBuild - https://www.incredibuild.com/
- Fast build - https://www.fastbuild.org/
- icecream - https://github.com/icecc/icecream
- Goma - https://chromium.googlesource.com/infra/goma/client/
- Bazel / buck / like with various RBE back ends - https://bazel.build/remote/rbe
- distcc - https://www.distcc.org/
- ElectricAccelerator - https://docs.cloudbees.com/docs/cloudbees-build-acceleration/11.0/
- and many others...
I've had mostly experience with IncrediBuild in the past, currently SN-DBS, but colleagues are looking into FASTBuild. Though my personal favorite is bazel
We discovered that while incredibuild did trap the system calls needed to stream and cache files from the building computer, at the time they did not trap Beep()!
ha! we've used it really long time ago, and there was something a bit non-standard with their C++ pre-processor, back then it wasn't working with one of our macros, and by the way they were displaying messages, and later searched these message in their binary I think I've found pascal-like strings (e.g. byte or word with length, then characters), so I thought it might've been written in Borland/Delphi Pascal?
distcc was really slow IME as well. It did not know how to optimally distribute the work across different build nodes. AFAIR distcc simply assumed that all build nodes are created equal and it also disregarded the load on the nodes resulting in over-saturation with build jobs.
However, this is something that icecream aimed to solve, and in my case it really did. I can't remember the actual numbers but it provided a major gain and it was super easy to set up.
So I guess it would be more nteresting to see how nocc compares to icecream instead of distcc.
Giving a comparison - e.g. evaluation - is a work paid hours. Also no one probably in their mind is ever going to do such an evaluation, or if it's done, it'll be one where you had to scratch one solution because of some limiting factor required by your company (but that factor may not exist outside - for example "support for Windows", or "works with precompiled libraries, does not expect everything to come from source code", etc., etc.)
because listing alternatives as a response is like saying "it also rains" when someone remarks. on how sunny it is. yes, it's true, but it's useless without discussing why it's preferable or not in what circumstances.
