Re: Fortran now in the Great Language Shootout

From: James Van Buskirk (not_valid_at_comcast.net)
Date: 03/02/05 

Date: Wed, 2 Mar 2005 11:48:39 -0700

"Janne Blomqvist" <foo@bar.invalid> wrote in message
news:slrnd2bt9f.f46.foo@vipunen.hut.fi...

> I don't think that a 4000 line program partly written in asm is more
> representative of how Fortran compares to the other programming
> languages than the current naive implementation in multiple languages.
> Not to mention that requiring a 4000 line implementation for a
> competetive solution would probably drastically reduce the number of
> implementations in the first place.

Jeez, is it really 4 KLOC? It's been quite a while since I
looked at it, and I seemed to recall only a couple of hundred
lines. Maybe I was counting the lines of the automatic code
generator (writesieve.f90) rather than the code it generated
(sieve_core.fi). A hundred lines might just as well be infinity
for the purposes of a newsgroup post, though, as I admit that
I get all fuzzy-eyed when I see a post that has that much code
in it myself. It would be so cool if there were a language
that allowed you to tell the compiler what you wanted it to
do in relatively few high-level instructions, like 'unroll this
loop by 8, write 64 cases of it for the 8 congruence classes
mod 30 and implement it with LEA and RMW instructions so as
do try to attain one table hit in memory each clock cycle' or
'implement a population count 64-way parallel using mmx
registers as carry-save adders' or 'make sure that this load
is prefetched because it's not going to come from L1 cache'
and so on. Compilers are far from being able to do this
kind of stuff and there is no prospect of them catching up
any time soon because the rules are changing, easily as fast
as compilers that attempt to generate efficient code for a
given set of rules can be produced. It always amuses me when
someone says that he's got to have the capability to run his
code on a multiprocessor machine when you can see how much of
the potential of any single processor is typically wasted. By
my perhaps wierd way of looking at things the times quoted for
nsieve-bits are more than 4 orders of magnitude off of optimal.
More nearly optimal code for this problem ends up doing
different kinds of stuff from what the nsieve-bits code does:
it uses less memory, uses memory in a much more disciplined
fashion, and runs from much more irregular, herky-jerky
machine code.

Ah well, it's nice to see Fortran ranking #1 in LOC or time
in some of these tests, and I appreciate those of you who
are putting in the effort to make this possible, but I
always have a rather contrarian view when I see benchmarks
like this: as you say to allow a freestyle benchmark makes
it simply a test of who's got the most time and the time of
a competent (including engineering and numerical analysis
skills) Fortran programmer doesn't come all that cheap. But
the constraints of a benchmark that fits within the free time
capabilities of many programmers often ends up creating
solutions that do not correspond to the problems they might
outwardly seem to be addressing. 

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Relevant Pages

  • Re: Ideal Fortran
    ... I'm not familiar with the latest changes in fortran syntax so ... languages up through the 80's. ... so some programming mistakes would be ...
    (comp.lang.fortran)
  • Re: IF DEAD, GOTO 10-3-39
    ... No one would do text parsing in FORTRAN given the choice. ... As having labels implies that they are going to be used (for dreaded goto statements), I'd have to say they have not survived, aside from being a dirty little secret that some languages have but you are never supposed to use. ... The fact is that general use of GOTOs is one of the most difficult programming constructs to trace and determine "programmer's intent", making debugging and long-term code maintenance very difficult. ...
    (rec.sport.football.college)
  • Re: IF DEAD, GOTO 10-3-39
    ... No one would do text parsing in FORTRAN given the choice. ... As having labels implies that they are going to be used (for dreaded goto statements), I'd have to say they have not survived, aside from being a dirty little secret that some languages have but you are never supposed to use. ... The fact is that general use of GOTOs is one of the most difficult programming constructs to trace and determine "programmer's intent", making debugging and long-term code maintenance very difficult. ...
    (rec.sport.football.college)
  • Re: IF DEAD, GOTO 10-3-39
    ... No one would do text parsing in FORTRAN given the choice. ... As having labels implies that they are going to be used (for dreaded goto statements), I'd have to say they have not survived, aside from being a dirty little secret that some languages have but you are never supposed to use. ... The fact is that general use of GOTOs is one of the most difficult programming constructs to trace and determine "programmer's intent", making debugging and long-term code maintenance very difficult. ...
    (rec.sport.football.college)
  • Re: Is VB.NET Stable??
    ... and I know multiple languages ... I know lots of HTML languages.. ... Programming is WORTHLESS to my salary; I coast on my database skills.. ... GUI class libraries, Pascal, LISP, C++, assembly language, a few 4GL languages, ...
    (microsoft.public.dotnet.languages.vb)