Yet another software toolmaker has offered up its solution to the parallel programming crisis. This week, French software vendor Ateji released a Java solution for multicore CPUs and multiprocessor server environments. Ateji PX for Java is aimed at developers who want to take advantage of current and future computer architectures by moving their legacy codes into the parallel realm.

Now Java is not exactly the first language that comes to mind when you think of parallel programming. Although the language encompasses the thread model and the notion of concurrency, it’s up to the Java Virtual Machine (JVM) component to implement true parallelism on the hardware. Attempts to add more parallel smarts to the language itself are numerous, but mostly incomplete. These include Titanium (a parallel dialect of Java), JOMP (an OpenMP-supported implementation), and JavaParty (for distributed computing environments), among others. Despite all these research projects, commercial adoption of parallel Java implementations never took hold.

Ateji, of course, would like to change that. One thing in its favor is that Ateji PX supports a wide range of parallel models, including task parallelism, data parallelism, speculative parallelism, recursive parallelism and distributed parallelism. And it does so with a relatively-small number of extensions to the standard language. The main addition is the “||” operator, which is used to tell the compiler to parallelize the associated source statement. For example, if you wanted to parallelize matrix multiplication via a for-loop you embed the || after the keyword:

for || (int i : I) {
   for (int j : J) {
      for (int k : K) {
         C[i][j] += A[i][k] * B[k][j];
      }
   }
}

Using this method, Ateji demonstrated a 3.4x speedup on a 4-core PC and a 12.5x speedup on a 16-core server. You could implement the equivalent parallelism by using Java’s thread library, but that would take about four times as much user code. Also, in that case, the original matrix multiplication algorithm gets hidden within a lot of thread management code.

In fact, the Ateji solution tosses the whole notion of threads out the window. “Threads are very ill-suited as a programming concept,” says the Ateji PX white paper. According to a Berkeley technical report cited in the whitepaper, a thread is really a hardware concept associated with the underlying processor architecture, rather than a natural language construct. This makes the thread model a much less productive way to think about parallelizing algorithms and can lead to buggy programs.

Instead, the Ateji model introduces the concept of a “branch,” which is basically equivalent to a parallelized statement. Beneath the covers, branches do get mapped to processor threads since the hardware demands it. But the mapping is context-specific, and the programmer can’t assume that the branch is (or is not) running in its own thread.

Ateji PX does provide compatibility with standard Java. The compiler front-end does a source-to-source translation to the base language, allowing the developer to keep his or her software development tool chain intact. It also enables the developer to revert back to vanilla Java once the parallelism has been implemented.

Even though the Ateji solution is being promoted as “parallel programming made simple,” the programmer is still stuck with the task of figuring out which statements and code sequences can be parallelized. The compiler doesn’t protect you from things like data races and deadlocks, so locks and atomic operations must be used if data is to be shared across parallelized code. For cases where sharing memory becomes too arduous or is just not available, Ateji PX also offers distributed memory parallelism. In fact, the Ateji PX programming manual suggests you mix the two, using a lot of small, well-defined parallel tasks that communicate via message passing.

For distributed parallelism, Ateji has come up with message passing primitives. At the simplest level, the programmer just needs to declare a channel object for message passing that is visible to both the sender and the receiver (using || chan ! value to send a message and || chan ? value to receive it). The fact that message passing can be specified at the language level rather than by invoking runtime routines (i.e., an MPI library) means that the source can be mapped to different types of distributed computing architecture independent of library implementations. It also allows different kinds of distributed models to be used — dataflow, stream programming, the Actor model, and the MapReduce algorithm.

Apparently, the distributed parallel feature is still a work in progress. According to the Ateji Web site, a version that is able to implement parallel branches on distributed memory hardware — compute clusters, supercomputers, grids and clouds — is still under development.

Of course, the whole idea of parallelizing code is to boost execution performance. Mapping code to more than one core or processor is bound to speed up the program, but Java, being an interpreted language, is not known for its stellar performance. For optimal execution, some heavy lifting will have to be done by the JVM. Just in time (JIT) compilers have helped to some extent, but the virtual machine model tends to be at odds with compute-bound codes. A 2004 report looked at the current state of Java for HPC and found that it is possible to deliver comparable performance to that of a Fortran/MPI implementation, for at least some codes, but scalability issues still remain. It’s not inconceivable that back-end Java technology could be developed for the performance market.

Although the official launch of Ateji PX was this week, the solution has been previewed by selected customers over the past year. A group at ISIMA claimed a seven-fold speedup with the Game of Life algorithm using Ateji PX on an 8-core Nehalem system. Another researcher at the University of Pisa benchmarked different parallel implementations of the convolution algorithm using the Ateji solution. In another case, an investment bank was able to parallelize a back-office Java app, reducing execution time from 40 minutes to eight minutes.

A free 30-day evaluation license is available for users that want to give Ateji PX a whirl. The solution is provided as an Eclipse plug-in, and all documentation and samples are provided online through the Ateji Web site.