I’m up in Seattle right now at TechReady, an internal Microsoft conference with technical presentations and information for folks in the field (like me, of course). So … with that said, there will likely be the occasional post this week about something that I’ve seen up here that I can actually talk about.
The first thing is the parallel extensions to .Net. You can get a preview of these at the MSDN Parallel Computing Center. Keep in mind that it’s a CTP (that’s lower on the food chain than an official Beta) – and an early CTP at that – so there will be bugs and the performance won’t be as good as the final, RTM release. Also, be forewarned: the API may (OK, let’s be honest, it will) change before the RTM release. Still, it’s a good thing to play with because it gives you a good idea of where we’re going to enable developers to make traditional very hard things easy.
The hard thing that the parallel extensions address is multi-threading where concurrency between threads is required. Doing this right is actually a pretty significant undertaking and it’s really, really easy to get yourself all messed up and tied up in knots. And multi-threaded code has some additional challenges when it comes to debugging. Then there is the issue related to dividing the work to be done up among the different threads.
In the days of single core processors, where most applications weren’t running on multi-proc boxes, multi-threading was something that could help with UI responsiveness, but let’s be honest … work wasn’t really done concurrently. Sure, Windows would schedule your threads at different times and in some cases you could actually get somewhat better performance than if you used a single thread, but you didn’t nearly have the number of issues (and the challenges) that you have with multi-core processors. And in this day and age, multi-core processors have become very much the mainstream, entry level processor. I just looked at a Major Computer Manufacturer’s website and found that only the very, very lowest end systems had single core processors … and a dual core desktop could be had for as little as $359 (sans monitor, of course). Intel has dual-core Celerons (their “value” processors). And, of course, triple-cores (from AMD) and quad-cores are available … and I saw a desktop with quad-core for as low as $729. If, like me, you build your own systems from parts, a dual-core processor can be found for around $50 and a quad-core can be found for about $175. Eight-core processors aren’t going to be too far down the road (octo-core?) and I really doubt that it’ll stop there. Oh, and lest I forget, Intel’s HyperThreading technology looks (and in many ways acts) like multiple cores.
In order to take full advantage of this powerful hardware, developers need to rethink some of things that we’ve traditionally done with an eye towards multi-threading and parallel processing. It is a huge change to much of what we’ve done for years and it sometimes hurts the brain to try to follow the way the code executes … a single line of code could be executing on, say, 4 different threads literally at the same time. Yes, the Windows scheduler is still involved scheduling the threads for execution but now it’s got 2, 3 or 4 processors to execute the threads on. It’s not just appearances anymore. The parallel extensions to .Net make this dirt simple (I like dirt simple). It can be as simple as adding AsParallel() to a Linq query. Or use Parallel.ForEach() rather than a traditional for … each loop.
The demo that was showed did a couple of different operations (find, sum, etc) and compared the performance of the parallel with the non-parallel version of the same code. Even now, in the CTP, where the performance tuning hasn’t been done to any real extent, there was an improvement of 3-4 times. Pretty impressive.