Nitin has posted 391 posts at DZone. View Full User Profile

Is Java 7 ready for the multicore revolution?

03.27.2008
| 21266 views |
  • submit to reddit

Henrik Engström doesn't think so. In a recent blog entry, he argues that "the new programming languages must have support to handle many-cores built into the language rather than adding these important features as APIs later on." 

In its early days, few probably could've foreseen the impact that concurrency and multicore programming were going to have on the Java programming model -- all this, driven by the rapid commoditzation and increasing power of processors. But as the JVM iteself evolves to support multiple languages, languages like Scala might become the language of choice for concurrent programming.

If improving application performance is the real question here, then perhaps Engström is right in suggesting that I/O and memory management may be the real bottlenecks, not necessarily how many processors we throw at the problem.  He references Brian Goetz's article Java theory and practice: Stick a Fork in it,Part 1, which talks about the new fork-join framework which will be part of the java.util.concurrent packages coming in Java 7:

"Server applications typically run many more concurrent threads, or requests, than there are processors available. The reason is because in most server applications, the processing of a request includes a fair amount of I/O, which does not require very much of the processor. (All network server applications do a lot of socket I/O, as requests are received via sockets; many do a fair amount of disk (or database) I/O as well.) If each task spends 90 percent of its time waiting for I/O to complete, you’ll need 10 times as many concurrent tasks as processors to keep the processors fully utilized. As processor counts increase, there may not be enough concurrent requests to keep all the processors busy."

All this begs the question, are we even going to know how to use all this new processing power available to us as part of the multicore revolution?

It probably doesn't matter much to folks like Daniel Lemire who believe that there is no upcoming multicore revolution in computer programming. In fact, he argues that for most large enterprises, the biggest performance bottleneck really lies at the data tier. Moreover, many of the "hard" performance problems can be solved by frameworks like MapReduce and Hadoop and by partitioning your storage tier.

Nevertheless, Java 7 is certainly priming itself for the brave new 'parallel' universe that will be ushered in by the multicore revolution. Also, when Microsoft and Intel invest in something, you can bet that a tidal shift is just on the horizon.  The two companies recently announced a joint venture to invest $20M in parallel computing.

What do you think -- is multicore programming going to cause a radical shift in how we build enterprise applications?

 

Published at DZone with permission of its author, Nitin Bharti.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Ronald Miura replied on Thu, 2008/03/27 - 11:44am

This whole idea of Java being 'multicore-ready' is crap. Ease of programming in multicore environments isn't about making span threads easy. The problem with parallel programming is not syntax, is state. Java (and most OO languages out there) has nothing to enforce separation of contexts between tasks, and it ends up being just a matter of pure discipline of the programmer. (Ironically, old-fashion structured languages would be probably more multicore-friendly, because they mostly pass parameters by copying values instead of passing references)

A possible solution to this is a complete paradigm shift, like made in Erlang model or Scala's actors (pure message passing). Or maybe making mainstream JVMs JSR-121 (Isolates) -complatible.

But, even then, I think parallel programming is just not for the so common code monkeys. They will always need something to handle threads for them (like Servlet and EJB containers) and let them to think linearly. And they will always have problems with Swing's threading model. And if they try to use these 'fork-join' or 'map-reduce' libraries, or just 'plain old threads', they will always struggle and complain, and will write thread-unsafe code that will eventually crash, and will blame Java for it. Well, that's life, I guess... -sigh--

Artur Biesiadowski replied on Thu, 2008/03/27 - 12:42pm in response to: Ronald Miura

[quote=ronaldtm]

A possible solution to this is a complete paradigm shift, like made in Erlang model or Scala's actors (pure message passing). Or maybe making mainstream JVMs JSR-121 (Isolates) -complatible.

[/quote]

JavaSpaces/GigaSpaces offer quite interesting solution here. They are using the object space as a message bus between stateless modules. Obviously, there is some overhead, but you get quite good scalability/load balancing and redundancy as needed - plus design of the system becomes a lot easier.

You can start with local spaces, to facilitate message passing between multiple cores/CPUs and then scale to distributed processing with only a configuration change and same code. As the extra benefit, you can also share bigger chunks of stateful data (not messages) between the machines using same technology.

