create a fast program

[pjkldeo]

I have these two questions about the ifort fortran compiler that I cannot answer myself and was wondering if anyone could answer them for me.

RE: OSX 10.5.8/ Intel core2 Duo/ ifort 10.0.016

The first is, how can I force the applications I build to look for input files and create input file in the local directory? It's bothersome to both enter a path or move back and forth between the working dir. and my home dir where output files always end up.

The second question, and this is more valuable to me, is how to make a native 64 bit program with the ifortcompiler on an imac? I am compiling f77 code using a simple shell script for kernal calls.

if I do this I can create an executable,

ifort -c -extend_source -g -nus pjk3_Intel.f

ifort -o pjk3_Intel pjk3_Intel.o

but when I do this

ifort -c -extend_source -g -nus -ipo pcregpjk3_Intel.f

ifort -fast pcregpjk3_Intel pcregpjk3_Intel.o

I get a bunch of ipo warnings that conclude with

ld: file not found: pjk3_Intel

What am I not doing that I should?

[Ron_Green]

Quoting - pjkldeo

I have these two questions about the ifort fortran compiler that I cannot answer myself and was wondering if anyone could answer them for me.

RE: OSX 10.5.8/ Intel core2 Duo/ ifort 10.0.016

The first is, how can I force the applications I build to look for input files and create input file in the local directory? It's bothersome to both enter a path or move back and forth between the working dir. and my home dir where output files always end up.

The second question, and this is more valuable to me, is how to make a native 64 bit program with the ifortcompiler on an imac? I am compiling f77 code using a simple shell script for kernal calls.

if I do this I can create an executable,

ifort -c -extend_source -g -nus pjk3_Intel.f

ifort -o pjk3_Intel pjk3_Intel.o

but when I do this

ifort -c -extend_source -g -nus -ipo pcregpjk3_Intel.f

ifort -fast pcregpjk3_Intel pcregpjk3_Intel.o

I get a bunch of ipo warnings that conclude with

ld: file not found: pjk3_Intel

What am I not doing that I should?

For 64bit for your compiler, you can enter the command:

source /opt/intel/fce/10.0.016/bin/ifortvars.sh

for 32bit:

source /opt/intel/fc/10.1.016/bin/ifortvars.sh

You need -o pcregpjk_Intel if the name of the executable is to be pcregpjk_Intel. You missed the -o in front of that name.

Your program should look in the directory where the executable is located for input files, and put output files there so long as the OPEN statements do not use full paths: like OPEN(FILE="myoutput", ...etc ....)

Are you running from the Command Line or from within Xcode? What do your OPEN statements look like? And you don't use 'sudo' when you run the code do you?

ron

[pjkldeo]

Quoting - Ronald W. Green (Intel)

For 64bit for your compiler, you can enter the command:

source /opt/intel/fce/10.0.016/bin/ifortvars.sh

for 32bit:

source /opt/intel/fc/10.1.016/bin/ifortvars.sh

You need -o pcregpjk_Intel if the name of the executable is to be pcregpjk_Intel. You missed the -o in front of that name.

Your program should look in the directory where the executable is located for input files, and put output files there so long as the OPEN statements do not use full paths: like OPEN(FILE="myoutput", ...etc ....)

Are you running from the Command Line or from within Xcode? What do your OPEN statements look like? And you don't use 'sudo' when you run the code do you?

ron

Dear Ron,

Thanks for the quick reply! In reverse order, taking the issue of how I invoke the compiler first, I am a hold out from the old days. I make a simple command file in which are written the lines of instructions for the kernal e.g.,

clear

rm *.o

# compile source

ifort -c -extend_source -g -nus pjk3_Intel.f

#link objects create executable

ifort -o pjk3_Intel pjk3_Intel.o

Executing this file to produces the program pjk3 in the example above.

With regards to the default directory for input and output files, my open statements typically look like this;

c for existing files

open(iu6,file='pjk3_out.txt',status='old',readonly)

c for new files

open(iu6,file='pjk4_out.txt',status='unknown')

