This table shows the execution times for calculating the number, the 30th Fibonacci number.
Language | Time (seconds) | ||
C | 0 | . | 22 |
---|---|---|---|
Perl | 26 | . | 5 |
MatLab | 183 | . | 4 |
TONS | 40 | . | 0 |
TONS | 29 | . | 7 |
The TONS number, is for TONS running on two processors on an SMP machine.
Our virtual machine places itself somewhere between the performance of Perl and MatLab, but closest to Perl. I'm pretty happy with that. Especially because there hasn't been done any work on fine tuning the performance on the virtual machine yet. It is fairly well performing by design, but there are definitely tuning opportunities left.
The reason why we don't scale better when going to two CPUs, is that the first node (which computes fib(28) and delegates fib(29) to its slave), is spending some time waiting for the node to return it's result. This is an implementation issue mostly, since the nodes should be able to communicate to each other when someone becomes idle. It is, however, also a design issue, since this communication should not be taken lightly upon. This is discussed in chapter 2.3.4.
This problem will scale to a large number of processors. Because of the re-scheduling problem, we do not see a linear speedup, and the actual speedup will decrease as we add more nodes. But I've run this program successfully on 9 nodes, though with a more disappointing speedup. But the speedup problem will - to a large extent - be solved by implementing a smart re-scheduling strategy, so nodes can delegate jobs to other nodes, as they become idle.