I think that enterprise world will manage the 'multicore' problem. Already a lot of applications is multithreaded and it doesn't matter so much if you run on 16 single core SparcIII, or 4 quad core Intel. I see the biggest problem in things like games, where probably Erlang-like model is not fitting the requirements well. There, you work constantly on shared state, 'rendering' different aspects of it to the image, physics simulation, AI, game logic, networking. If you will consider heterogenous execution model (CPU, GPU, physics acceleration card, various console-specific units), it becomes ever nastier.

Ronald Miura replied on Thu, 2008/03/27 - 1:27pm in response to: Artur Biesiadowski

[quote=abies]I see the biggest problem in things like games, where probably Erlang-like model is not fitting the requirements well. There, you work constantly on shared state, 'rendering' different aspects of it to the image, physics simulation, AI, game logic, networking. If you will consider heterogenous execution model (CPU, GPU, physics acceleration card, various console-specific units), it becomes ever nastier. [/quote]

Games traditionally use single-thread model. So, they probably will have to review all their current architectures to accomodate this multi-core reality (where single-cpu clock rates increasing seems to be hitting its limit). And it will be an architectural change, not a language syntax change, that will solve this problem.

Alex(JAlexoid) ... replied on Thu, 2008/03/27 - 2:26pm

  Until we have states and interdependent data it will not be easy to create a language that has multithreading "woven into it's fabric". So basically just syntax change will not be enough. We need new brains for human kind, since we all think of things as stateful. And therefore it's the smart people's chance to differentiante from the code monkeys taht can do Java.

   Games are not that hard to paralelize... Since you only need to propagate data between modules as fast as a person can react, no faster. It's when you need to do 10's of thousands transactions per second, what is where it gets really tricky(in current state of things though). Split up data and you got yourself massive parallelism.

Nikita Ivanov replied on Thu, 2008/03/27 - 6:19pm

I think we (the article and some recent posts) tend to overcomplicate the issues. Frameworks like GridGain/Hadoop/GigaSpaces/Coherence already solve the problem on multi-VM environment and upcoming fork/join extension in Java 7 will solve it on language level. I also hope that Java 7 compiler/VM will be better suited for multi-core CPUs.

There are always going to be edge cases when none of the above will provide optimal solution. But this is typical 80/20 rule. I also believe the parallelazation is too complex of a concern to be put in language (look at Erlang, for example, of how things can go wrong).

Best,

Nikita Ivanov.

GridGain - Grid Computing Made Simple.

James Imber replied on Fri, 2008/03/28 - 3:15am

You guys seems to forget the desktop applications. Today I have a CPU with 2 cores and I'm depressed each time I see some swing application using 100% of one core and 0% of the other core... My computer could potentially complete the task in 50% less time if the program took advantage of both cores. But of course, as a programmer I know that it would be extremely hard (but not impossible) to split some simple tasks. In the end it would take much more time to code for a multicore cpu (and create many bugs) at least for desktop applications.

I fear that the situation will only get worse with time. When CPU's will routinely come loaded with 4-8 cores my desktop program will still be only able to use a single core (25% - 12.5% of the CPU power!).

Mark Thornton replied on Fri, 2008/03/28 - 4:03am

I have been making a fair bit of use of the prototype fork join framework and other techniques to get my two and four core desktops running near 100% cpu for sustained periods. Of course not all tasks are amenable to this treatment.

Chris Merrill replied on Fri, 2008/03/28 - 11:45am

What a load of bullxxxx - The post author has sensationalized what the the blog author has said...and both appear to have an extremely narrow view of what Java is. Java has flourished on multi-processor servers for years. The Java-based software I develop every day utilizes multi-processor and multi-core architectures transparently. Are there certain frameworks that have single-thread limitations that limit that framework's ability to use multi-core architectures? Clearly so, but those are choices made by the framework developers (and frequently the underlying OS), and have nothing to do with Java as a whole. Guess what? The Windows File Explorer is single-threaded for many operations. Does this imply that Windows is not ready for multiple processors? No.

The blogger doesn't even appear to know the difference between Tomcat and Apache. sheesh.

taranfx fx replied on Sun, 2009/08/30 - 5:39am in response to: Ronald Miura

The most noticeable thing about Java 7 is the performance. And i wrote this blog on  Benchmark 1.5 1.6 1.7 which shows where we are heading

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.