Skip to main content

Speculations for 2010, Part 2: The Multicore Challenge - Is It Still Relevant?

Posted by editor on December 31, 2009 at 9:45 AM PST

Ever since Mark Reinhold's announcement at DEVOXX that Java 7 will include closures, I've found myself thinking a lot about where we are headed with respect to desktop computers, how Java fits into that, how the cloud fits in, etc. It makes sense that the future will include many-core processors, which will be available even in budget-priced systems. What will we do with all those processor cores? Well, that depends on the nature of the software we'll be running on our systems.

In Mark Reinhold's Closures for Java post, which was written soon after the DEVOXX announcement, he said that it is because of the emergence of multicore processors that closures are needed in Java. Why? Because:

Working with parallel arrays in Java, unfortunately, requires lots of boilerplate code to solve even simple problems. Closures
can eliminate
that boilerplate

I was initially somewhat confused by these statements, because I thought Java had everything it needed for efficient use of multiple cores in its threading libraries. The results of our (unscientific) November poll Is Java's parallel programming support sufficient to meet 'the Multicore Challenge'? suggest that quite a lot of developers (34%) believe the same thing. 18% thought that with the addition of closures, Java will have adequate parallel programming support.

In my recent interview with Adam Bien, I asked:

Do you agree that adding closures to Java is needed to enable Java to meet "the Multicore Challenge"?

Adam's response:

I'm not sure about that. You can run perfectly scalable code right now with plain Java. Closures could make it more convenient - but it isn't impossible to write multicore code without them.

But -- another question is: are we moving away from desktop applications anyway? Look at the purchase of Playfish by Electronic Arts:

The acquisition of Playfish falls in line with EA's desire to be more than just a developer for traditional gaming platforms, like consoles and the PC. The company said in a statement that the acquisition "strengthens its focus on the transition to digital and social gaming."

It's not "we want to diversify into social gaming"; rather, it's taken for granted that social gaming is replacing digital gaming. And where does social gaming actually take place? In the cloud, not on your multicore desktop.

So, then, is the Multicore Challenge becoming a moot point as people migrate ever greater shares of their computer-based activity into the cloud? My little HP Mini 1120NR netbook does a fine job with FaceBook, Twitter, and BlogBridge; it's great at conferences; I can even set up the home page and write my blogs on it (though I prefer my larger desktop screen for that work). Sometimes I even turn off my quad-core desktop (500 Watt power supply) and use the Mini for periods of hours, to save on my electric bill (also, in the winter, to minimize the chance for the quad-core to overheat, which happens on occasion when the corn stove we use to heat this end of the house is running).

Then, too, there's the iPhone, Google's Android platform, etc. Larry Ellison even hinted at the creation of an Oracle/Sun phone at JavaOne. At minimum, Oracle/Sun would be very active in developing software for mobile devices. While I remember Ellison saying these things, I'll point you to a Wall Street Journal article for reference. Talking about mobile devices, Ellison said:

"I don't see why some of those devices shouldn't come from Sun-Oracle."

And he also said:

"I think you'll see us get very aggressive with Java and developing Java apps for things like telephones and netbooks."

So, then, might the desktop computer itself be kind of on the way out? Probably not, but if the great majority of apps people want to run actually perform their processing on remote server farms, with the local activity being simply a user interface that sends out requests and receives and displays responses, how much of a need will there be for heavy-duty multithreaded applications that run locally? And, thinking about Java, doesn't Java EE 6 provide everything we need on the server farm end?

Just some thoughts...

Happy New Year to all who observe the Gregorian calendar!

In Java Today, Kirill Grouchnikov presents Pushing Pixels: the best of 2009:

The year is coming to an end, and it


Why closures for parallelism?

Closures make parallel programming easier because it forces the software developer to do things without intermediate or mutable state (or as John said, functional programming). The more you can keep state localized to a function being applied across a sequence, the easier the job becomes. This is why map-reduce is so successful.

For Java, however, they're not entirely necessary -- like many other language extensions, they are merely syntactic sugar.

People probably don't remember much from the "bad old days" of MPP systems from the early 90's and late 80's. Way back then, Lisp and its closures were the primary programming language of the Connection Machine (as well as others). Consequently, some support for functional programming and immutable state (maybe not to the degree of Haskell) is overall a good thing to exploit multicore.


parallel programming on desktop only?

Maybe I'm missing something, but you're thinking parallel programming (multicore) is relevant only for the desktop? Wouldn't we expect even greater parallelism on the server? 32-, 64-, 256-way servers, massive parallelism? Or are we just assuming that our environment will always be Glassfish/JBoss/Websphere and those platforms will handle the parallelism with something like a processor per servlet? Aren't there other benefits to closures besides removing boilerplate for parallel code? Easier functional programming, for instance? John.

parallel programming on servers already exists

The reason I ignored servers is that I think we already do have quite effective capability to develop software that runs on hundreds or thousands of nodes, and on multiprocessor systems, running enterprise-level applications (where the processing can be readily divided into tiers), with Java EE. 

I think the term "Multicore Challenge" has most often been used in reference to desktop systems: single processor computers can't get faster because Moore's Law is breaking down, so the only way to make desktop computers more powerful is to add more processor cores -- but to take advantage of the multiple cores, applications must be multithreaded. Hence, it's a crisis for companies that develop desktop software, a "challenge."

Closures would be another tool in the developer toolbox, and would make certain tasks simpler to accomplish. How they're implemented will determine how useful they will be in solving specific problems. Mark Reinhold, however, explicitly stated that the reason closures are needed is because of the Multicore Challenge. This statement has had me thinking and wondering ever since he made it.

Why couple multi-core and desktops?

The shift to multi-core will catch up with cell-phone-sized machines soon enough, maybe three to eight years out. I suppose you could just keep fleeing to smaller few-core machines for a while, assuming the JVM stays under you.