[Beowulf] Linux quality vs. defects

[Joe Landman]

On 05/13/2013 01:21 PM, Peter St. John wrote:
> Joe,
> Well that was facile of me. I was thinking universities didn't teach
> fortran anymore, but I see that the UNC research computing support group
> currently supports three brands (gnu, intel, and portland) for each of
> all three of fortran, C, and C++ compilers.

Yeah ... pretty much every time a CS person incredulously wonders why 
anyone would *evuh* use such a horrible old language (Fortran of 
course), lots of physical scientists, chemists, astronomers, and others 
say something to the effect of "you can have my language when you pry it 
from my cold dead fingers."

The Fortran of today doesn't look much like F77, or F66.  Quite a modern 
little language there.  And it optimizes very well.  Just doesn't know 
much about parallelism ... no wait, f2008 does.

Fortran was described first in a paper in 1957 by Backus and team.  This 
is a 56 year old language, and its still going strong.  Rumors of its 
demise are something of an exaggeration.  Whats more amusing than these 
rumors, are the myriad of (fad) languages proposed to take over its 
heavy lifting.

I have to admit that my mad 4tran skillz are atrophying due to lack of 
use.  Mostly a Perl, C, and (oh my gosh) Node coder these days.  Every 
once in a while I'll pull out some of my old (20+ year old) code to play 
with it.  The Fortran and Perl work.  C ... its a toss up, and the C++? 
  Fuggedaboutit.  I won't even think to try the Pascal, Modula2, and 
other bits I played with (anyone remember Prolog or APL?).

To circle back to beowulfery ... I think that what matters most is 
finding something you can be productive with, and run in parallel on a 
distributed memory/shared nothing architecture.  This is what Beowulfery 
enables (though with vSMP you can have the best of both worlds).  Having 
a language that enables you to naturally express your problem, and that 
knows how to map correctly onto the underlying architecture ... that 
would be wonderful.  That is the hard problem implicit in this.  Fast 
serial code often doesn't make terribly good parallel code, and 
sometimes poor serial code winds up showing excellent parallel 
capability, though you often have to graft the parallelism onto the code 
... so its not quite serial anymore.

And that is, in beowulfery, where many code defects I see come from. 
Getting parallelism right is non-trivial at best.  Compilers cannot be 
made infinitely smart, they don't do a great job of hyperoptimizing to 
the parallel/serial architectures.  They have to make engineering 
tradeoffs between faster and more correct/accurate.  Some times 
combining these tradeoffs with elements of the code design can lead to 
... erm ... spectacular failures.

-- 
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics, Inc.
email: landman at scalableinformatics.com
web  : http://scalableinformatics.com
        http://scalableinformatics.com/siflash
phone: +1 734 786 8423 x121
fax  : +1 866 888 3112
cell : +1 734 612 4615