[clean-list] Clean and scientific programming

Bjorn Lisper lisper@it.kth.se
Thu, 30 Aug 2001 23:36:41 +0200 (MET DST)


Siegfried Gonzi:
>Jan Kort wrote:
>
>> A debate rekindled" [1].
>> It's a followup to an earlier debate where the conclusion was
>> that Fortran was a bad thing but "Fortran and only Fortran
>> provided the performance needed for large-scale scientific computing".
>> Cann reopens the debate in this article by pitting Sisal
>> against Fortran. Sisal more or less destroys Fortran.
>
>The article is dated back to 1991, could it be possible that they
>compared Fortran 77 and not Fortran 90?

Yes. And to say that Sisal destroyed Fortran, as the original poster, is an
exaggeration. The paper, if I remember correctly, benchmarks the Livermore
loops, original Fortran versions vs. Sisal versions, on a range of the
supercomputers of that time from vector machines such as Cray to some
parallel machines. I think the race was quite even for the vector machines,
with a slight edge for Fortran, but that Sisal won on the parallel machines.

I think the results are much due to the fact that good vectorizing Fortran
compilers have been around for a long time, while parallelizing compilers
have been substantially harder to develop. In particular, they were not well
developed in 1991. The reason Sisal won on the parallel machines was the
much easier parallelization of the purely functional code.

>> Although Sisal is dead, the results are still significant:
>> they show that there is a feature for functional
>> languages in scientific computing. 

Yes, I agree. But such languages must be carefully designed to meet the
demands for efficiency yet not loosing too much of the traditionally
appreciated properties of functional languages.

>I think there is an undiscussed problem: Does a functional language need
>some sort of imperative-"loop style" for beeing numerically efficient
>(see FISH link below)?

I think so. The efficiency of Sisal relied heavily on a "loop" construct
which was really tail recursion with accumulating arguments in
disguise. This construct admits efficient reuse of memory locations which is
crucial for performance in high-performance applications and very hard to
achieve for general functional programs with general recursion, dynamic data
structures, lazy evaluation, etc...

On the other hand it made the Sisal versions of the Livermore loops, which
used this construct a lot, look remarkably similar to the Fortran codes.

(Sorry for posting this non-Clean stuff on the clean-list, but I couldn't
resist commenting on this.)

Björn Lisper