4

I am trying to optimise the compilation time of a large VC++ project. My processor is a Core i7 950 (4 Cores, 8 Threads since it supports Intel Hyper-Threading Technology).

In Microsoft Visual Studio 2010, if you go to Tools>Options>Projects and Solutions>VC++ Project Settings>Maximum Concurrent C++ complilations

you can select the maximum of CPU cores to use for parallel C++ compilation. I select 0 there (so that all my cores are used), which produces exactly the same results as when using 4 or 8.

Now, if I open the Task Manager whilst compiling the project, I can see that 4 parallel compilation threads are running (Under processes they have the description: Microsoft C/C++ Compiler Driver), and that the total CPU usage is a bit less than 50% all the time.

So my question is:

Is it possible to have 8 parallel compilation threads in a quad core, hyper-threaded processor? If this is not possible, then is it possible somehow to use near 100% the processor power whilst compiling?

This is will save me a huge amount of time.

Thank you very much in advance,

Nicholas

nikos
  • 147
  • 2
  • 9

3 Answers3

4

This is will save me a huge amount of time.

No, it wouldn't. Hyperthreading is useful when you have different sorts of tasks to run which use complementary resources inside the CPU. For example, one thread uses a lot of floating-point and the other doesn't. While the first is doing floating-point math, the rest of the CPU is available to the other thread.

For obvious reasons, a bunch of compile threads want the same internal CPU resources. All you'd achieve is having twice as many threads fighting over the CPU cache and resources. More cache contention would make life slower, not faster.

Well, the above explains why you won't get BIG gains from Hyperthreading and homogenous code. The conventional wisdom for parallel make is to set the number of jobs one greater than the number of cores, the assumption being that 1/N processes is probably doing disk I/O. Of course, that's for Unix make where a job does a lot of makefile processing in addition to actual compilation.

If you turned the knob up to 8 and didn't see any change (note, it could be a negative change in throughput for reasons explained above) in Task Manager reported CPU usage, it's probably because interdependencies in your solution are forcing certain compile tasks to run sequentially. If one task relies on the output of another (precompiled headers often cause this) then that limits the number of simultaneous jobs -- even if you had a 16 core system, you'd still not get more parallelism than what the project structure permits.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • Thank you for the reply. So having 4 compiler processes will never get me over 50% total CPU usage, is that right?? – nikos Jun 16 '11 at 14:06
  • @Nicholas: Windows has no clue how to calculate % usage for a CPU with hyperthreading. You only have 4/8 possible threads running, but they're using 4/4 of the kind of CPU resources needed for compiling. Higher CPU usage doesn't mean useful work getting done faster. 10,000 processes running at once will hit 100% CPU, but they'd be spending more time moving data between main memory and cache than doing work. – Ben Voigt Jun 16 '11 at 14:08
  • This is not true. Compilation Speed is not really dependent on processing but memory throughput (not IO as many people call it). And this means lots of cache misses where the CPU is going idle and the other thread can run. Unfortunately Intel is far away from Sun/Oracles state of the art. Thats why you only see a 35% increase during compilation. – Lothar Jan 25 '12 at 05:44
  • @Lothar: Did "All you'd achieve is having twice as many threads fighting over the CPU cache" not adequately cover that point? – Ben Voigt Jan 25 '12 at 05:46
  • The same vs. different kinds of threads isn't the important criterion. High throughput vs. low throughput is what matters. Two threads that both stall frequently on branch mispredicts can gain big speedups. Two threads that both average 3 instructions per cycle with different instruction mixes will likely gain very little, especially once you consider that they don't have as many out-of-order exec resources to themselves. – Peter Cordes Oct 23 '22 at 15:52
0

Could be that you're just disk limited instead of CPU limited.

Puppy
  • 144,682
  • 38
  • 256
  • 465
  • so you are suggesting that upgrading to an ssd could solve this issue, and go up to 100%? – nikos Jun 16 '11 at 14:02
  • @Nicholas: Quick test would be to use a RAMDisk for your build directory. But usually compilation is CPU-bound. – Ben Voigt Jun 16 '11 at 14:03
  • Just wanted to cancel my upvote rather then -1 but here goes - near 50% on an 8core HT system means that 4 cores run at near 100% CPU usage - this shows it's not disk limited as it's using all the CPU that 4 threads can. – RnR Jun 16 '11 at 14:08
  • 1
    @RnR: Or, there could be 8 threads running at 50% CPU each, as they can't get enough input to run at 100%. – Puppy Jun 16 '11 at 15:32
  • Yes - but that's not the case here - "Now, if I open the Task Manager whilst compiling the project, I can see that 4 parallel compilation threads are running" – RnR Jun 17 '11 at 11:44
  • I'm not sure if the CPU usuage display is helpfull to measure the utilization of hyperthreaded applications. – Lothar Jan 25 '12 at 05:50
0

I think this is a problem with visual studio. Try to run your makefiles with "jom" the parallel nmake clone. You should see a 35% increase when using it over msvc called to compile with 4 cores.

Lothar
  • 12,537
  • 6
  • 72
  • 121