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 })
    .max();

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’s not a moment to lose!:

The free lunch is over. Multicore processors are not just coming—they’re here. Leveraging multiple cores requires writing scalable parallel programs,
which is incredibly hard. Tools such as fork/join
frameworks
based on work-stealing
algorithms make the task easier, but it still takes a fair bit of expertise
and tuning. Bulk-data APIs such as parallel
arrays
allow computations to be expressed in terms of higher-level,
SQL-like operations (e.g., filter, map, and reduce) which can be mapped
automatically onto the fork-join paradigm. Working with parallel arrays in Java, unfortunately, requires lots
of boilerplate code
to solve even simple problems...

Robilad provides his latest OpenJDK roundup:

The JVM Language Summit 2009 took place in September. The first video of a full talk is now available on InfoQ, and it's Rich Hickey's keynote, "Are We There Yet?". John Rose has blogged about his paper on "Bytecodes meet Combinators: invokedynamic on the JVM" for the VMIL workshop at OOSPLA on the internals and implications of adding invokedynamic to the JVM...

Java Champion Alan Williamson talks about Server side Javascript with CFML:

I have always wondered why CFSCRIPT was never Javascript, but instead a half-way house. This is something I have spoken about before in various blogs and forums. I have made no secret of the fact that I have not been a fan of CFSCRIPT and feel it was a lost opportunity. Javascript has taken the development world by storm, with it now being one of the fastest growing languages out there. In short, there is a lot of Javascript talent out there, and I want them to be able to utilise this talent server-side, within CFML applications...


In today's Weblogs, Jan Haderka provides his devoxx roundup:

There was a bunch of good things to see at this years Devoxx. My personal highlights are ScalaTest (you definitively want to look into this when testing concurrency in any java code ... the best way to test different race scenarios I've seen so far). Another highlight was the amount of work done on JavaFX yet. The new UI for the clickable gui builder shown briefly by Tor ... surely you remember when Tor has shown this thing for the first time on JavaOne ... well, guess what, since then, the UI have been completely re-written and is using FX only. This language has a potential for building the slick UIs (and not only games, tho those are also very interesting ... check work by Rich and Jasper) ...

Remi Forax talks abou NIO server with continuation in Java:

Java VM embodies
continuations now
(not in production, in a hacking mode :),
This post shows how to write a non-blocking server with continuations...

And Harold Carr completed his Kynetx conference with Kynetx Impact Conference - notes - afternoon day 2:

1:00-1:45 pm
Show Me the Money!
by Kristen Knight, Kynetx VP Product Management

Monetizing cross-site, context-sensitive apps, revenue models, VAR &
Implementor business opportunities.

Wal-Mart
- generated their own warehousing and distribution infrastructure
  rather than depending on manufacturers or 3rd party distributors

Before Kynetx:
- search engines (3rd party) direct people to YOUR site
- website sales funnel

With Kynetx:
- consumer/community is center
- search engine, web-enabled devices, other people's sites, desktop, on you site...


In the Forums, kleopatra has a question about Appframework: how-to restore session state dynamically?: "Works fine for everything actually added to the demo app at startup. Problem are that the demo pages themselves are loaded and added only when selected. Any way to restore their state? And if so, how-to? BTW, in case you have not noticed yet:..."

ntimesc has a question Regarding stateful webservices: "Hi All, i have implemented stateful web servies using following mechanism enable a binding property at client side: ((BindingProvider)port).getRequestContext().put(BindingProvider.SESSION_MAINTAIN_PROPERTY, ..."

xclaim wonders how to stop/exit the mediabox: "hi. may i know how to exit the mediabox? for example i create a group inside that is the mediabox, but when i click the close button(custom button) it will go to the other group and thus exit the mediabox. current situation is..."


In our current Spotlight, Terrence Barr invites us to Check out Java Card 3.0 Connected Edition: Real Java, just really flat ;-): "Java Card 3.0 was released a couple of months ago – and the second update (version 3.0.2) is scheduled for December. If you haven’t paid much attention to Java on smart cards because you thought it’s not “real” Java – well, look again. It’s true that Java Card 2 was very limited in many ways – a testament to the kind of technology you had available on smart cards 10 years ago. There are billions of these out there today..."


The new java.net Poll asks What do you think about closures in JDK 7? The poll will run through Thursday.


Our Feature Articles lead off with Sanjay Dasgupta's in-depth article Simplify Native Code Access with JNA. We're also featuring Eric Siegelberg's Using a Service Delegate to Avoid MVC Controller Bloat, which describes how to maintain separation of concerns and avoid MVC controller bloat through the use of service delegates. And, our latest Java Tech guest column is Marina Kamahele's "Transparent" Panel - Mixing Heavyweight and Lightweight Components.


The latest Java Mobility Podcast is Java Mobile Podcast 90: Augmented Reality: Excerpts from the JavaOne 2009 Augmented Reality session with Kenneth Andersson and Erik Hellman of Sony Ericsson.


Current and upcoming Java Events:

Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.


Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.

-- Kevin Farnham

O'Reilly Media

Related Topics >>

Comments

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"))
.max()


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.