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.

Solution 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.)

Solution 2

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

Solution 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?

Solution 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.

Solution 5

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

View more solutions

Comments

[Erx_VB.NExT.Coder]

thank you brian, that was a perfect clarification of the isses i've had in mind, between the 2.0ghz quad-core and the 2.93ghz dual-core i believe that the 2.93ghz dual-core is probably the best way to go (if others were also wondering, based on current laptop available cpu components) mainly because vs as with many other apps are unlikely to be perfectly (or close to perfectly) parallelized. - thanks again

[Erx_VB.NExT.Coder]

thanks for this input, i think mainly enterprise developers and multi-project developers should pay attention to this, if you are reading.

[PeteT]

I think in VS 2010 it's a very close run thing, it's certainly more threaded than before. And if you have set ms build correctly it will build projects in parallel. Most people have several projects in their solution that have dependencies on each other in some way. Combine that with the fact you are running an OS, email client, web browser... probably all the time 4 cores makes sense to me. Don't think multiple threads for one program think multiple apps.

[Erx_VB.NExT.Coder]

thanks for this input pete, its definitely something to think about, i wonder what the vs dev team have to say about this?

[Erx_VB.NExT.Coder]

thanks for this note, i've voted you up :) esp given that you're a new user.

[jcpennypincher]

You may have other programs running at the same time besides Visual Studio... That's the point of using a Quad core or Octal core etc etc...

[Erx_VB.NExT.Coder]

wow, really? i had no idea about this. heard SSDs can make a big difference but didn't understand why, since my understanding of hard drives making a difference in VS UI would be only when opening huge projects or something... but i suppose what you're saying makes sense, so to clarify, the store many UI and code based variable, lists and item data on the HD during use instead of consuming unnecessary amounts of memory, is that right? I'v ebeen oblivious to this and would love to know as much as you're happy to provide, thanks mate (upvoted).

[darklon]

This is actually not true, CPU does seem to be the main factor! I say this from experience - I timed compilation on a 1.6 Ghz Core i5 + SSD machine, and on a 3 Ghz Athlon 64 X2 with hard drive. The Athlon machine with hard drive is about 50% faster!

[Daniel Dyson]

What I said was true, Specifically that the BIGGEST performance boost would be a faster HDD. That's not to say that a faster CPU wouldn't help at all. Of course it would. But in terms of bang for your buck, go for the SSD. Also, you are not comparing like for like. Try comparing the speed with the same HDD in both machines. And then the same SSD in both machines. And then do your calculations. You will find that in both tests, the SSD will perform much better

[Daniel Dyson]

Also, Check out Scott Guthrie's bog on the matter weblogs.asp.net/scottgu/archive/2007/11/01/… 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.

[Erx_VB.NExT.Coder]

@CorneliusScarabeus I'd like to add, I think Daniel is talking about UI experience (since thats my main concern) as opposed to compilation time. Compilation time isn't a big issue for me, since most time spent is using the UI, UI related freezes and slowdowns are the prime concern, so in this case I think Daniel is right. However, I'm sure you are also right in relation to compile time since compiling is processor-intense.