Effective Image Algebra Implementation for the JVM (temporary title)
|has title::Effective Image Algebra Implementation for the JVM (temporary title)|
|Master:||project within::Information and Communication Technology|
|Student name:||student name::Dirkjan Ochtman|
|Second reader:||has second reader::Ceriel Jacobs|
The project will seek to re-implement (a set of) image algebra algorithms in such a way that (a) the implementation is easy to maintain (in particular, that code size relative to implemented complexity remains low) and (b) the implementation can run efficiently on the JVM (with the IBIS distributed system in mind). In order to do this, we will have to write the implementation in some language that compiles down to JVM bytecode. Since an initial port of the algorithm library to the Java language failed (became increasingly expensive to maintain/improve), we will research alternative (variations on) languages that are a better fit for the problem domain.
The Ibis parallel programming platform comes with a small Java library to facilitate image algebra. This library, called Jorus, is a derivative of the Horus image algebra library implemented in C++ (that library is now called Impala). The Horus library used C++ templates extensively to allow algebra to be performed on images with their underlying data specified in different formats (e.g. black and white versus 24-bits RGB images based on integers, based on doubles, and a few other variants). The templates used made it possible to implement this functionality in a concise and performant way. Of course, conciseness is a primary factor in maintainability for any software project.
Unfortunately things did not look up when porting the Horus code to Java. The Java language sports a generics feature that tries to provide the same functionality as C++'s templates, but that implementation has one important limitation: primitive types cannot be used for generic implementations. In the Java languages, types are divided into primitive and non-primitive types, where the primitive types are special-cased in order to be more performant.
Facing this dilemma, the Jorus implementers chose to shun the generics feature when it turned out that using Java's boxed primitives were significantly slower than the related primitive types. This then resulted in their having to write a bunch of copied implementations of both image data classes and algebraic operations (one for each basic underlying data type).
In this project, we aim to find a way to dial down the code size by eliminating multiple copies of the same (but parametrized) algorithm while keeping the library (nearly) as performant as before. This means that all of the complexity in the current versions of Jorus should be maintained in fewer lines of code in some language that compiles down to JDK bytecode.
The Jorus package (the development version can be obtained from the Ibis Subversion repository at https://gforge.cs.vu.nl/svn/ibis/) implements many copies of the CxArray2d class (in the array package), each for a different data type. In the operations package (also part of Jorus), where algebraic operations on top of image data are implemented, each operations has five implementations to account for disparate data types (byte, double, int, long and short). It should be possible to find a way to drastically lessen the amount of code by implementing just one version of the operation each. It's also likely that one version of the Array2d class is really enough.