Path: utzoo!attcan!uunet!wuarchive!rex!samsung!xylogics!merk!alliant!cantrell
From: cantrell@Alliant.COM (Paul Cantrell)
Newsgroups: comp.sys.alliant
Subject: Re: job classes
Message-ID: <4067@alliant.Alliant.COM>
Date: 15 Aug 90 18:05:37 GMT
References: <1990Aug10.112530.720@eagle.lerc.nasa.gov> <4059@alliant.Alliant.COM> <1990Aug14.115752.23746@eagle.lerc.nasa.gov>
Reply-To: cantrell@alliant.Alliant.COM (Paul Cantrell)
Organization: Alliant Computer Systems, Littleton, MA
Lines: 59

In article <1990Aug14.115752.23746@eagle.lerc.nasa.gov> xxrich@alliant1.lerc.nasa.gov (Rich Rinehart) writes:
>via makefiles.....
>
>fortran -c node.f
>fortran -Ogv -o n node.o /usr/local/intel/bsimlib.a
>-wants to run on the complex
>
>fortran -c node.f
>fortran -Ogv -nc -o node node.o /usr/local/intel/bsimlib.a
>-makes it run on individual ce's, which is what i wanted.

Right. But what I would have suggested would be:

fortran -Ogv -c node.f
fortran -o node node.o

which would avoid generating any concurrency instructions at all.

First thing to realize here is how the "fortran" or "cc" commands work
under unix. They try to do any compilations necessary, and then invoke
the linker for you. Many other operating systems require you to invoke
the linker by yourself. This feature of unix annoyed me the first few
weeks I used it until I got used to it.

What this means is that the line:

	fortran -c node.f

actually invokes the compiler to take node.f and compile it into a
relocatable binary. Since you didn't specify any level of optimization,
it assumed -Ogvc (the most agressive). It generated node.o which contains
possibly both vector and concurrency instructions.

Then you issued the command:

	fortran -Ogv -o n node.o /usr/local/intel/bsimlib.a

Since there are no .f files to be compiled in this line, the fortran
compiler actually never gets invoked, and the command just causes the
linker to run. The -Ogv command gets ignored by the linker, which then
proceeds to build "n" out of "node.o" and the library. Since "node.o"
contains concurrency instructions, the linker sets the "n" executable
file to require concurrency hardware, thus the OS will try to run it on
a complex if one exists.

So the basic problem you had was not specifying the -Ogv switch at the
time that the program got compiled. The reason that the -nc switch caused
the behavior that you desired was that this is indeed a linker switch
which caused the executable header to be bashed, indicating no concurrency
instructions in the file, when indeed there really are some in the program.

When the OS loads the program to run on a CE, the CE's concurrency hardware
will be turned off so that the embedded concurrency instructions will act
as nops. There may be a very minor performance penalty since you are executing
extra concurrency instructions. Just how much impact this has on performance
depends a lot on the exact structure of the loops. In general, I would expect
it to be fairly minor.

					Paul Cantrell