Kirill Grouchnikov's Blog

An article on multi-core client side development in Java

Yesterday JavaWorld.com published a new article titled "Multicore processing for client-side Java applications". You're welcome to take a look and let me know what you think. Here's a summary of the article:

It's a well-known fact that hardware companies are abandoning the race for single-CPU speed and instead are focusing on multicore processors. Despite the fact that many algorithms can be easily parallelized, most client-side Java code is still written for single-CPU systems. This article shows you how to fine-tune a core JDK array-sorting algorithm for improved processing speed of as much as 35%.

Comments

• Unfortunately the reality of Swings single-threaded nature prevents you from applying this type of technique to the sorting of a table model, or list model. It's great for pre-view data-only operations tough. I wish there was a way to say "EDT, cancel all pending events for a me because I'm busy right now. I'll let you know when I'm ready. Until then please paint me from my backing buffer." Or something like that. I guess that wouldn't work if you resized the component. We've had a lot of issues because you shouldn't update the model of a component from any other thread but the EDT. So all sorting and filtering has to happen on the EDT. When you have 100,000 or more records and complicated comparison rules you really want to use these types of techniques. I know the logical reasons for a single threaded model. I just wish there was a better way that didn't involve copying the entire data structure, sorting it in a separate thread(s), and moving it back to the model.

  Posted by: aberrant on September 28, 2007 at 05:55 AM

• This is interesting. Wouldn't it be possible to write a model in such a way that the sorting is separate from the fired events? Then, you sort the actual data by splitting the work between cores, and then in the "merge" stage you finally fire all the events?

  Posted by: kirillcool on September 28, 2007 at 02:59 PM

• OK, so what actually happens if you have a table model with say 100000 records and you sort it on multiple non EDT threads. If the EDT tries to display a row, it will get whatever row happens to appear (to its thread) to be in that position at the time.

  So What?

  When the sorting is done, simply fire a notification that the whole table context has changed. This will fix up the display to show the correctly ordered content.
  All that goes wrong is that the display may temporarily show something that doesn't correspond to any reality (e.g. some records may appear more than once). You could alter the colour of the table during such processes to indicate that it was in progress or perhaps apply some sort of blur filter (anyone have a "Frosted Glass Pane" ;-/ )

  Note that the javax.swing.text.PlainDocument does allow some updating from non EDT threads. So this is possible when the implementation of a component model has been designed to support it.

  Posted by: mthornton on September 29, 2007 at 12:02 PM

• 
  I am sorry but the article is flawed.
  And you missed a great opportunity here to talk about the real benefits and challenges that multicore machines are bringing to java.
  Sorting large arrays in parallel is just silly. It shows that you indentified the wrong granularity of the units of work.

  Posted by: unoinpiu on October 01, 2007 at 08:18 AM

• @kirill
  Wouldn't it be possible to write a model in such a way that the sorting is separate from the fired events?
  I tried that exact same thing and it didn't work. I won't say there is NOT a way to write this in a model, but I will say there are problems that I'm not sure can be handled in the current framework. The problems is the EDT can repaint at any time, this calls getValueAt(row,col), if you are in the middle of sorting getValueAt(row,col) may or may not actually exist or resolve to a non-null object. If you synchronize you make the problem worse because now you increase the likelihood of a getValueAt call coming in with stale column and row indexes. This is more important then it sounds because if a user is attempting some action on the item selected, then you want to make sure it gets executed on that exact one they selected. I've done the "frosted glass pane" but it's just not practical for a table that is constantly updated. One could implement a model that sorts a copy of the data, and then swaps it all at once, but thats just doesn't scale well.

  
  

  Posted by: aberrant on October 01, 2007 at 09:42 AM

This work is licensed under a Creative Commons License.