23 December 2008

Visual Studio 2010 Hardware Requirements

Soma’s been talking about the upcoming Visual Studio 2010 release on his blog, which means I’m starting to get questions about what type of hardware you’re going to need to run VS2010 on.

Unfortunately, I can’t give you an official answer yet (other than to say, it depends on what you’re doing – obviously building small apps with one of the Express versions of Visual Studio won’t require the same resources as a multi-million line app using full blown Visual Studio Team System with lots of third party add-ins).

What I can do is help put some of the things we’ve said about Visual Studio 2010 into context, to maybe help you make some better hardware decisions today:

1)                  Memory – we’re trying to make VS2010 as frugal as we can here in order to run in as little memory as possible; however, we’re also adding a lot of functionality, and systems with more memory do tend to perform much better.  So the general rule of buying systems still applies – spring for as much memory as you can afford.  It’s hard to have too much memory, at a minimum you want to make sure that you’re not paging.  That said, there’s very little benefit to making a text editor 64 bit (and lots of reasons not to), so anything over 4GB is likely to be wasted (unless you’re running or writing apps that need more).

 

2)                  CPU – modern CPUs with their larger caches and tuned instruction pipelines tend to perform much better than one’s from just a few years ago (see our blog).  If you’re going to do multi-threaded programming, you’ll want at least a dual core processor (and with the new Parallel Computing support in VS 2010, you will want to do multi-threaded programming).

 

3)                  GPU – VS2010 will leverage WPF heavily to create richer editing and visualizations, so a decent GPU that supports at least DX9 is highly recommended (DX10 is preferred, but requires Vista).

 

4)                  Disk – If you’re building a large project or working with a large database, a large high-speed disk is pretty important.  For large projects, you can often benefit by spreading your work across multiple disk spindles.  At an extreme, putting your tools on one drive, your source code on another, and your object files on a third drive allows the three major sources of disk IO in building a project to be carried out independently of each other.  If you have to use a slower disk (e.g. a notebook) then be sure to get lots of memory.  Also keep in mind that modern hard drives tend to have more built in caching, so the same speed drive bought recently will likely outperform one bought a few years ago. 

So now that I’ve given you my thoughts on what hardware Visual Studio 2010 will need, what are your thoughts?  What kind of hardware are you developing on today, and what do you expect to be using in the next couple years?  What are your expectations on how we should be leveraging your hardware to create a productive development environment?

 

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# Miha Markic said:

I am thinking about using SSD(or SAS or Velociraptor) most probably in RAID1 for sources and/or RAM disk for object files.

Do you have any performance tests for such configurations?

24 December 08 at 10:03 AM
# David Berg said:

Miha,

We used to test with 10,000 RPM HDs (like the Velociraptor) but quit because it wasn't a "typical user experience" (but it did help the throughput in our test lab).  We do most of our testing on 7,200 RPM HDs on the basis that it's a fairly standard configuration that sits in the middle of what most of our customers have.  We don't currently test SSD in DevDiv (although Windows does).

In general, you can expect that a faster drive will improve performance in any disk bound scenario.  The biggest advantage of SSD drives is that you eliminate seek time, making them ideal for applications with high random I/O.

The only problem with putting object files in a RAM disk is when the RAM comes from system memory it effectively reduces the amount of memory available for disk caching.  So you gain in some areas, but may lose in others.

