Does Visual Studio 2012 utilize all available CPU cores?

18,727

Solution 1

I would recommend getting a non extreme latest generation i7 with a decent SSD and double the RAM. If you trace to the file system what visual studio is actually doing, you will see that it is reading and writing a great number of files. Much of these files are cached during the second build in a row, but an SSD and enough RAM seems to be the most important speed-up component in the equation and a quad core i5 or i7 is sufficient preferably with hyper-threading and VT technology in case you want to run 64 bit virtual machines later.

I have also noticed decent compilation performance upgrades from changing an old computer from IDE to AHCI in the bios following the proper guide.

Solution 2

Visual Studio has the option of choosing number of maximum parallel builds - they use as many CPU cores as you wish.

However, you shouldn't really focus too much on this option when deciding which CPU to buy. Newest Intel processors use the Turbo Boost to speed up processes which are using less than maximum number of cores. Also, the Extreme Series are very expensive without much of a performance gain. The lower models can usually be overclocked and match the more expensive models.

If you really feel, however, that your compilation times are too high, you should take a look at IncrediBuild - I've used it myself and must say that it really speeds up the build process. It is able to really understand your system specification and use all the resources possible, and also use remote build servers as well.

Solution 3

If you are building large C++ projects you need as many cores as you can get! For example building Qt 4.8.3 did take less than two hours on my eight core machine with a SSD drive - o an 2 core machine with an HDD it took more than 20 hours

With BlueGo you can measure how long it takes to build Qt or boost on your system - so you can use it as a benchmark to find out how well suited your system is for building large C++ projects.

Share:
18,727

Related videos on Youtube

Tony_Henrich
Author by

Tony_Henrich

Updated on July 13, 2022

Comments

  • Tony_Henrich
    Tony_Henrich over 1 year

    I am planning to build a new very fast developer computer under Visual Studio 2012 and Windows 7 64 bit. I am getting all fast components like SSD's and 16G RAM. I was wondering if Visual Studio 2012 is built to utilize all available CPU cores. I am trying to make a decision whether to get an expensive 6 core I7 CPU or a lesser expensive quad core CPU in terms of whether they make a difference in compile time since that's what takes the most time when I am not coding.

    Note: There's a similar post from 2009 but I wanted to know if VS2012 has much better performance than VS 2010 in terms of cores utilization.

    I am balking at the $1000+ price of the I7 Extreme.

    • kfsone
      kfsone about 10 years
      A while back (2009) I pinged some MS folk with benchmarks of Win/MSVC, Win/GCC, Lin/GCC, VMLin/GCC and then with -j9 on the GCC's makes. All on the same physical hardware. The difference was staggering (they were shocked). Win/GCC was much slower than Lin/GCC but when I added the -j9 it left MSVC in the dust. My point is that the bottleneck with MSVC is not CPU - a huge chunk of it is writing map and pdb files, but it also does a hell of a lot of other io. If you can move $(tmpdir) to a ramdisk, you'll get a crazy compile time reduction, and an i7 will help with that.
  • Tony_Henrich
    Tony_Henrich over 11 years
    I read IncrediBuild's FAQ. It supports C & C++ only. I use C#. and no performance advantages on stand alone machines. I use a single computer.
  • Tony_Henrich
    Tony_Henrich over 11 years
    Are you talking about compilation time?
  • Bartek Banachewicz
    Bartek Banachewicz over 11 years
    Yea, I guess so. It isn't compiled to machine code, so it is much faster.
  • Lothar
    Lothar almost 8 years
    Using a SSD gave me 0 improvement, in compile or link time as all files are in cache already if you have RAM (8 GB are enough).