Visual C++ compiles much slower on dual core processor

Visual C++ compiles much slower on dual core processor

• gandor

  Thanks for the information.  Both processors are active; two panes show up in the task manager.
  
  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!
  
  
  

• tschissler

  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

  
  
  

• excalidalf

  The performance differences are similar, whether Debug or Release.  These numbers are from the AMD Athlon 2.08Ghz and from the Pentium dual core, running .NET 2003.  Debug build:  11 minutes AMD, 25 minutes Pentium.  Release build:  7 minutes AMD, 19 min Pentium.  I have a RAID1 system (parallel writes for data security) on a new Dell XPS400.  The machine has 4GB of memory.  In the Debug or Release builds, neither CPU was pegged at 100%.  I do not about hyperthreading.  I just used the machine the way it was configured by Dell.  How do I check for this
  
  
  

• mpenalor

  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

  
  
  

• Demono

  This makes sense.  Good to see you figured it out.  If you want your fake D drive back, use subst.exe instead of a network drive.
  
  Louis Lafreniere
  VC++ Development
  
  

• RJDBA

  Thank you for the response.  I was hoping to have an option within the IDE to specify the priority for cl.exe, but since changing it through Windows Task Manager when the process is running did not seem to do anything, it might not matter even if I had the option.  I can always try to run the build from the command line and specify "start /high" and see what happens.  With the default priority, cl.exe shows up as using 25% of CPU.  "System Idle Process" appears to be stable at 40%, but "System" is about 30% during compilation.  If the processors are this idle, it is a shame if I cannot get cl.exe to suck up more of their time.
  
  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.
  
  
  

• Steve Moores

  Go to the task manager (via control-alt-delete, or right click on taskbar), and go to the Performance tab.  The number of panes in the CPU Usage History corresponds to the number of processors active.   If you have a Pentium 4 processor with HT turned on you should have two processors active.
  
  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... )
  
• Visual C++ compiles much slower on dual core processor