The Background: I recently upgraded from a 2GHz AMD Athlon machine to a 3.2GHz Pentium D dual core processor, thinking that my Visual C++ (.NET 2003) compile times would decrease significantly. In fact, it went the other way round. One of my library projects requires 11 minutes to compile on the AMD machine, but takes 25 minutes on the dual core machine. My entire set of projects compiles in about 4 hours on the AMD machine, but in 8.5 hours on the dual core. The same slowdown occurs with the .NET 2002 version and VC6. I am awaiting delivery of Visual Studio .NET 2005 (apparently Programmers Paradise just got their shipment), so I have not tested the compile times for the latest version on the dual core. I have tested the compile times for the last of the .NET 2005 Beta on the AMD machine, and it is significantly slower than the .NET 2003 compiler.
My Questions. (1) Does the .NET 2005 version have the capability to load the processors to make the compiles faster (2) With any version of the compiler, is there some way I can get better performance Windows Task Manager allows me to right-click on a process and "Set Priority" or "Set Affinity...", the latter for suggesting which CPUs to run on. I'd rather not have to set these each time I start a compile. Moreover, when I did change the priority, I saw no noticeable difference in performance. Both processors appear to be about 50 to 65 percent utilized. I imagine it might be useful to have one of the processors (nearly) 100 percent utilized for the compiles.
I am hoping that the answers are "yes", otherwise I just purchased a very expensive machine just to double my compile times :(
Visual C++ compiles much slower on dual core processor
Hot Topic
- Microsoft Visual C++ Runtime Library
- VCBUILD -ing a single project in a solution file.
- yet another compiler error under vc2005
- Why doesn't this code work?
- Code that compiles in VS 6 doens't work in VS 2005
- VC++ Debugging - skip standard library code?
- MFC application crashes when running standalone
- Will porting a project from Visual C++ 6.0 to Visual C++ 2003 improve look of GUI?
- reference to an int array
- Program database manager mismatch
Visual C++
- ReadEncryptedFileRaw Problem
- Restarting CArchive
- Compiling x86 / x86-64 asm in VC++ projects
- CPP Compile
- c++ compilation strategy
- Problem seeing my window
- CDialog::DoModal asserting in CWnd::DestroyWindow
- The debugger isn't displaying std::wstring values
- Dialog background
- newbie question: Migrating from MSVC5.0 to actual Visual C++ 2005 Express Edition
Visual C++ compiles much slower on dual core processor
Imran Ashraf
Given the ability to compile multiple projects in parallel, at least my total compile time should be on the order of what I mentioned for the single processor AMD. I was really hoping to justify the expense of a high-end computer for developement. I will try the same experiment on a 3.2GHz Pentium 4. If the compile time is much better, maybe I can return the dual-core machine and replace it with a single-core one.
Thanks again.
Jason Celestine
First of all, thanks for sharing your experience with us.
In VC2005, the project build system allows you to build separate projects at the same time. You can specifiy the maximum number of processors used by going to: Tools-->options-->project & solution and then specify the maximum number of parallel project builds.
It is to be noted that this is building separate PROJECTS and not files within the same project.
As for the compiler performance itself, in lots of cases it has been slower due to enabling more optmizations and techniques. Nevertheless, we are looking into such issues for our next release.
Thanks,
Ayman Shoukry
VC++ Team
Andrew1985
As Ayman mentioned, VS2005 does allow you to compile multiple projects in parallel, but unfortunately we don’t have that ability within a project at this time. That second CPU will still help taking care of services and other process on the machine, but the compiler itself won’t take advantage of it.< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
Are these debug or release builds On a debug build, a lot of the time is spent doing disk I/O. The amount of memory on the system and the speed of the hard drive can make a big difference. On a release build however, a lot of the time is spent on the CPU and doing memory I/O. I would expect one of the CPU to peg near 100% utilization, unless you have hyperthreading on… A 2X slowdown is quite unexpected to me.
Cl.exe is running at normal priority, so changing the priority on the process won't help unless you have other processes busy doing other things and stealing CPU cycles.
< xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />Louis Lafreniere
VC++ Development
William Dobbs
Jeffrey van Gogh
If you have a Pentium 4 and only see one pane, then you will need to start up your machine and do a Bios-level setup (F2 on Dell) and enable hyperthreading.
(Posting and testing this by rebooting... )
Find in Forums
I actually discovered what the problem is with the compiles. My old machine had a hard disk partitioned into two drives, C and D. I had all my source and source control set up for drive D. The new machine has a hard disk with a single partition. In order to avoid changing my source control, I created a folder on C, shared it, and mapped it to be network drive D (on the same machine). Turns out that I was opening the Visual Studio projects through this networked drive. My earlier post about "System" taking a lot of cycles should have been a clue to me, but the posts from others about the disk I/O made me think about figuring out why "System" was taking so long. Apparently, the networking overhead associated with my "fake" drive D setup is significant. Chalk one up to my ignorance of networking.
I opened the Visual Studio projects directly from the folder on the C drive. The compile times are now what I expected. The 11-minute compile on the AMD is now a 5-minute compile on the dual core.
I really appreciate the help. And I appreciate that the .NET 2005 environment will support simultaneous compiling of multiple projects. This should cut my full-compile times to one hour, which makes my development life much easier. Thank you for all your efforts in building such a fine product!
WishYouWereHere
Louis Lafreniere
VC++ Development