low level optimization

[Dario Bressanini]

    martelli at cadlab.sublink.ORG (Alex Martelli) writes:

>>:Just in case.... I don't want to start the usual and useless war
>>:C vs FORTRAN etc..,i would like to use C for my programs, but in most
>>:cases i tried, the Code produced by the C compiler was 2 or 3 times
>>:slower that the fortran code.
>On what platforms?  On workstation-class hardware, my experience is
>just the reverse: despite all the theoretical advantages of Fortran,
>which SHOULD be vastly easier to optimize for numerical computation
>(no aliasing allowed...), I find most Fortran-generated code quite a
>bit slower than C. 

Ciao Alex! I didn't know i was starting such a discussion with my
first innocent message.

Well, i tried on Mini systems (Gould, Convex ...). When i used 
f77 (the standard unix compiler) the performances were *VERY* bad,
but when i switched to the vendor's compiler the fortran code
was faster than the C code. I plan to try again on the RS-6000
and on a Personal IRIS to see if there is any difference. 

>>On PC's, it's even worse, as
>>if compiler vendors barely cared for Fortran performance (particularly
>>in bulk I/O) but were locked in a mad race for C performance, or
>>something like that...

I agree with you. Once i reduced the execution time of a fortran
program on a IBM PC  from 18 Hours to 2 by changing a single line!
it was something like

  a = (expr)**3

I changed it in    

        b = expr
        a = b*b*b 

et voila' (expr is a floating point expression).
If the compiler cannot do this kind of optimizations, well, it is a
very poor compiler.
On my Atari ST, the FASTEST language is......compiled BASIC!
(and now all comp.lang.c will flame me :-) )


>>modern C's should allow you to use
>>single precision anyway where/when it matters (ANSI allows that, Sun C
>>while non-ANSI offers a special option for this, etc).  Anyway I'm not
>>surprised if your results are on supers/mainframes, since apparently
>>those guys are GOOD at writing Fortran compilers (maybe it is that they
>>CARE about it!), while their WSs colleagues appear to be either less
>>able or less motivated... 

Yes, with ANSI C you can use single precision, but it is almost USELESS  
in scientific computations (at least in my field, i.e. quantum chemistry)
If I use single precision I cannot trust the results!
FORTRAN and C belong to different worlds: C is for programmers
while FORTRAN is for most of the scientific community. Most of the time
a C programmer doesn't give a damn for the floating point performances,
while sometimes, doing scientific computations, I even have to care
about the performances of DOUBLE PRECISION COMPLEX.
I would like to use a language which combines the good features of the
two, but i guess I'll have to wait...


>>Since when do you mind 'pure void theoric discussions', DB...?-) {Personal
>>joke warning, me and DB are old fidonet friend/enemies!-}
things change....


   rob at mckinley.eng.ohio-state.edu (Rob Carriere) writes:

>>>Right now, in the Real World (TM), optimized Fortran really does run faster
>>>than optimized C.  A situation that truly sucks.
>>It seems to me that, like mister Giles, you are confusing properties of the
>>language with properties of the implementation.  It would sure be nice to have
>>those wonderful compilers today, but their presence or absence has nothing to
>>do with the merits or lack thereof of the language C.

I don't agree with this. We can talk forever about properties of a language,
but when you write a program you have to deal with the actual implementation.
I am glad to know that a language has certain properties, but if the
implementation doesn't use them, well, they don't count for me.
If my fortran program, that takes 100 hours on a CRAY, can takes 80 hours
if rewritten in C, I'll start coding immediately, but if you say that 
i should judge C from the fact that in theory i could have a program
that takes 80 hours, and not from the fact that the actual C implementation
would take longer that 100 hours, well...
 
     dario bressanini      rkowen at violet.berkeley.edu