next up previous
Next: Conclusion Up: Translation Schemes for the Previous: Translating element access in


Status and prospects

The first fully functional version of the HPJava translator is now operational. Over the last few weeks the system as been tested and debugged against a small test suite of available HPJava programs. Currently most of the examples are short, although the suite does include an 800-line Multigrid code, transcribed from an existing Fortran 90 program. One pressing concern over the next few months is to develop a much more substantial body of test code and applications.

As we have emphasized, HPJava includes all of standard Java as a subset. ``Translation'' of the conventional Java part of the language is very easy. It is a design feature of HPJava that the translation system handles code that looks like base language code in exactly the same way as it would be handled by a compiler for the base language. In our source-to-source translation strategy, this means that standard Java statements and expressions are copied through essentially unchanged. On the other hand the inclusion of Java means that we do need a front-end that covers the whole of Java. The translation scheme for HPJava depends in an important way on type information. It follows that we need type analysis for the whole language, including the Java part. Writing a full type-checker for Java is not trivial (especially since the introduction of nested types). In practice development of the front-end, and particularly the type-checker, has been the most time-consuming step in developing the whole system. The HPJava translator is written in Java. The parser was developed using the JavaCC and JTB tools.

It is too early to give detailed benchmarks. However we will give some general arguments that lead us to believe that in the near future we can hope to obtain effective performance using our system. For the sake of definiteness, consider the Multigrid example referred to above. This is a good example for HPJava, because it is an example of an algorithm that is quite complex to code ``by hand'' as a parallel program, and relatively easy to code using HPJava together with the communication library Adlib. The detailed logic of the Multigrid algorithm has an interesting recursive structure, but the core of the computational work boils down to red-black relaxation (Figure 2). If we can code this simple algorithm well, we expect the whole of the solver should work reasonably well.

The general feasibility of programming this kind of algorithm on a massively parallel, distributed memory computer is presumably not at issue. As discussed in the previous section, the translation scheme for HPJava ultimately reduces the overall constructs of the source program to simple for loops--much the same as the kind of for loops one would write in a hand-coded MPI program3. Earlier experiences, using the high-level Adlib communication library as run-time support for research implementations of HPF, lead us to believe that this library should not introduce unacceptable overheads. (Adlib is a C++ library built on top of MPI. The Java binding is through JNI.) So this leaves us with the question of whether Java will be the weak link, in terms of performance. The answer seems to be ``perhaps not''. Recent benchmarking efforts [2] indicate that--at least on major commodity platforms--Java JIT performance is approaching parity with C and even Fortran compilers. We believe that these results will carry over to our applications.


next up previous
Next: Conclusion Up: Translation Schemes for the Previous: Translating element access in
Bryan Carpenter 2002-07-12