5 ms·

Why do you need to many CPUs? I can only think of compiling but in my experience not many compilers can actually handle multiple cores well and you might wanna

Why do you need to many CPUs? I can only think of compiling but in my experience not many compilers can actually handle multiple cores well and you might wanna consider using other tooling if your compiler needs to recompile that 100k LOC again and again instead of just compiling the changed files again (and their dependencies). As cool as this machine is, it is definitely targeted at video makers who spend more money on powerful hardware (because they need that) compared to developers.

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.
maccard 11y ago
I work on a large C++ application. A full rebuild is 35 minutes of our main configuration - that's with 2x 20 core xeons. We also have a "gaming" pc, which is an overclocked 6700k (think it's running at about 4.5GHz) - I believe a full build of the same configuration is about an hour.
Sanddancer 11y ago
Think things like test VMs for development when you're targeting disparate OSes and versions. Instead of needing to deploy things to VMs in sequence, you can deploy to them all at once and still get decent performance.
walshemj 11y ago
Depends what sort of developing you do if your working as technical programmer there are plenty of areas where you want as much CPU and memory as possible. Look at the average node in a big data cluster
jwr 11y ago
Clojure code scales to multiple cores very nicely and I can make very good use of them in my work. That said, I do care about single-core performance too, the number of cores is secondary.

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.

maccard 11y ago

I work on a large C++ application. A full rebuild is 35 minutes of our main configuration - that's with 2x 20 core xeons. We also have a "gaming" pc, which is an overclocked 6700k (think it's running at about 4.5GHz) - I believe a full build of the same configuration is about an hour.

Sanddancer 11y ago

Think things like test VMs for development when you're targeting disparate OSes and versions. Instead of needing to deploy things to VMs in sequence, you can deploy to them all at once and still get decent performance.

walshemj 11y ago

Depends what sort of developing you do if your working as technical programmer there are plenty of areas where you want as much CPU and memory as possible. Look at the average node in a big data cluster

jwr 11y ago

Clojure code scales to multiple cores very nicely and I can make very good use of them in my work. That said, I do care about single-core performance too, the number of cores is secondary.