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: [email protected] web : http://scalableinformatics.com http://scalableinformatics.com/siflash phone: +1 734 786 8423 x121 fax : +1 866 888 3112 cell : +1 734 612 4615 _______________________________________________ Beowulf mailing list, [email protected] sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
