Was Visual Studio 2008, 2010 or 2012 (v11) written to use multi cores?

Question

Basically i want to know if the visual studio IDE and/or compiler in 2010 and 2012 was written to make use of a multi core environment (i understand we can target multi core environments in all versions using parallelism, but that is not my question).

I am trying to decide on if i should get a higher clock dual core or a lower clock quad core, as i want to try and figure out which processor will give me the absolute best possible experience with Visual Studio 2010 or 2012 (v11) (ide and background compiler).

If they are running the most important section (background compiler and other ide tasks) in one core, then the core will get cut off quicker if running a quad core, especially if background compiler is the heaviest task, i would imagine this would be difficult to separate in more than one process, so even if it uses multi cores you might still be better off going for a higher clock CPU if the majority of the processing is still bound to occur in one core (i.e. the most significant part of the VS environment).

I am a VB programmer, they've made great performance improvements in 2010 and 2012, congrats (except for the horrid grey scale design and the uppercase everywhere), but I would love to be able to use VS seamlessly... anyone have any ideas? Also, I'm not too worried about solution load time, as I only code one project at a time.

Thanks.

Answer 1

I think you're probably better off with a higher-clock dual core. I think VS (and most apps today) do not yet take great advantages of multi-threading. VS may have dozens of threads running, but only a subset of operations really take advantage of them well I think. A whole lot of the VS implementation is C++ COM components that run on the STA thread, so the UI thread does the bulk of the work in many scenarios. The fact that many pieces of the VS shell are being rewritten in managed code as part of VS2010 will help break a lot more of these ancient component STA dependencies. As others have mentioned, some key scenarios (like building a large solution) already do take advantage of multiple cores (MSBuild works well in parallel), so if those dominate what you care about, then more cores is better. But for things like IDE UI usage and background compilation, I think most of these are still mostly single-threaded. I've a quad-core box at work, and I rarely see VS2008 use more than 25% of my CPU resources. (I've not used VS2010 enough in earnest to know which scenarios are better, though I know at least a few are better.)

Answer 2

MSBuild supports building projects in parallel. Visual Studio 2008 takes advantage of multiple processors to compile projects.

Answer 3

As other people have noted, MSVS 2010 does indeed use multiple processes for compilation. Although, it does not automatically converts into heavily reduced compilation time. I have just made a test with a middle sized C++ project (around 200 files). It built faster on Dual Core at 3.4 Ghz than Quad Core at 2.8Ghz. Although Dual Core processor is cheaper. (Systems are practically identical with 4GiB DDR2 Ram each). I must note also, that during compilation Dual Core processor was loaded to 70% max. As you can see, if VS2010 can not fully load even 2 cores, what is the point of having 4 or more?

Answer 4

Forget CPU. The single biggest performance boost you can give your machine is a Solid State drive. Compilation and background processes such as Resharper and Intellisense are so IO intensive that the main bottleneck with visual studio is IO. I have never seen VS max out the CPU, regardless of whether I had single, dual quad or 8 cores as I do now.

Update Thanks for your comment @Erx... I am no expert about the exact processes that are going on. However, if you think about how many reads the compiler makes just to compile a project, you won't be surprised by the IO hit. Visual Studio may hold files in memory, but have you noticed that when you build a project and you have unsaved changes, the files are saved first before the build kicks off? This tells me that the msbuild compiler is accessing the saved files and that it doesn't use the in-memory files. If you have closed a file in VS, there is no guarantee that the file is still in memory as it might have been cleaned up by VS's memory management. So it makes sense that the compiler gets a clean copy. This can be many hundreds or thousands of files. Then there is the writing of compiled output, NuGet package reads, ConfigGen scripts (http://configgen.codeplex.com/). You get the picture.

Also, I have read somewhere that Intellisense does a lot of reading and writing to the file system, so that is going to be an added hit on performance if you have a slow HDD.

Plugins such as Resharper also hit the file system, particularly with background compilation. I would never advocate removing Resharper as it is the best productivity tool available. So I will reiterate, if you have splashed out on a fancy new system with the latest number of available cores and huge ammounts of RAM, spend a couple of hundred dollars / £100 on a new SSD. You won't regret it.

Also, Check out Scott Guthrie's bog on the matter http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx Specifically, I quote: "...where necessary trade off purchasing additional CPU processor speed in favor of investing in a faster disk instead". If anybody should know you would expect the head of the Visual Studio Development Team to know.

Answer 5

http://blogs.msdn.com/visualstudio/archive/2010/03/08/tuning-c-build-parallelism-in-vs2010.aspx

Answer 6

On thing to consider would be your use of virtualization in your development environment. virtualization definitely makes use of multiple cores whether or not Visual Studio does. I have multiple development environments each with its own VM.

Answer 7

The question has been edited to mention VS2012, but most of answers date back to before that was released. VS2012 introduced parallel builds as a standard feature. So, there is better opportunity to easily utilize more cores on a capable CPU. However as previously mentioned, if you want short compile times a fast hard drive is essential, preferably a high end SSD.

There is some debate regarding whether the hard drive or the CPU is the better investment, but improving either should have a big impact. In most markets the cost of developer time far outweighs hardware costs so usually you are best off buying the best CPU and hard drive you can. The only thing to factor in is the law of diminishing returns at they very top end.

Quote from the article regarding parallel builds on VS2012:

Visual Studio 2010 included an option for "maximum number of parallel project builds." Although there was no indication of any restriction, this IDE option only worked for C++ projects. Fortunately, this restriction no longer applies to Visual Studio 11. Rather, there's now full support for parallel builds in other languages as well. To view this, run a copy of Process Explorer at the same time a solution with numerous projects is building. You'll see that multiple MSBuild instances are created -- as many as specified in the "maximum number of parallel project builds."