On Wed, 22 Feb 2006, Joe Landman wrote:
b) Alas, I'm probably going to have to become one (again).
Heh... people complained that I wrote my Perl, C, and even Assembler in
Fortran for a while. Now they complain that I write it all in C. Its not so
hard to switch back and forth. The hard part is the IO. Format statements
are annoying.
Yeah, I/O sucks. String manipulation in general used to suck. Column
indentation and continuation rules suck (if they're still there). Not
having structs and pointers sucks (I just LOVE to play pointer magic
games and roll my own data objects). All of which may well be doable
nowadays -- did I mention that it was fortran >>IV<< that I learned?
Running on an IBM mainframe running MVS, JCL, HASP and all that?
Although I did use the early IBM-PC Microsoft fortran compiler and some
proprietary fortran on some odd architectures (Harris 800 and its Vulcan
OS, with *6 and *12 variables).
Hopefully "modern" fortran is a whole lot closer to C and supports some
sort of struct/union or equivalent thereof, and some sort of dynamical
memory allocation.
c) Working on some problems with potentially very large memory
allocations.
Shouldn't be too hard using g95/gfortran. Can you look at out of core type
solutions (blocked access).
Don't know. FIRST the funding, THEN the work. No Way In Hell am I
going to learn fortran (again, any flavor) unless I have to, that is to
say "Will program for food"...;-)
d) Where commercial compilers aren't a viable option (although I
suggested them) -- the software has to build and be usable by e.g.
researchers in countries where there simply is no money to spend on
compilers.
Actually the code, if written to spec should be trivially portable between
the compilers, modulo some limits and vagaries of each compiler.
Ah, gotta love those words. "if". "should". "modulo limits and
vagaries". I still remember fondly cursing roundly and trying to change
all the REAL*8's in my code to REAL*12's in an era before real code
editors and decent operating systems.
Though I agree, sure, and said as much to greg. I'm HOPING that this is
possible, although just finding a common denominator a la F IV, F77,
F95, gfortran -- standards are your friend, sure, and F95 compilers can
PROBABLY still compile my old FIV sources, but stil...
The last suggests that it would be ideal if large arrays were at least
approximately "transparent" -- so that the software would build on 32
bit systems and be runnable there with smaller arrays but would also
build and run on x64 big-memory systems without the need for extensive
instrumentation of the code.
If you want to do this, you might look at the out of core methods. This
might not be realistic, depends upon your analysis.
If we get to where I'm am being paid to do so, I will do so. Now we're
more at the point of "can" we do this, if we must. Other than by
porting to C, of course, which is my OTHER really good solution:-)
rgb
Thanks,
rgb
(I know Toone works on this and am hoping he's paying attention so I can
get a really authoritative and informative answer...:-)
--
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED]
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
