Caveat: I couldn't stop myself. Read at your own risk.
Mark Hahn wrote:
>>Trying to be objective and not fan the flames ..
>>> hah!
Where'd I leave that gasoline can?
>>Hence a compiler can always optimise Fortran code more than C code becuase
>>the programmer has expressed the operation at a higher level (eg. a
>>matrix-multiply rather than a nested set of for-loops). However ultimately
>>> reasonably true for C vs Fortran, but clearly not for C++ vs Fortran.
And questionable for most F77 implementations, as well. While matrix
multiply was part of the standard, it was a part that was frequently
poorly implemented, in my past experience.
>>an expert C-programmer (read 'assembly programmer') may be able to tweak
>>even more performance by hand-unrolling loops, using prefetch, etc.
>>> I'm afraid I don't see why C is somehow hostile to compiler-directed
> unrolling and prefetch. in fact, gcc demonstrates this.
It's probably related to the unnatural use of indentation. C++ is
further problemmatic by its inclusion of curly braces instead of
readable code.
>>(Also Mark Hahn suggested that Fortran was not inherently parallel - I would
>>argue that it is since Fortran source code exposes available concurrency of
>>operations : vector notation, loop trip counts are known a-priori, no
>>aliasing of pointers, etc. )
>>> gcc also demonstrates that C has had optimization-friendly aliasing
> rules since C89.
Strictly speaking, an accomplished Fortran programmer (OK. I see you
out there. Stop giggling!) goes through 3 phases of accomplishment when
learning about parallelization.
1. Too dumb to follow convention. Loops are almost always simply
unrolled and parallelizable.
2. Learned to follow the herd. Loops are consistent with convention.
Must decompose the entire program to make the one parallelizable loop in
the middle a little more efficient. Rest of code should have stayed
linear but now suffers processing delays when CPU laughs at program
structure.
3. Learned what to do to parallelize code. Segregates parallel code
from serial code. Processes each appropriately. Trusts no compiler.
Looks at assembly output for flaws. Lives on Twinkies, Jolt and Cheetos
(crispy, pepper-hot).
--
Gerry Creager -- gerry.creager at tamu.edu
Network Engineering, Academy for Advanced Telecommunications
Texas A&M University, College Station, TX
Office: 979.458.4020 FAX: 979.847.8578 Cell: 979.229.5301 Page: 979.228.0173
_______________________________________________
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf