LAPI

Figure 6.13: Comparison of the mpjdev communication library using MPI vs. LAPI.

Table 6.7: Comparison of the mpjdev communication library using MPI vs. LAPI. All speeds in MFLOPS.

CFD
Processors	1	2	4	8	16
HPJava/MPI	50.04	100.73	195.30	361.72	638.24
HPJava/LAPI	50.08	99.44	184.09	307.12	459.22
Java	72.56

Figure 6.13 and Table 6.7 show same benchmark results of an implementation of underlying communication library using LAPI. As we can see from the figure, the results of the sample benchmark indicate, unfortunately, that LAPI version of library is slower then MPI version. After careful investigation of the time consuming parts of the library, we found that current version of Java thread synchronization is not implemented with high performance.

Table 6.8: Timing for a wait and wake-up function calls on JAVA thread and POSIX Thread in microseconds.

Java Thread	POSIX Thread
57.49	10.68

The Java thread consumes more then five times a long as POSIX thread, to perform wait and awake thread function calls (Table 6.8). This result suggests we should look for a new architectural design for mpjdev using LAPI. In this section we will not discuss in detail the new architecture design. However, we briefly introduce our thoughts. To eliminate major problem of current design, we consider using POSIX threads by calling JNI to the C instead of Java threads. This would force us to move any synchronized data from the Java to the C side. In this design, work for the Java side of the mpjdev is to call C functions via JNI. All the actual communication and data processing parts including maintain send and receive queue, protection of any shared datas, and thread waiting and awaking will be done in C. Implementation is a future project.