Michael Seuss ponders one of my favorite questions: How much of the software industry will have to deal with the concurrent computing [opportunity]? He hits the vital points:
- 2, 4, and maybe 8 cores may be usefully exploited by system services (anti-virus, disk indexing and searching, etc.), but when you get beyond that, any program for which performance is any kind of issue simply cannot ignore the capacity (this is why I distinguish between our current "multicore" transitional phase and the coming "manycore" era).
- Media programming (games, A/V processing) have an essentially infinite appetite for processing
- The manycore era provides an opportunity for new types of functionality. He mentions concurrent semantic analysis of your input, both typing and spoken, and the accumulation of context documents. For instance, as I type this, my computer might be gathering all my blog posts, OneNote notes, source code, etc. relating to concurrency. (And then wouldn't it be cool if it offered them for my perusal, maybe with, I dunno', a goggle-eyed paperclip?).
But I think the \$64 question is whether such services will be provided in a service-oriented, cross-application manner, or whether it will be the case that we find broad opportunities for them within applications. For instance, mail programs and word processors have had search functionality for a long time, but if you were designing such a program from scratch, you would probably be better advised to say "Hey, I won't implement a complete search subsystem, I'll just make sure I can be indexed by Windows and Google Desktop Search. If I want to add value, I'll layer on top of those systems if at all possible."
Conversely, if you had some powerful new value proposition (semantic analysis, task recognition, visual input), wouldn't it be vastly better for you and your customers if you could provide it to applications other than those that you happen to have written? In other words, of course value in the manycore era will derive from increased parallelism but maybe that parallelism will still be very coarse-grained. Maybe software organizations will face a choice: "Either develop client-oriented value with the best practices of "traditional" non-parallel development or develop broader, system-oriented value using whatever is the emerging set of best practices for system-level parallel development." Maybe that choice will become increasingly orthogonal.
Now, the final part of the thought experiment is this: if that scenario is reasonable, what kind of platform services / APIs would one desire?