Just to make sure, I went and downloaded the trial version of Windows Server 2008 from the Microsoft website. I installed it on this 8-core Opteron workstation with 8 GB of RAM that AMD sent me awhile ago for doing multithreading and performance scaling stuff. I installed version 3.22, then updated it to 3.30 Beta 2 to make sure that would work, and sure enough it does!
I’m not surprised, but I felt the need to verify this anyway🙂 I’ll make sure the website lists Windows Server 2008 as a supported OS on the next update.
As an interesting side note, having access to systems with 4 and 8 cores has brought up an interesting performance problem in Paint.NET, and key insights for optimization and design going forward. In the past I have done a lot of work to ensure that certain key rendering code is multithreaded, and as such going from dual- to quad- to octa-core has yielded healthy performance gains. Even on these systems, quite often, I just can’t get CPU usage all the way up to 100%! Just look at the screenshot above: even on a very compute-intensive effect such as Julia Fractal, at highest quality, on a 16,000 x 9,000 pixel canvas (yes that’s 144 megapixels), the CPU usage is bouncing around and clearly not anywhere close to full performance. I guess the silver lining here is that power consumption is a little lower as a result, eh?
Even on my personal quad core desktop, I’m lucky if rendering a large gradient can hit 65% CPU usage. There’s a lot of wasted performance by having the rendering pipeline set up the way it us. Hopefully my talks with the .NET Parallels Extensions team will help me to improve this situation, while also putting some extra “real world” code in their laps to play with. With the current design, I wouldn’t be surprised if Paint.NET could barely keep a 64-core system more than 15% busy.
Also, I’d like to point out another exciting project related to things like concurrency and parallelism: Microsoft Live Labs Volta. I had a meeting with them last Tuesday and their approach to asynchronous, stream/event-based programming just blew my mind. Their project as a whole is actually targeted for some kind of simplified web cloud tier-distributed development*, but they have a concurrency runtime which could prove extremely valuable for the two rich client/desktop applications that I currently work on**. I’m very excited – anytime somebody sends me a meeting request titled, “Discuss monads and composition in the context of asynchronous computations,” I am reassured that there are still smart people out there working on cool things. I’m not sure how much I can discuss publicly about their stuff, but once I get any kind of green light I’m sure I’ll start gushing. I’ll leave you with one quote from the discussion that I actually made sure to write down, as it embodies something I’ve been struggling and searching for with respect to this type of coding:
“By construction, these things are correct.”
More on what that actually means later. I’ve got a lot of thoughts on parallel/asynchronous, concurrent, and functional programming and how it relates to multithreading, correctness, and performance. Hopefully I can put some of that into writing!
* This is not an exact definition🙂
** That would be 1) Paint.NET, and 2) the other one that I work on at Microsoft (“my day job”).