0

I need to parallelize a CPU intensive Java application on my multicore desktop but I am not so comfortable with threads programming. I looked at Scala but this would imply learning a new language which is really time consuming. I also looked at Ateji PX Java parallel extensions which seem very easy to use but did not have a chance yet to evaluate it. Would anyone recommend it? Other suggestions welcome.

Thanks in advance for your help

Bill

user578524
  • 1

5 Answers5

6

I would suggest you try the built-in ExecutorService for distributing multiple tasks across multiple threads/cores. Do you have any requirements which this might not do for you?

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • And they have been around for years before they were added to Java in 2004 so you can have confience they work. Additionally, they have builtin support in the JVM which an external library cannot safely do. – Peter Lawrey Jan 17 '11 at 13:02
  • 3
    +1, but with the caveat that jumping into concurrent programming isn't as simple as sectioning off code into tasks and plugging in an executor. In any substantial application there are often numerous thread safety and ordering issues. – Tim Bender Jan 17 '11 at 13:08
  • @Tim and that's exactly what Ateji PX is not doing. – gabuzo Jan 17 '11 at 13:21
  • @Tim, it rather depends on how the code has been written. Some coding styles (like functional programming) are easier to parallelise than others. Its not unlikely that a complete re-write of the core code is the best approach, once you have learnt what needs to be done. ;) – Peter Lawrey Jan 17 '11 at 13:28
2

The Java concurrency utilites:

http://download.oracle.com/javase/1.5.0/docs/guide/concurrency/overview.html

make parallel programming on Java even easier than it already was. I would suggest starting there - if you are uncomfortable with that level of working with threads, I would think twice about proceeding further. Parallelizing anything requires some level of technical comfort with how concurrent computation is done and coordinated. In my opinion, it can't get much easier than that framework - which is part of the reason why you see so few alternatives.

Second, the main thing you should think about is what the unit of work is for parallelization. If your unit of work is independent (i.e., each parallel task does not impact the others), this is generally far easier because you don't need to worry about much (or any) synchronization at all. Put effort into thinking how to model the problem so that computation is as independent as possible. If you model it well, you will almost certainly reduce the lines of code (which reduces the error, etc).

Admittedly, frameworks that automatically parallelize for you are less error prone, but can be suboptimal if your model unit of work doesn't play to their parallelization scheme.

kvista
  • 5,039
  • 1
  • 23
  • 25
2

I am the lead developer of Ateji PX. As you mention, guaranteeing thread safety is an important topic. It is also a very difficult one, and there's not much help out there beside hand-written and hand-checked @ThreadSafe annotations. See e.g. "The problem with threads".

We are currently working on a parallel verifier for Ateji PX. This has become possible because parallelism in Ateji PX is compositional (unlike threads) and based on a sound mathematical foundation, namely pi-calculus. Even without a tool, experience shows that expressing parallelism in an intuitive and compositional way makes it much easier to "think parallel" and catch errors earlier.

Patrick Viry
  • 21
  • 1
1

I browsed quickly through the Ateji PX web site. Seems to be a nice product but I'm afraid you will be disappointed at some point since Ateji PX only provides you an intuitive simple way of performing high level parallel operations such as distributing the work load on several workers, creating rendez-vous points between parallel tasks, etc. However as you can read in the FAQ in the section How do you detect and prevent data dependencies? Ateji PX does not ensure that the underlying code is thread safe. So at any rate you'll still be needing skills in Java thread programming.

Edit:

Also consider that when maintenance time will come and you won't be available to perform it, it'll be easier to find a contractor, employee or trainee with skills in standard Java multithread programming than in Ateji PX.

Last word, there's a free 30 days evaluation, try it.

gabuzo
  • 7,378
  • 4
  • 28
  • 36
0

Dont worry java 7 is coming up with Fork Join by Doug lea for Distributed Processing.

Dead Programmer
  • 12,427
  • 23
  • 80
  • 112
  • That's one of the nice things to .NET's implementation ... they have the fork/join implementation up and running and it does simplify things ... depending on your needs, of course. – BonanzaDriver Jan 28 '11 at 17:38