In a recent JavaWorld article, Multicore processing for client-side Java applications, Kirill Grouchnikov explores the benefits of concurrency on the desktop, nothing that:

The consistent increase in single-core CPU speed that programmers could rely on for years is no longer available. This has been true for the server side for at least a decade, and now it's also the reality for client-side programming. Quite a few tasks easily lend themselves to being parallelized using new features in JDK 6.0, letting client-side applications take advantage of newer multicore hardware...

Multicore machines are the reality for client-side development. Failure to adapt will result in software that does not scale well on modern hardware. By identifying routines that lend themselves to parallelizing, your code can continue enjoying the advances of multicore machines.

However, this means switching your mindset from the sequential model to the concurrent model. The concurrent model doesn't only yield performance improvements; it also comes with its own set of best practices. If you want to achieve competitive performance and write software that scales with the hardware, you need to dip your toes in the concurrency pool.

To illustrate his point of scaling client-side performance with parallelism, Grouchnikov demonstrate how to take advantage of the concurrency utilities in JDK 6 to speed up array sorting by more than 30% on multicore hardware.

Existing Java collection-sorting routines ... perform no faster on newer multicore machines than on single-core machines. This might seem acceptable on smaller inputs, but the input domains for most real-world problems don't stand still. Moreover, developers and users rightly expect their programs to run faster on newer hardware.

When you call Arrays.sort or Collections.sort, the running time doesn't grow linearly with the collection size. On my machine, calling Arrays.sort on an array of 200,000 strings takes 490ms on average. An array of 400,000 strings is sorted in 1290ms—an increase in running time by factor of about 2.6...

The mergesort in the Arrays class [is a ] classic mergesort with a few optimization tweaks for corner cases. If the array size is small (seven or fewer with the current implementation), it reverts to the bubble sort. Otherwise, the array is split in half, and the same method is called (recursively) on both halves. After both halves are sorted, the code "merges" them (hence the name).

Grouchnikov points out that mergesort lends itself to parallel execution, and that modifying the mergesort in the current Arrays implementation is straightforward with the JDK 6 concurrency utilities:

You can easily see that increasing the CPU speed (number of operations per second) by a factor of two results in a matching improvement in the algorithm running time. This is the case because the mergesort is a sequential recursive algorithm that does exactly the same sequence of steps, provided the same input.... It doesn't explore the inherent concurrency of the recursive implementation. When the array is split in half, the sorting of the second half begins only after the sorting of the first half is done.

New concurrency utilities in JDK 6.0 come to the rescue, letting you perform these subtasks in parallel without any communication between them. At the end, when both tasks are done, the sorted halves still need to be merged together.

Grouchnikov presents his implementation in the article, and shows that the simple changes affecting parallel sorting results in over 30% increase in performance. He also notes, however, that the concurrent code ads a layer of complexity to sorting, and that the decision of just how much concurrency to use requires careful consideration.

What do you think of concurrency on the desktop?