[Beowulf] g77 limits...

[Robert G. Brown]

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:rgb at phy.duke.edu