What I found is with the ifort compiler both files are either created or must be in my home dir. (unless I explicitly include the path with the file name e.g.,file='/opt/intel/fce/pjk3_out.txt'

Getting back to the create a 64 bit application, are you saying the following?

clear

rm *.o

source /opt/intel/fce/10.0.016/bin/ifortvars.sh

# compile source

ifort -c -extend_source -g -nus -ipo pjk3_Intel.f

#link objects create executable

ifort -fast pjk3_Intel pjk3_Intel.o

or

clear

rm *.o

source /opt/intel/fce/10.0.016/bin/ifortvars.sh

# compile source

ifort -c -extend_source -g -nus -ipo pjk3_Intel.f

#link objects create executable

ifort -o pjk3_Intel pjk3_Intel.o

What about the -o3 and -fast options, what are they for?

Sincerely,

paul

[Kevin_D_Intel]

You only need to source the ifortvars.sh/ifortvars.csh (the version used depends on your working shell) script once interactively to setup your shell working environment to then be able to use the compiler interactively or via scripts. You do not need to embed the source command in your command file.

So, to create the 64-bit executable you need to source the fce version using the command Ron provided so invocations of ifort use the 64-bit compiler.

What he was saying about your command-line for the second execution of ifort in your command file (which performs the link) is that you omitted the -o (lower-case) option that names the executable pjk3_Intel. The correct syntax is (highlighting your omission):

ifort -fast -o pjk3_Intel pjk3_Intel.o


As for the -fast, -O3 (upper-case O) options for the older 10.0 compiler you have:

-fast : Maximizes speed across the entire program. On systems using IA-32 architecture and Intel 64 architecture, the option includes these options on:

Mac OS X: -ipo, -mdynamic-no-pic, -O3, -no-prec-div, -static

-O{n} : Specifies the code optimization for applications.

-O3 : Enables -O2 optimizations plus more aggressive optimizations

Additional details are available in the Users Guide on your system under /opt/intel/fce/10.0.016/doc/doc_files or available online (here)


If you use -fast or -O3, then provide it on both invocations of ifort in your command file. For an example of using -fast, use these commands:

clear
rm *.o
# compile source
ifort -c -fast -extend_source -g -nus pjk3_Intel.f
#link objects create executable
ifort -fast -o pjk3_Intel pjk3_Intel.o

Hope that helps.

[pjkldeo]

Quoting - Kevin Davis (Intel)

You only need to source the ifortvars.sh/ifortvars.csh (the version used depends on your working shell) script once interactively to setup your shell working environment to then be able to use the compiler interactively or via scripts. You do not need to embed the source command in your command file.

So, to create the 64-bit executable you need to source the fce version using the command Ron provided so invocations of ifort use the 64-bit compiler.

What he was saying about your command-line for the second execution of ifort in your command file (which performs the link) is that you omitted the -o (lower-case) option that names the executable pjk3_Intel. The correct syntax is (highlighting your omission):

ifort -fast -o pjk3_Intel pjk3_Intel.o


As for the -fast, -O3 (upper-case O) options for the older 10.0 compiler you have:

-fast : Maximizes speed across the entire program. On systems using IA-32 architecture and Intel 64 architecture, the option includes these options on:

Mac OS X: -ipo, -mdynamic-no-pic, -O3, -no-prec-div, -static

-O{n} : Specifies the code optimization for applications.

-O3 : Enables -O2 optimizations plus more aggressive optimizations

Additional details are available in the Users Guide on your system under /opt/intel/fce/10.0.016/doc/doc_files or available online (here)


If you use -fast or -O3, then provide it on both invocations of ifort in your command file. For an example of using -fast, use these commands:

clear
rm *.o
# compile source
ifort -c -fast -extend_source -g -nus pjk3_Intel.f
#link objects create executable
ifort -fast -o pjk3_Intel pjk3_Intel.o

Hope that helps.

Dear Kevin,

Yes, very much so! It works and speed wise, is a marked improvement over the mrwe application I was using. But.... What is your take on the fact that the application, by default, is tied to my home directory for all input and output files???

I sincerely appreciate all the responses from this forum, they have been immensely helpful and efficient.

Thanks!

pjk

[Kevin_D_Intel]

The wiring of the OPEN to the home directory is odd. I do not know what might cause that. We have an extension, DEFAULTFILE that allows defining a default path which seems to match the described behavior, but I do not expect you are using this.

I am unable to reproduce this too. I see the behavior Ron described. I tested the older 10.0 on at least Mac OS 10.5.6. It's possible the older 10.0 compiler may not be entirely working correctly on your newer OS. 10.0 last officially supported 10.4.9. If there is a possibility of you moving to our latest 11.1 release then you really should. You may even see better performance with 11.1 vs. the older 10.0 release.

Is this behavior reproducible with just a small program with just a single open and a read or write?

Places to look perhaps are the environment settings to see if theres anything there. I don't have anything specific in mind to look for. If you want to capture 'env' to a file and attach to this thread then we can look at those.

[pjkldeo]

Quoting - Kevin Davis (Intel)

The wiring of the OPEN to the home directory is odd. I do not know what might cause that. We have an extension, DEFAULTFILE that allows defining a default path which seems to match the described behavior, but I do not expect you are using this.

I am unable to reproduce this too. I see the behavior Ron described. I tested the older 10.0 on at least Mac OS 10.5.6. It's possible the older 10.0 compiler may not be entirely working correctly on your newer OS. 10.0 last officially supported 10.4.9. If there is a possibility of you moving to our latest 11.1 release then you really should. You may even see better performance with 11.1 vs. the older 10.0 release.

Is this behavior reproducible with just a small program with just a single open and a read or write?

Places to look perhaps are the environment settings to see if theres anything there. I don't have anything specific in mind to look for. If you want to capture 'env' to a file and attach to this thread then we can look at those.

Dear Kevin,

I understand now better the behavior of the file/open/home dir. dilemma. It occurs when I launch a terminal app using my computer gui os (ie. double clicking on the file) if instead I navigate my way to the working dir. in a terminal window, then launch the application with a ./myprog the home directory dependancy goes away. I can live with this for now.

Thanks again to all for their help and advice. It has been a learning experience. However, it sure is strange to receive an accolade (green-belt) for posting silly questions as opposed to intelligent answers.

Sincerely,

pjk

[Steven_L_Intel1]

Quoting - pjkldeo

However, it sure is strange to receive an accolade (green-belt) for posting silly questions as opposed to intelligent answers.

Woody Allen once said, "80 percent of success is just showing up". Now that you've asked questions you'll be ready to start answering them! Stick around!