next up previous
Next: Benchmarking the System Up: Java as an Intermediate Previous: Translating VCODE into Java

Pros and Cons of Java

It took one of the authors just over two days to complete a working prototype of the system, with his time divided roughly equally between implementing the Java stack model and translation script, and writing the vector methods. From this standpoint, the experiment was clearly a success: we quickly had a working system that enabled us to execute NESL code on any Java platform.

In terms of language features, Java's stack and array classes were a great help in rapid prototyping, and the language's built-in garbage collection meant that we did not have to adapt the reference-counting code used by the VCODE interpreter. We did not exploit Java's object-oriented features; there is no inheritance, and very few little composition of objects. In essence, we used Java as a portable dialect of C with garbage collection and a good collection of preexisting data structures.

Some aspects of Java slowed down both the development process and the generated code. Without templates, parametric polymorphism, or a built-in preprocessor, it is impossible to generate efficient type-specialized versions of the same basic method from within Java itself. Although useful for prototyping, the standard Java stack class is limiting in that it allows manipulation only of the element at the top of the stack, whereas VCODE requires the ability to operate on multiple elements at arbitrary positions in the stack. In terms of runtime performance, creating Java arrays is relatively expensive, because they are defined to be filled with the null value appropriate for their type. This requirement causes an implicit loop over the array, even though the initialization is unnecessary for arrays that will be written before being read. Finally, because Java is a young language, there is little performance data available for use in making informed design and optimization decisions.

However, it is easy to solve or work around most of these problems. We could have used an external preprocessor such as the Unix m4 tool to generate multiple type-specialized versions of each vector method.Footnote Microbenchmarks were used to establish the comparative cost of various Java operations; the results can be found at http://www.cs.cmu.edu/~jch/java/optimization.html.. Profiling revealed that the awkward coding required to use the standard Java stack class was also a significant performance bottleneck. We therefore created a new version of the VcodeEmulation class that represents the stack as a directly-accessible array of objects. Each element of the stack holds an array corresponding to a VCODE vector, and the stack is grown as necessary; this is essentially a specialized version of the standard Java vector class. This modification improved the performance of the stack-intensive selection benchmark (see Section 5) by approximately 30%, and was adopted for the final version of the code.


next up previous
Next: Benchmarking the System Up: Java as an Intermediate Previous: Translating VCODE into Java

Jonathan Hardwick