You might want to turn off search and virus checking for the directories/drives where you put your object files (if you haven't already).  We do most of our performance testing with search and virus checking off, otherwise the results are too noisy.

Regards,

Dave

24 December 08 at 11:59 AM
# Josh said:

"That said, there’s very little benefit to making a text editor 64 bit "

So VS2010 is *just* a text editor?  It kinda does a bit more than that, stuff I'd imagine would be useful under 64-bit.  I'd like more details on the pros/cons that you guys ran into.

30 December 08 at 10:42 PM
# David Berg said:

Josh,

The pro of 64 bits is access to more than 4GB of memory (which can help some apps trememndously).  The con is increased pointer size, which increases data sizes, in term consuming more memory, which take a little longer to manipulate.  (There's also a hit to debugging performance due to differences in how stack frames are built.)

Yes, VS is much more than a text editor.  The real question is which parts of VS would benefit from being able to access more than 4GB of memory?  Text editing probably not.  Even if you had more than 4GB of source code, annotations, and cross references - would we really benefit from having it all in memory?  It's unlikely that a single user would ever reference that much source material.  What's more important is a good on disk index structure that allows us to rapidly retrieve information as necessary, and cache it where it makes sense.  By avoiding 64 bits we keep data structures smaller, so we actually can keep more in memory with a smaller footprint, and access it faster than if we went to 64 bit.

Now, where we have parts of VS that do benefit greatly from accessing more than 64 bits, then it would make a lot of sense to make those parts of VS 64 bits.  Also, some parts of VS have to be 64 bits in order to support 64 bit code development.

So, as I said, if you're doing 64 bit development (and the only real reason to do so is if you're writing apps that need more than 4GB), then you will absolutely want a 64 bit system, and probably want more than 4GB of RAM.  Or if you're using VS in some kind of application server environment, where it's accessible to multiple users, then you may also want more than 4GB of memory.

But for the average developer, writing 32 bit apps, then 4GB should be plenty (at least for VS2010).

Regards,

Dave

31 December 08 at 1:00 AM
# Olaf van der Spek said:

>  If you’re going to do multi-threaded programming,

Can VC already compile multiple files of a single project in parallel? With 4/8 cores/threads being easily available, I certainly hope so.

11 February 09 at 3:50 PM
# David Berg said:

MS Build 3.5 (NETFX3.5/VS2008) supports a parallel build from the command line (http://msdn.microsoft.com/en-us/library/bb651793.aspx).  

The VC IDE also supports a parallel build, but it's only VC, not the rest of VS2008 (http://blogs.msdn.com/saraford/archive/2008/09/30/did-you-know-only-vc-supports-parallel-building-within-the-ide-324.aspx).

11 February 09 at 4:28 PM
# David Berg said:

On the subject of build performance, here's a recent post by Jim Lamb on improving TFS Build performance, note that a lot of the suggestions apply to any build system.

http://blogs.msdn.com/jimlamb/archive/2009/02/10/improving-build-performance-in-tfs-2008.aspx

12 February 09 at 9:13 AM
# Ketan said:

I would suggest to focus on general performance and basic tools (like C++ Refactoring tools, Code snippet support etc.) instead of using WPF, which does not add any value to code product! I am finding myself going back to some other editor which does the one job well without eating away my resources!

Some how, I find your Goal #1 and #3 contradictory.

16 February 09 at 11:50 PM
# David Berg said:

Ketan,

Yes, it's not uncommon for goals to be somewhat contradictory.  Striking a good balance is always the challenge.  One of our biggest challenges with VS 2010 is making sure we make the right trade-offs.

WPF requires extra memory to load WPF, DX, and for DX buffers.  Exactly how much depends on the GPU.

There are benefits to WPF, which include:

1) By leveraging the GPU WPF can offload processing from the CPU and free it up to do real work and let us create a more responsive UI.  

2) WPF gives us better UI design / code separation.

3) WPF enables new features that would be cost prohibitive without the GPU.

However, Visual Studio is large and we won't be able to realize all the benefits in a single release.  Hopefully though we'll be able to do enough that you will find it worth while.

17 February 09 at 12:40 AM
# valued customer said:

My top three reasons for wanting a 64-bit devenv.exe:

1) Add-ins

2) Add-ins

3) Add-ins

Analysis add-ins such as Refactor, CodeRush, NDepend, Dotfuscator Pro, MemProfiler and the like eat quite a bit of memory, especially with a large solution. I have to resort to running some of these stand-alone (NDepend, Dotfuscator), losing a fair amount of integration with VS.

13 May 09 at 2:42 PM
# Parashu said:

Hi Team,

this is Parshu, my system runnung with VS2008 and VS2005 and here i am facing the Performace issue. my system getting dead slow when i open both the Environments

this is my Sys configuration:

1.83Ghz CPU.

1GB RAM

160 GB HARDDISK

Please suggest me if i need to upgrade my sys Configuration.

Thanks in Advance

Parasu

26 June 09 at 8:31 AM
# David Berg said:

Parashu,

The short answer is a qualified, yes - you should upgrade your hardware.  

Here's why:

1) You didn't say anything about your OS or the size of your solutions.  With only 1 GB of RAM - if your running XP, and if youre solutions are fairly small, then you may be okay where you're at.  But, if you're running Vista or your solutions are large, then you're going to see some significant performance improvements from moving up to 4GB.  And once you move to 4GB, if you're not running Vista, you're also missing out.  With sufficient memory, Vista will do a better job of caching the hard disk than XP, so you'll see faster loads and fewer stalls.

