Figure2 shows some results
for *N*=1234567890123456789, with
112 work packets of size 100000000 each.
We used five identical 200MHz dual-Pentium machines (one server,
and four clients) connected to a 10Base-T Ethernet hub, and running
Windows NT 4.0.
The server application was run using Sun's JDK 1.1.4, and the
worker applets were run using Netscape 4.02.
The speeds in the figure represent the average rate (i.e., numbers
checked per millisecond) at which work packets were processed,
over the course of searching the whole target space.
The number of workers represents the number of worker applets
run on the client machines. Each client machine was used to
run up to two worker applets.^{}
The ideal speed is computed as the pure computation speed
(measured at the client side) multiplied by the number of workers.
With eight workers, we get the figures in Table1.

measurement | num/ms | ||

pure computation (1 worker) | 1828 | ||

ave. speed (8 workers) | 13571 | ||

speedup | 7.42 | ||

efficiency | 92.8% |

To evaluate the performance of Java, relative to C, we wrote a simple
C program, compiled it with `djgpp` [42] (the `gcc`
implementation for MS-DOS).
Comparing its performance with the one-worker pure computation performance,
we get the results shown in Table2. These
results show that at least for simple tight-loop
computations such as our factoring algorithm, the performance
of the Java just-in-time-compiler in Netscape is comparable to
native C code.

While these results are admittedly preliminary and based on a toy problem, we believe that they give us hope that Java-based implementations of volunteer computing will be feasible and practical.