Skip to main content

Closures as a Response to Multi-core Processors?

Posted by editor on November 25, 2009 at 8:24 AM PST

I was surprised to read, in Mark Reinhold's post "There's not a moment to lose!", that the primary objective, or use case, behind Sun's sudden desire to add closures to Java is multi-core processors. I mean, it's not like multi-core processors are a brand new development, a stunning revolutionary technology that has popped up out of nowhere!

Mark cites Herb Sutter's March 2005 Dr. Dobb's Journal article "The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software" in making his case that closures are needed now in Java. But that article is almost five years old at this point. Multicore isn't news anymore, is it?

Still, it's quite true that, while the typical new PC even for home use has 2 or 4 cores today, very little mainstream software has been redesigned to take advantage of multiple cores. Rather, the gain in speed comes from the possibility of an individual core being fully tasked running a single foreground application, while the other cores take care of background and OS processes.

It has actually surprised me a bit, how slow companies have been to develop multithreaded apps. Of course, many of the most commonly used desktop applications are highly interactive. In that case, much more time is spent by the user deciding what to input or where to move the mouse than is spent by the computer processing the user's requests for action. And, also, much of people's activity as they sit in front of their computers today actually takes place on a remote server somewhere -- so, again, when your computer is serving as a smart terminal, having that terminal application (for example, your browser) multithreaded isn't really critical, since much of your wait time is likely to be your network connection anyway. But, still, it's hard to picture a future where 16 and 32 core PCs are inexpensive and the marketplace is not demanding that those cores be utilized to speed up our computer-based activities. Has there ever been a time when we thought our software applications ran too fast?

A couple years ago, I participated in the launch of Intel's open source Threading Building Blocks (TBB) project. I was the community manager for that project for its first nine months. TBB is a C++ threading library. It's objective is to facilitate development of multithreaded C++ applications that can take full advantage of multicore processors. In some cases, existing software can be "parallelized" automatically by wrapping the code in TBB structures. TBB represents a significant and formidable advance for the C++ world, when it comes to development for multicore/multiprocessor systems, in my view.

My 107 blog posts about TBB and multithreaded development in general are still public, if anyone's interested. I even engaged in a small debate with Herb Sutter over whether "superlinearity" in multithreaded development is really possible (see "Superlinearity Is Impossible; We Just Don't Always Think Correctly" and "Superlinearity and Algorithmic Complexity; or, My Interesting Conversation with Herb Sutter"). So, you can see that development for multicore systems is something I've spent a lot of time thinking about...

But, getting back to Java and closures: Mark links to the "Connection with closures" section of an IBM Developer Works paper. This section talks about ParallelArray, which "offers a nice way to declaratively specify filtering, processing, and aggregation operations on data sets, while also facilitating automatic parallelization." Later on:

one of the arguments in favor of closures is that it makes expressing small snippets of code - such as filters, mappers, and reducers in ParallelArray - much more compact.

Looking at the code snippet that follows (Listing 4 in the article), I am indeed reminded of some of the TBB constructs I was working with a couple years ago. The code snippet is part of a set of routines that compute the maximum GPA for graduating students. The snippet uses the closure syntax from the BGGA proposal. Here's the code:

double bestGpa = students.withFilter({Student s => (s.graduationYear == THIS_YEAR) })
    .withMapping({ Student s => s.gpa })

Needless to say, for me, the entire closures discussion is becoming very interesting. But, I'm still a bit confused. For example, Java has had threads for a very long time. So, I would have thought that the concept of programming for multicore processors would have received a lot of attention in the past. And it's still confusing to read that suddenly right now is when Java must react to the advent of multi-core processors. This wasn't being thought about four or five years ago? Also, I see almost nothing about multi-core processors and multithreaded programming in the primary closures proposals. So, as I say, I find closures as a response to the multicore challenge, at this time, a quite surprising -- but nonetheless very interesting -- development.

More to come!

In Java Today, Mark Reinhold leads the closures charge with There


Hope it pans out this time

While I'm very much in favor of adding language support for function objects, I'd like to point out that with the right set of libraries, you can already get most of the way there. This could already be expressed as

max(transform(filter(students, compareProperty(Student.class, "graduationYear", THIS_YEAR)),
getProperty(Student.class, "gpa")))

A lot of the readability improvements are due more to extension methods rather than closures. Adding extension methods would change this to

students.filter(compareProperty(Student.class, "graduationYear", THIS_YEAR))
.transform(getProperty(Student.class, "gpa"))

the rest of the tangible improvement is in adding direct support for function literals and no longer needing reflection based primitives.

If there's no time to lose, there's no reason to wait. With support in the language, you'll get better typesafety, compile time checking of properties rather than the runtime checking that this example provides, and more readable syntax. That said, anyone who really needs this should already be most of the way there with existing libraries.