3 ms·

Xcode scales to the number of CPUs that you have very well. Any kind of c-compiler usually scales the compile step very well to the number of CPUs you have. Wh

by mahyarm 11y ago

Xcode scales to the number of CPUs that you have very well. Any kind of c-compiler usually scales the compile step very well to the number of CPUs you have. When I had a 12 core mac pro, my compile speeds were actually 3.4x faster than my 4-core macbook pro. And when you're an iOS / OSX developer, the only practical kind of machine you can use is apple's hardware. You can't go buy a 4 socket compile server that easily like people on other platforms.

jsmthrowaway 11y ago
Not really, no. Compiling C or C++ is not very distributable by its nature, and the parallelization you are seeing is scaling out builds by building multiple compilation units in parallel. If you're working in one file in an edit-build-test loop, all of those cores are pretty much unused as long as you're using incremental builds. This applies to a lot of languages, actually, not just C/C++. Even beyond that, you're usually I/O bound when you're building anyway, and I've found disk investment to pay off much better than CPU investment. But yes, for an all-up project build, it will be slightly to much faster because big projects can horizontally scale with the right tooling (make -j, etc).
- mahyarm 11y ago
  Very often you modify some upstream file and a 100 files have to be recompiled, so in an edit-build-test loop, it's very relevant. If you only have to rebuild one file, then everything is already usually very fast. When you don't then that's when the 12 cores becomes very helpful. And having a PCIe SSD is already built into the mac pro and macbook. RAID 0ing a whole bunch of SSDs didn't increase build speeds for me either when we did a test. And yes, the parallelization is done as you said. The compilation unit step tends to dwarf the linking step. edit: since HN prevents a reply to the downstream comment, we did test the ram disk case and turning off swap, and comparing to an HDD. The SSD from HDD was a marked improvement, otherwise everything else wasn't that much better unfortunately. This was a few years ago for a full rebuild on a C++ project, focused on the linking step.
  - derefr 11y ago
    If you want to test the effect of disk speed on build times, you should probably get a control case: one where the disk is taken out of the equation completely. Disable swap, check your git repo out into a tmpfs, and build there. If it isn't much faster, then you can just stop worrying about the impact of disk speed.

by mahyarm 11y ago

jsmthrowaway 11y ago

Not really, no. Compiling C or C++ is not very distributable by its nature, and the parallelization you are seeing is scaling out builds by building multiple compilation units in parallel. If you're working in one file in an edit-build-test loop, all of those cores are pretty much unused as long as you're using incremental builds. This applies to a lot of languages, actually, not just C/C++. Even beyond that, you're usually I/O bound when you're building anyway, and I've found disk investment to pay off much better than CPU investment. But yes, for an all-up project build, it will be slightly to much faster because big projects can horizontally scale with the right tooling (make -j, etc).

mahyarm 11y ago
Very often you modify some upstream file and a 100 files have to be recompiled, so in an edit-build-test loop, it's very relevant. If you only have to rebuild one file, then everything is already usually very fast. When you don't then that's when the 12 cores becomes very helpful. And having a PCIe SSD is already built into the mac pro and macbook. RAID 0ing a whole bunch of SSDs didn't increase build speeds for me either when we did a test. And yes, the parallelization is done as you said. The compilation unit step tends to dwarf the linking step. edit: since HN prevents a reply to the downstream comment, we did test the ram disk case and turning off swap, and comparing to an HDD. The SSD from HDD was a marked improvement, otherwise everything else wasn't that much better unfortunately. This was a few years ago for a full rebuild on a C++ project, focused on the linking step.
- derefr 11y ago
  If you want to test the effect of disk speed on build times, you should probably get a control case: one where the disk is taken out of the equation completely. Disable swap, check your git repo out into a tmpfs, and build there. If it isn't much faster, then you can just stop worrying about the impact of disk speed.