Imagining uses for multiple cores

Along with some other cleanup and infrastructure tasks, one of the things on my to-do list is to update the topics wish-list portion of the java.net Writer's Guide. There are probably a few topics that were priorities for us in the past and that just haven't attracted interested writers (e.g., the gaming API's). And on the other hand it's naturally important to maintain a current, modern view of where computing and development trends are today and where they're going, and try to get ahead of them.

On this last point, I've been wondering about developing for the new multi-core era. Oh, I know, Java has great threading, so we're fine. Yeah, to a point, as long as what you're doing is handing off servlet handlePost() calls to whichever core has the most bandwidth, and you have at least a passing understanding of your resource contention issues and concurrent programming (and recent back-channel e-mails with Java concurrency gurus have convinced me that almost nobody truly handles concurrency correctly, myself included). But overall, yeah, the major server-side frameworks can be expected to benefit from more and more cores on more and more CPU's.

But what about the desktop? I can buy an eight-core Mac Pro (well, not on my budget, but I digress...), but what good is it going to do me? Artima recently ran an item based in large part on Jeff Atwood's assessment of desktop app performance running on 4 CPU cores. In many cases, he got no improvement at all in going from two to four cores: "Beyond encoding and rendering tasks which are naturally amenable to parallelization, the task manager CPU graphs tell the sad tale of software that simply isn't written to exploit more than two CPUs."

Think of this from the point-of-view of the Swing developer. In Swing, anything you do that touches your GUI -- repainting, changing data in the models -- must be done on the AWT event-dispatch thread. Lots of developers implicitly do all their work on this thread until and unless they manage to do something that takes just long enough to cause noticeable lag in their GUI, and only then do they consider threading off the work and calling back in with a SwingWorker. Swing apps probably aren't going to gain much from multi cores because parallelization goes against many of the natural inclinations of Swing programmers.

And this, I think, would make for a good article if someone is solving these problems. Are there new approaches that would make Java desktop apps more amenable to parallelization? Rather than put all your non-EDT work in one thread, is there maybe a way you could split that work into parallelizable tasks, and then coordinate their completion? On the other hand, are there really that many desktop tasks that are really that expensive? Is the wait-grind-wait cycle actually appropriate for user-facing software architectures?