slow exe with trial?/fast exe with buy?

[djbenton]

I am running a large FORTRAN (100K lines) legacy code on Windows-XP using Pentium class machines. When I compile the source code on my machine (a Dell desktop with a P4) using the trial version of the compiler I get an executable that runs slower than a herd of snails stampeding up the side of a salt dome. When my associate compiles the same source code on his machine (a Dell laptop with a P4M) using the same compiler switches (not using the /host switch) using a purchased version of the compiler he gets an executable that's significantly different in size and runs significantly faster. We've tried several combinations of optimization switches including target processor switches and the same thing happens. We answered the installation questions the same (default) for setting up the environment and defaults. What gives? Is this a limitation of the trial version or a quirk of the host processor or what? We're both running XP.

[Steven_L_Intel1]

What exact versions of the compilers do you have? You mention a /host switch which doesn't exist in the Intel compilers.

There is no difference between the trial and purchased compilers. Same actual product - just the license key is different. What happens when you run his EXE on your system? What versions of Visual Studio do you have installed?

[djbenton]

We're both using the same copy of Visual Studio .NET 2003 that we got with a MSDN universal subscription.

We're both using Intel FORTRAN 9.1. I'm not sure about any more minor version specs; but I'll check.

The "host" option I mentioned is the /Qsomething option that isn't in the /help listing; but my associate found somewhere in the documentation that optimizes for processor type that the compiler is currently running on.

The guy with the laptop is out of the country until next month. For now we're sending stuff back and forth through Email. When he returns I plan to sit his machine next to mine and do a file-by-file comparison until I find something; but even if I find a difference it won't answer why.

[Steven_L_Intel1]

Well, there is no host option in the Intel compiler. We had that with the DEC/Compaq compilers.

I suggest compiling with /watch which will show all the options passed to the compiler. But more interesting would be to swap EXEs and see if the performance degradation follows the EXE. Also specify /what which will show the exact compiler version.

[djbenton]

I just did get a bundle of files from the other guy, whose name, by the way, is Paul. He sent modified source code, a new batch file with some different optimization switches, and 3 executables (P4, D, and CF targets). I'll recompile the code and see what I get.

By the way... when he runs my executables on his machine it runs slow too. Also, I generated these slow executables before I changed anything in the setup like moving files around or deleting unnecessary folders. I also just found out that he may be returning as soon as this coming Monday.

You've been so helpful! I just can't tell you how unusual it is to get any response from a primary source such as Intel! It's truly remarkable to interact with a human that has even driven past the headquarters of the company in question. Thanks again!

[Steven_L_Intel1]

Glad to be of help. Rearranging folders and files should not have any impact. I'm guessing that, somehow, you're not building with the same optimization options.

[djbenton]

I finally got the new code compiled and linked with the new batch file. It took me this long; because the linker kept insisting on searching for things along the paths C:Program FilesInteldownloadFORTRAN... and C:Program FilesMicrosoft Visual Studio... and I never install things there (Paul does). It's a pet peeve of mine. I always edit installation paths, changing them to C:IntelFORTRAN91, C:Visual Studio, etc. Why would anyone want every software product they've got installed under the Program Files folder?

Anyway, I got an exe of similar, though not identical size. I don't know why it isn't exactly the same. The strange thing is, it now runs as fast as Paul's version. I'm confused; but at least the situation has gone from being a problem to being a curiosity. I still plan to run some tests when Paul gets here next week. I have the previous batch files; so perhaps I can duplicate the problem and learn something from it.

If I figure something out I will let you know.

One thing I noticed was that before when I got to the link step it did a whole lot of processing and wrote out a whole lot of messages about what it was doing with the individual functions (The source code is separated by subroutines.). And it took 15 minutes to link. That's when it produced the slow executable. This time it didn't write out much of anything and only took a minute or so to link, producing a fast executable. Go figure. So what. The linker optimized the inter-function calls and made it slower?

[Steven_L_Intel1]

You can specify the path where you want files installed when you install. If you then moved files afterward, you have to find all the places the compiler wrote out the paths and change them too. It does not have C: hardcoded.

You must be using a different set of compile options now.