6
: Trees Compared To Code

In this chapter, we will look at the empirical results obtained by running multiple trials of the same benchmark under the three interpreter implementations. In this way, we will be able to determine which implementation of each benchmark is more efficient, and by examining all these results together, we will hopefully be able to determine which implementation was most successful.

In determining the most efficient implementation, and comparing the differences in efficiency between implementations, we should be able to answer the question posed in §1.4: Are tree representations able to be interpreted faster than code representations? We will also be able to make comments about in what circumstances the difference is widened or narrowed.

All trials were conducted using the same Power Macintosh 6100/60 running MacOS 8 and Metrowerks Java. The trials were conducted while the system was under the same load conditions, and the elapsed times are for the system clock. Shaded trials have not been included in averages.

6.1 Empty Loop Results

Twenty trials were carried out for each of the three implementations. The results were as follows (all times are in seconds):

↑ Table 6.1 EmptyLoop Results

For EmptyLoop, the stacking tree interpreter is 2.32% faster than the code interpreter, while the optimized tree interpreter is 74.96% faster.

6.2 Deep Empty Loop Results

Twenty trials were carried out for each of the three implementations. The results were as follows (all times are in seconds):

↑ Table 6.2 DeepEmptyLoop Results

For DeepEmptyLoop, the stacking tree interpreter is 1.10% faster than the code interpreter, while the optimized tree interpreter is 71.36% faster.

6.3 Field Access Results

Twenty trials were carried out for each of the three implementations. The results were as follows (all times are in seconds):

↑ Table 6.3 FieldAccess Results

For FieldAccess, the stacking tree interpreter is 1.25% faster than the code interpreter, while the optimized tree interpreter is 63.67% faster.

6.4 Method Call Results

Twenty trials were carried out for each of the three implementations. The results were as follows (all times are in seconds):

↑ Table 6.4 MethodCall Results

For MethodCall, the stacking tree interpreter is 0.58% faster than the code interpreter, while the optimized tree interpreter is 58.19% faster.

6.5 Often True Results

Twenty trials were carried out for each of the three implementations. The results were as follows (all times are in seconds):

↑ Table 6.5 OftenTrue Results

For OftenTrue, the stacking tree interpreter is 1.04% faster than the code interpreter, while the optimized tree interpreter is 76.06% faster.

6.6 Fibonacci Results

Twenty trials were carried out for each of the three implementations. The results were as follows (all times are in seconds):

↑ Table 6.6 Fibonacci Results

For Fibonacci, the stacking tree interpreter is 1.78% faster than the code interpreter, while the optimized tree interpreter is 45.33% faster.

6.7 Summary

As expected, EmptyLoop showed the greatest speed up, both in the best-case and worst-case tree interpreters. This indicates that statement-based interpreters do derive an advantage from not having to explicitly execute branch instructions.

OftenTrue was the best performer in terms of potential speed-up, and this could be attributed to its heavy use of the operand stack. This would advantage the optimized tree interpreter significantly, but would have no effect at all on the stacking tree interpreter (as observed in the results).

DeepEmptyLoop showed a high potential speed up also, but in the stacking tree interpreter this was lost. The results for this are diluted by the sheer amount of data transfer going on relative to the amount of loop mechanics.

Clearly loops benefit most from a tree interpreter, as expected. Even the "real world" example of Fibonacci showed a 45% speed up in the best case, and a little shy of 2% speed up in the worst case.

  Previous Chapter     Next Chapter     Top of Chapter