Table of Contents Author Guidelines Submit a Manuscript
Scientific Programming
Volume 7 (1999), Issue 2, Pages 87-95
http://dx.doi.org/10.1155/1999/464598

The Cost of being Object-Oriented: A Preliminary Study

Zoran Budimlić, Ken Kennedy, and Jeff Piper

Center for Research on Parallel Computation, Rice University, CRPC – MS 41, 6100 Main Street, Houston, TX 77005‐1892, USA

Copyright © 1999 Hindawi Publishing Corporation. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Abstract

Since the introduction of the Java programming language, there has been widespread interest in the use Java for the high performance scientific computing. One major impediment to such use is the performance penalty paid relative to Fortran. To support our research on overcoming this penalty through compiler technology, we have developed a benchmark suite, called OwlPack, which is based on the popular LINPACK library. Although there are existing implementations of LINPACK in Java, most of these are produced by direct translation from Fortran. As such they do not reflect the style of programming that a good object‐oriented programmer would use in Java. Our goal is to investigate how to make object‐oriented scientific programming practical. Therefore we developed two object‐oriented versions of LINPACK in Java, a true polymorphic version and a “Lite” version designed for higher performance. We used these libraries to perform a detailed performance analysis using several leading Java compilers and virtual machines, comparing the performance of the object‐oriented versions of the benchmark with a version produced by direct translation from Fortran. Although Java implementations have been made great strides, they still fall short on programs that use the full power of Java’s object‐oriented features. Our ultimate goal is to drive research on compiler technology that will reward, rather than penalize good object‐oriented programming practice.