Synchronization using counting semaphores
ICS '88 Proceedings of the 2nd international conference on Supercomputing
The fuzzy barrier: a mechanism for high speed synchronization of processors
ASPLOS III Proceedings of the third international conference on Architectural support for programming languages and operating systems
X10: an object-oriented approach to non-uniform cluster computing
OOPSLA '05 Proceedings of the 20th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications
Productivity and performance using partitioned global address space languages
Proceedings of the 2007 international workshop on Parallel symbolic computation
Phasers: a unified deadlock-free construct for collective and point-to-point synchronization
Proceedings of the 22nd annual international conference on Supercomputing
Hi-index | 0.00 |
Mainstream object-oriented languages such as Java and C#, through the use of object-oriented abstractions and managed runtimes (virtual machines), have significantly improved productivity and portability in multiple application domains. However, despite many attempts in the past, the effect of these improvements on high-performance numeric computations has been limited. In this report, we describe the results and lessons learned from a one-year joint study between researchers in an industrial company (BHP Billiton) and an academic institution (Rice University) to port Dipole1D, an open source Fortran 90 application for 1D forward modeling of an arbitrarily located and oriented electric dipole transmitter, to Java with a goal of gaining efficient sequential and multicore implementations. Our primary conclusions from this study are as follows: 1) a standard library-based implementation of Fortran 90 primitives in Java (especially complex arithmetic and complex variables) results in un-acceptably large performance overheads, 2) the Java bytecodes generated from this translation include large methods for which current JIT compilers generate surprisingly inefficient code, 3) hand splitting of the large methods removes much of this inefficiency, and 4) after building the sequential extended-Java version of the Dipole1D application, the path to multicore execution is greatly simplified. The resulting Habanero-Java version of Dipole1D is in the process of being made available publicly, and sheds light on missed opportunities from the past, such as JSR 84 (Floating Point Extensions) which has been withdrawn in 2002.