Xref: utzoo comp.lang.fortran:820 comp.lang.c:10957 Path: utzoo!attcan!uunet!lll-winken!lll-lcc!mordor!joyce!sri-unix!garth!smryan From: smryan@garth.UUCP (Steven Ryan) Newsgroups: comp.lang.fortran,comp.lang.c Subject: Re: Should I convert FORTRAN code to C? Summary: What's more important? Your time or the computer's time? Message-ID: <817@garth.UUCP> Date: 27 Jun 88 22:21:21 GMT References: <2742@utastro.UUCP> <20008@beta.UUCP> <224@raunvis.UUCP> <750@garth.UUCP> <528@philmds.UUCP> Reply-To: smryan@garth.UUCP (Steven Ryan) Organization: INTERGRAPH (APD) -- Palo Alto, CA Lines: 70 >So what IS FORTRAN's game? Running big huge numerical models like a bat out of hell. Watching people getting bigger and faster computers is like watching a heroin addict: more! more! MORE! People who say nasty things about fortran are right, but what have they to offer? >A few remarks: >A C programmer can CHOOSE (note: uppercase 8-) whether he wants arrays >to be global, static or automatic. By only offering static allocation, the compiler does not have to support any overhead at all. A C program must keep the stack pointer correctly aligned and rest of the protocol straight even if it doesn't use the stack because somebody it calls may use the stack. Similarily, in supporting recursion, the stack has to be maintained in case some called program needs the stack. Further, supporting recursion means all automatic variables must be mapped into the stack because the procedure may recurse indirectly. Forbidding recursion means the compiler can map automatic variables into static areas. However convenient it might be, recursion is not strictly necessary in practical programs. In some numeric models, it would actually be inconvenient. This is another case where fortran gives up something of questionable value (for them) to simplify optimisation. (However, we can always use a transitive closure which takes (?)cubic time to detect recursion, but most customers would rather a fast compiler.) > (zero overhead is >rubbish; you always have to page or swap the data in, whether you use data >/heap space or stack space, or you at least have to claim core). Pagein cost vs. pagein + computation cost. > procedure frame are more >or less for compiler builders: you can do without them, making it much >harder for yourself Unless it is impossible for a procedure to recurse, directly or indirectly, local variables must be mapped onto the stack. You cannot avoid this overhead without avoiding recursion. > Dropping off these things (call, push ..) >can only gain a few percent, at what other cost (inflexible subroutine >scheme, permanent variables)? You can even totally rule out any use of >subroutines if you're out for speed: large monolotic blocks with many >pieces of repeated code, is that desirable? Unfortunately--some people do find that desirable. As far as few cycles, look back a few weeks when somebody said a C function should make the argument list length available. Many jumped on the poor guy because they didn't want their code to waste the single instruction necessary to load a register. Please, don't suggest I want speed or I find this desirable. My favorite compiler was an Algol60 compiler. I never turned off array bound checks or switch range checks. I think call-by-name (real call-by-name with deferred execution and not wimpy call-by-reference) is fun. The compiler permitted assembly procedures to have variable length lists. The calling protocol gave the parameter list length and a descriptor with type and kind for each element in the list. And the address of dope vector was passed along. >>Apparently some Fortran programmers equivalence different typed arrays to >>create structures (shudder). Some fortran programmers use the EQUIVALENCE statement to adjust the beginning address of different arrays with different types so that they map their elements into interleaved storage. Don't know details--just heard about some of things they do just to stay in fortran. Like using blank common as a heap.