Virtual Machine Plumbing

There's a bunch of cool research going on make parallelism implicit through under the hood plumbing. This means the programmer can merrily go on her way not caring about deadlocks, race conditions and other nasty stuff, but instead concentrate on how their program should compose together with a known expectation of concurrency. Software Transactional Memory is one such implementation, and there's a fair amount of love and hate around for the idea.

And while STM does provide an elegant way to enforce composability and modularity (which is a nice way of saying that the programmer must declare their program invariant's up front), it's not clear if you can broaden the concept to encapsulate and protect most of the OO imperative world - the broader you go, the more rules you need.

I'll leave it as an exercise to the reader to go off and understand some of these issues - the journey is definitely rewarding.

Better OS Level Parallelism

The elephant in the room is that for the most part, apps like Outlook don't really do all that much hard data processing and number crunching. Sure, search, indexing, spam filtering etc are computationally intensive, but for the most part, users are waiting for that, they're sitting around waiting for Outlook to slurp up data from the disk. IO (especially blocking IO) is concurrency's best and worst friend. You can spend IO time doing something worthwhile with the processor, or you can spend it waiting for the data it's off collecting.

It'd be great if we had better tools and constructs to make designing for IO bottlenecks easier. I'm not exactly sure what we need, but we could start with some fundamentals like hardcore documentation.

I'd also like lighter code encapsulation constructs (something lighter than your traditional Win32 thread) that are fully supported. Fibers are okay, but I don't have a brilliantly simple managed API, and I don't really want to write a scheduler either.

GPU's, Custom Sockets and More Fun Stuff

When I saw this I got a bit googley eyed. Custom silicon to do instruction crunching on the same bus as your general purpose x86/64 is powerful and an interesting enabler. Not so long ago, if you wanted to do serious domain specific computation (financial modelling, simulations etc) you'd crack open your favourite Verilog compiler and start buiding a custom processor. Soon, if you need that extra FPU power you can go and buy the latest NVidia card and start coding away.

Of course, you'll need great libraries (stuff that looks like what we consider common today), or, have the compiler/libraries figure it out for you. There's no reason why a PLINQ operation over an array of doubles can't be offloaded on to the GPU?

• The World's Eight Most Excellent Software Adventures, Part One
• The World's Eight Most Excellent Software Adventures - Part Two