next up previous contents index
Next: Datatypes in HPJava Up: Issues in the Language Previous: Extending the Java Language   Contents   Index

Why not HPF?

The design of the HPJava language is strongly influenced by HPF. The language emerged partly out of practices adopted in our efforts to implement an HPF compilation system [10]. For example:

  !HPF$ POCESSOR    P(4)
  !HPF$ TEMPLET     T(100)
  !HPF$ DISTRIBUTE  T(BLOCK) ONTO P
        REAL        A(100,100), B(100)
  !HPF$ ALIGN       A(:,*) WITH T(:)
  !HPF$ ALIGN       B WITH T
have their conterparts in HPJava:
  Procs1 p = new Procs1(4);
  Range x = new BlockRange (100, p.dim(0));
  float [[,*]] a = new float [[x,100]] on p;
  float [[ ]] b = new float [[x]] on p;
Both languages provide a globally addressed name space for data parallel applications. Both of them can specify how data are mapped on to a processor grid. The difference between the two lies in their communication aspects. In HPF, a simple assignment statement may cause data movement. For example, given the above distribution, the assignment
  A(10,10) = B(30)
will cause communication between processor 1 and 2. In HPJava, similar communication must be done through explicit function calls: [*]
  Adlib.remap(a[[9,9]], b[[29]]);
Experience from compiling the HPF language suggests that, while there are various kinds of algorithms to detect communication automatically, it is often difficult to give the generated node program acceptable performance. In HPF, the need to decide on which processor the computation should be executed further complicates the situation. One may apply ``owner computes'' or ``majority computes'' rules to partition computation, but these heuristics are difficult to apply in many situations.

In HPJava, the SPMD programming model is emphasized. The distributed arrays just help the programmer organize data, and simplify global-to-local address translation. The tasks of computation partition and communication are still under control of the programmer. This is certainly an extra onus, and the language may be more difficult to program than HPF; [*] but it helps programmers to understand the performance of the program much better than in HPF, so algorithms exploiting locality and parallelism are encouraged. It also dramatically simplifies the work of the compiler.

Because the communication sector is considered an ``add-on'' to the basic language, HPJava should interoperate more smoothly than HPF with other successful SPMD libraries, including MPI [5], Global Arrays [7], CHAOS [3], and so on.


next up previous contents index
Next: Datatypes in HPJava Up: Issues in the Language Previous: Extending the Java Language   Contents   Index
Bryan Carpenter 2002-07-11