Multi-core Processors: Good or Bad for Java

Posted by Scott Delap on Nov 27, 2006

Sections

Development,

Architecture & Design

Topics

Java ,

Performance & Scalability ,

Programming

Tags

Multi-threading ,

Java EE

Two recent items on the internet have looked at the topic of multi-core processors and Java. A recent article by Randall Scarberry of JavaWorld.com looks at using the Java concurrency API to write multi-threaded algorithms. Billy Newport of IBM also recently written a blog post detailing how Java may not be well suited for multi-core processors.

The JavaWorld article looks at the process of taking a single threaded algorithm and converting it to be multi-threaded. The basic approach is outlined as:

1. Develop a single-threaded, sequential, robust, and clearly organized version of your algorithm. If you're reading this article to speed up something that exists, you may already have this step covered.
2. Identify the subtasks. Examine the algorithm to identify the discrete stages. This shouldn't be difficult if you performed Step 1 adequately. Each subtask probably has its own method, or at least a clearly-delineated block of code. If you have difficulty identifying the subtasks, you probably need to understand the algorithm better or reorganize your code. In that case, return to Step 1.
3. Benchmark the algorithm. In other words, time the identified subtasks to determine the fraction of time consumed by each. This should be a trivial matter of adding some timing and output statements.
4. Delegate the most time-consuming subtasks to a thread pool. Now we come to the most difficult part: reorganizing your code so the slowest subtasks are performed concurrently by multiple subtask threads. Luckily, two utility classes in java.util.concurrent greatly simplify the process.

The article then continues by taking a K-Means algorithm and multi-threading it using java.util.concurrent API features such as ThreadPoolExecutor and CyclicBarrier.

A TSS discussion on this article generated a number of interesting comments of multi-threading in respect to JEE.

...First of all, most J2EE applications are heavy transaction based applications. At least the ones that I work on in the financial industry. Because of the J2EE specification, you can't be spawning threads. You also can't have multiple threads accessing the same transaction. It just doesn't work.

A way of breaking up large chunks of work into smaller managable is to use JMS to leverage the container to do the multi-threading for you. But once again, you have to take into account the transactions and keep track of those chunks of work in different transactions.

J2EE applications already take advantage of multi-core, multiple CPUs already. Every applications server uses some sort of multiple threads, weather that is in an execute queue or (gasp) spawning a new thread for each connection.

Billy Newport responds:

...I beg to differ. If only the simple threading models offered by typical containers were adequate for the diversity of applications out there. I added the WorkManager spec to WebSphere and then standardized it using the commonj APIs for exactly this purpose. There are clever people out there who can be trusted to write threaded code and commonj lets them build J2EE applications using a threading model thats appropriate for the application rather than the boiler plate models provided by the vendors. Yes, JMS can be used as a way to do it also but it's millions of times slower than native threading...

This comment is followed by a blog post on why multi-core may actually be bad for Java. Among the items he notes:

• Java likely has a longer path length than languages like C and clock speeds won't help with this.
• JavaEE promotes a simple threading model for applications
• Garbage collection remains heavily dependant on clock speed for small pauses.

1. Back to top

   Multicore on the desktop

   by Fabrizio Giudici

   I'd just like to point at my blog on java.net where I dealt with the multi-core + Java, more in a desktop perspective.
   
   I've seen a bunch of blogs on this subject, each in a slightly different perspective, in a few days. It's good that people talks about it, as it will be something to deal with in the near future.

   Reply

2. Back to top

   Re: Multicore on the desktop

   by cstar cstar

   The problem is not multi-core is good or bad for Java.
   The top of the line for IBM AMD and Intel are all multi-core. Java must adapt if necessary to run on these architectures.

   Reply

3. Back to top

   Re: Multicore on the desktop

   by Billy Newport

   Hit the nail right on the head. Things and assumptions are changing and there will be changes as a result. Hopefully, Java JVM JITs can be designed to optimise for the processor architecture where they are running as well as expected workloads.

   Reply

• Older >