Benefit from quad core when compiling in Visual Studio?

[Per B]

As title says, will my compile times in Visual Studio decrease a lot if I upgrade to a quad core processor? At the moment I'm using a 2,8 GHz P4 (single core): I realize that upgrading to a Core 2 Duo should help a lot (due to the better IPC of Core 2), but what about Core 2 Quad? Would a Quad @ 2.4 GHz be better than a Duo @ 3.2 GHz?

Thanks,
Per

 

[ERP]

As title says, will my compile times in Visual Studio decrease a lot if I upgrade to a quad core processor? At the moment I'm using a 2,8 GHz P4 (single core): I realize that upgrading to a Core 2 Duo should help a lot (due to the better IPC of Core 2), but what about Core 2 Quad? Would a Quad @ 2.4 GHz be better than a Duo @ 3.2 GHz?

Thanks,
Per

Depends which version.
2003 is exclusively single threaded, so no improvement other than you can play a game or browse the web without impacting performance.
2005 makes some attempt at being multithreaded, but I don't use it often enough to know how it distributes, I've heard people say you need more than 1 project in your solution to see an improvement. The few tests I did compiles were done in parallel but the tests were all done on large codebases with multiple (20+) projects.

We use incredibuild at work, but I actually find working at home to be more resposive when doing incremental compiles.

What you can do if you commonly touch tightly coupled headers is export a make file and use one of the numerous parallel make utilities, I've never bothered but it should work fine.

 

[3dcgi]

I think you'll have to wait for Visual Studio 2008. There's a beta out now.

http://msdn.microsoft.com/msdnmag/issues/07/06/Cpp/

Build Code Faster

Another improvement for developing C++ code that targets the CLR is that incremental builds are significantly faster. One sore point in the development of large CLR applications that have C++ components has traditionally been the need to rebuild dependencies, even when the core components have had only implementation changes and no interface changes. This was due to CLR assemblies packaging both the metadata and the implementation of a component in one binary. As a result, large C++ projects that depend on CLR assemblies would need to be rebuilt if any part of that CLR assembly changed.

The upcoming release of Visual Studio adds a new tool that creates a metadata-only assembly that captures the interface and only rebuilds dependent C++ projects when the interface assembly has changed. Changes to the implementation of an assembly do not trigger a rebuild of dependent assemblies. This can significantly reduce build times in the incremental build scenario, subsequently improving developer productivity.

While I’m on the topic of build throughput, one of my favorite features of Visual Studio "Orcas" is its ability to compile source files in parallel. This works for both native and managed code. CL.EXE provides a new switch, /MP, to enable this behavior. The syntax for the new switch is as follows:

/MP[n] use up to ‘n’ processes for compilation

Here, n essentially specifies the number of processors to be used. When the number of processors is not specified, the compiler uses the number of logical processors available on the machine. When a number is specified, exactly n processes are spawned for compilation.

The parallel compilation feature works by compiling different translation units in different processes; a single translation unit cannot be compiled across multiple processes. For example, consider the results of the following compiler invocation when run on a quad-processor machine:

CL /c /MP a.cpp b.cpp c.cpp d.cpp e.cpp f.cpp

The compiler will end up compiling four translation units in parallel with new translation units being compiled as soon as one of the four processors is freed up.

Now consider the results of the following compiler invocation run on a dual-processor machine:

CL /c /MP a.cpp

The compiler will perform a serial compilation of the single translation unit that it received since it does not perform parallel compilation within a translation unit.

 

[davefb]

did see this a while back,,


http://www.codinghorror.com/blog/archives/000867.html

w.r.t how much a core2duo is better than a high end p4.

a lot , is the answer..

 

[Paco73]

You can usually divide the compiling time by the number of processors (whenever you have enought memory and a good hard disk system) and add small percentage of this time as a penalty.

Take a look at http://www.todobits.es/mpcl.html

There you can find a free plug-in for for Microsoft Visual Studio C++ 2005, which creates a compilation thread for each core and all compile all in parallel.