2) I'm assuming from the CPU speed and memory that your system is at least a couple years old.  As noted in point #2 in my original post, older systems tend to lack the cache and other micro-architectural advances of newer systems.  So moving to a modern 2.x ghz system will probably result in a major speed up of anything that's CPU bound.  Additionally, modern systems tend to have built in disk cache and better video systems.  

3) You didn't say how many CPUs you have, so I'm assuming one.  Almost everything I'm buying these days is dual or quad (and the rest is 8+ procs, I'm not buying any single proc machines - even most netbooks are hyperthreaded).  VS isn't terribly multithreaded, but parts of it are.  But at the same time, you said you're running VS2005 and VS2008 at the same time.  Plus you're probably running other applications, and the OS has lots it wants to do.  So you're probably missing the opportunity to parallelize work and improve responsiveness.  

Finally, you asked about VS2005/2008, and I assumed above that was your primary focus.  But the original post is about VS2010.  VS2010 adds a lot of functionality and leverages WPF.  You're going to want multiple CPUs, a good video subsystem, and lots of memory to leverage everything we're providing, especially if you're going to be running multiple copies or VS2005/VS2008 at the same time.  

26 June 09 at 10:36 AM
# Ramil said:

why Microsoft did not use ribbon UI in Visual Studio 2010

like Office 2007 and 2010

22 July 09 at 7:44 AM
# David Berg said:

Changing to a Ribbon UI would require a substantial rework of the UI and it's not clear that Visual Studio would benefit as much as Office (I like it too).  If you've got a lot of thoughts on why a ribbon UI would make you more productive, you might want to post them over on Jason Zander's blog or Soma's blog, as they're going to be much more involved in that decision than we will.  (If you have thoughts on why a Ribbon UI would make VS faster, then by all means, post them here.)

Changing to a Ribbon UI would be pretty disruptive.  Given that we're already replacing the editor, the shell, and completely reworking the multi-targeting system, I doubt that we could have handled a Ribbon UI in this release.  While it might seem easy to rework the toolbars into a Ribbon UI while we're replacing the shell, it's not.  That's because a lot of effort around the shell goes into making sure that the new shell has similar APIs and performance to the old shell, to minimize the disruption.  Changing to a Ribbon UI would have substantially increased the disruption around changing to the new shell.  It's really best to do those type of changes in stages.

22 July 09 at 9:02 AM
# Ryan said:

I'm surprised at Microsoft.

I'm running a web server, lots of tools, services, and apps to help me develop programs.  These are all in addition to all of the instances of Visual Studio that I may be running.

The above reccommendation "So the general rule of buying systems still applies – spring for as much memory as you can afford.  It’s hard to have too much memory" is heartily heard.  I have 4GB, on a (sigh) 32-bit operating system.  So, I can only use roughly 3.2GB of it.

I have to constantly watch my memory usage to ensure that I'm not out (thrashing my HD by paging).

So, I've followed the recommendations by getting as much Memory as the 32-bit OS allows.

Now I'm waiting for a 64-bit version of Visual Studio so that I can move to a 64-bit OS?

I could move to a 64-bit OS now, but I have heard stories of a 50+% performance penalty running Visual Studio on such 64bit OSes.

How long am I going to have to develop on a 32-bit OS?  Well, probably until Microsoft ports VS to 64-bit.

At some point I'll probably stop waiting an run a 32-bit OS on a Virtual PC (or on Windows 7's "Windows XP Mode").  Too bad VS is not written for the current OSes...

29 October 09 at 1:51 PM
# David Berg said:

Ryan,

The 32 bit VS runs just fine on a 64 bit OS.  I personally run 64 bit OSes at home and work.  I don't see a 50%+ performance penalty.  And if you do run VS on a 64 bit OS, you'll pick up an extra 2GB of VM (on a 32 bit OS VS gets 2gb of VM, on a 64 bit OS it gets 4GB).

You can go the virtualization route, but it's not necessary and will probably hurt your performance, so I wouldn't do it unless you have a really good reason.

Dave Berg

29 October 09 at 2:44 PM

Leave a Comment

Comment Policy: No HTML allowed. URIs and line breaks are converted automatically. Your e–mail address will not show up on any public page.

(required) 
(optional)
(required) 

  
Enter Code Here: Required

About David Berg

David runs Microsoft's Developer Division Performance Engineering Team. Prior to joining Microsoft he was CTO for a retail software company, a software engineer at Borland, and ran his own company doing custom software development.
Page view tracker