3003jalp@ucsbuxa.ucsb.edu (Applied Magnetics) (12/06/90)
Remember, guys, the post that started it all said: optimizers and the
like, no language wars please. (The post expired long ago at my site,
sorry for the mis-quote.)
Back in the glory days of the VAX there was a similar dilemma: Do you
use VMS for number-crunching or do you use BSD Unix? Answer: VMS.
Why? because the code produced by the VMS Fortran compiler ran circles
around the code from f77.
Doug Gwyn writes:
...Anyway, discussions about code optimization should have little
to do with selection of a programming language.
Obviously, I (and others) disagree. To me the quality of the compiler
is paramount. I am at ease with either programming language, and both
are portable enough to be candidates. Which do I use? The one that
makes my code run faster. Yes, a 2X speedup makes a difference.
Traditionally, Fortran compilers would heap kludge upon kludge to
perform arcane optimization. There are stories of hackers translating
critical routines in assembler to speed them up, and finally conceding
to Fortran! C compiler writers simply never put in the effort required
to make their compilers competitive. The situation always was: use C
and go slow, or use Fortran and go fast. So I would use Fortran,
fighting the language if necessary.
Have things changed? Maybe. I don't know yet. In the past couple
years, workstation vendors finally started paying attention to
floating-point performance. The hardware is pipelined or parallel or
vectorized, so high performance means good compilers. All the
workstations use Unix, because Unix is portable and customers demand it
anyway. Unix means C. Maybe we'll finally get serious C compilers for
number-crunching.
We recently acquired IBM RISC6000's for R&D. The `xl' compilers have
much in common (even bugs ;-). When I have an opinion as to the merits
of xlf vs. xlc, I'll post. But I don't know yet.
Pierre Asselin, R&D, Applied Magnetics Corp. I speak for me.