Currently, we have used the Bayanihan framework to write a simple
application that factors a long integer N by dividing the search space
into fixed-sized work packets which are executed
by the work engines. This problem, inspired by [38],
although somewhat unrealistic, was chosen because its simplicity and
predictability make it easy to measure performance and analyze results.
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 number of numbers
checked per millisecond, 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.
| 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 (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.