Hostname: page-component-cc8bf7c57-77pjf Total loading time: 0 Render date: 2024-12-11T22:08:05.698Z Has data issue: false hasContentIssue false

On the effectiveness of functional language features: NAS benchmark FT

Published online by Cambridge University Press:  01 January 1997

J. HAMMES
Affiliation:
Department of Computer Science, Colorado State University, Ft. Collins, CO 80523, USA
S. SUR
Affiliation:
Department of Computer Science, Colorado State University, Ft. Collins, CO 80523, USA
W. BÖHM
Affiliation:
Department of Computer Science, Colorado State University, Ft. Collins, CO 80523, USA
Rights & Permissions [Opens in a new window]

Abstract

Core share and HTML view are not available for this content. However, as you have access to this content, a full PDF is available via the ‘Save PDF’ action button.

In this paper we investigate the effectiveness of functional language features when writing scientific codes. Our programs are written in the purely functional subset of Id and executed on a one node Motorola Monsoon machine, and in Haskell and executed on a Sparc 2. In the application we study – the NAS FT benchmark, a three-dimensional heat equation solver – it is necessary to target and select one-dimensional sub-arrays in three-dimensional arrays. Furthermore, it is important to be able to share computation in array definitions. We compare first order and higher order implementations of this benchmark. The higher order version uses functions to select one-dimensional sub-arrays, or slices, from a three-dimensional object, whereas the first order version creates copies to achieve the same result. We compare various representations of a three-dimensional object, and study the effect of strictness in Haskell. We also study the performance of our codes when employing recursive and iterative implementations of the one-dimensional FFT, which forms the kernel of this benchmark. It turns out that these languages still have quite inefficient implementations, with respect to both space and time. For the largest problem we could run (323), Haskell is 15 times slower than Fortran and uses three times more space than is absolutely necessary, whereas Id on Monsoon uses nine times more cycles than Fortran on the MIPS R3000, and uses five times more space than is absolutely necessary. This code, and others like it, should inspire compiler writers to improve the performance of functional language implementations.

Type
Research Article
Copyright
© 1997 Cambridge University Press
Submit a response

Discussions

No Discussions have been published for this article.