Relative Speedup and Absolute Performance

  Figure 6 shows results from running the Mandelbrot application on 17 200MHz Pentium Pro machines (1 server and 16 workers) connected by 10Mbit Ethernet, running Windows NT 4.0, Netscape 4.03 on the clients, and Sun's JDK 1.1.6 JIT compiler on the server. In this experiment, the target work was an 800x800 pixel array, divided into 256 square chunks. To represent different computation granularities, we tried four different target ranges with different average depths (iterations per pixel). For comparison, ideal speedup was computed using the sequential computation speed on a single unpartitioned 800x800 array with maximum depth.

  

Figure 6: Speedup measurements for the Mandelbrot application.

As shown, we get good speedup for large granularities - achieving 91% and 85% efficiency with 16 workers at depths 2048 and 1037, respectively. As the granularity decreases, however, communication and other overheads begin to dominate, limiting efficiency to only 42% and 1% with 16 workers at depths 198 and 3, respectively. Possible approaches to this problem (which is not unique to Java-based volunteer computing) include reducing overhead, and adaptively changing the problem granularity.

Table 2 shows a comparison of absolute speeds from sequential Java and native C executions of the same Mandelbrot code. Here, we see that with just-in-time (JIT) compilation, Java was actually faster than unoptimized C code, while only slightly slower than optimized C code (compiled with djgpp's gcc [8] using the -O option that produced the best result). In another test, our RC5 code was about 8 times slower than distributed.net's version. While not as impressive, this is still notable, considering that distributed.net's code was hand-optimized using processor-specific assembly code, while Java does not even directly support some necessary operations such as bitwise rotates.

  

Table 2: Absolute Java and C speeds for the Mandelbrot demo on a 200MHz Pentium Pro.