Executable Size

[e013805]

I am in the process of converting from the old Compaq FORTRAN to Intel FORTRAN version 11. I have noticed that for my particular program, the Intel executable is many times the size of the executable produced by the Compaq compiler ( 65,272 KB for Intel vs 14,577 KB for Compaq ). Both have debugging turned on. Do you have any ideas about how my executable might be slimmed down or what might be causing the bloat??

Thanks,

Don Durschmidt

[jimdempseyatthecove]

You can set the optimizations to favor size over speed.

Also, the newer compiler can (default) generate multiple code paths, one taken, depending on processor features. You can set options to restrict the generated code to a specific level(s) of features. This will reduce the number of code paths.

Jim Dempsey

[Steven_L_Intel1]

What's happening is that the run-time library is larger, due to more features (F2003, largely), and more of it is being pulled in to the EXE. If you're worried about "code bloat", compare the size of the .OBJ files, not the .EXE. If the size difference matters, link with the DLL libraries and your EXE will be smaller.

[e013805]

Quoting - Steve Lionel (Intel)

What's happening is that the run-time library is larger, due to more features (F2003, largely), and more of it is being pulled in to the EXE. If you're worried about "code bloat", compare the size of the .OBJ files, not the .EXE. If the size difference matters, link with the DLL libraries and your EXE will be smaller.

In a somewhat related issue perhaps, I also have a Java GUI which is linked to aDLL lib created in a separate project from the same FORTRAN code without the main program. In that case the DLL is about twice the size of the one produced by the Compaq compiler ( 49,680 KB for Intel vs 25,737 for Compaq ). I have two separate 32 bit Windows XP test machines. I can execute the Compaq version of the DLL on both. And I can execute the Intel version of the DLL on one ( the old one with 3.0 GB of RAM ), but on the second machine, the launch crashes from Java (1.6.0_01) with the message "not enough storage is available to process this command" when it attempts to load the DLL. The machine itself has plenty of RAM ( 3.25 GB ). Any advice on how to "fix" the Intel DLL so it will load or how to tell Java that it can grab enough RAM to load the DLL??

Thanks for any help.

[Steven_L_Intel1]

I can't imagine what would add 25MB of size just by changing compilers. Perhaps you could open an issue at Intel Premier Support and attach a ZIP of your project so that we can take a look.

I don't think the amount of RAM on the system is all that important - but if the code and data size approaches 2GB, you may run into issues.

[e013805]

Quoting - Steve Lionel (Intel)

I can't imagine what would add 25MB of size just by changing compilers. Perhaps you could open an issue at Intel Premier Support and attach a ZIP of your project so that we can take a look.

I don't think the amount of RAM on the system is all that important - but if the code and data size approaches 2GB, you may run into issues.

Well, in the conversion from Compaq to Intel, this is kind of a show stopper for us. We have both a "batch" version of our program and a GUI version. The Intel batch version works just fine - though it did produce a significantly bigger executable. The GUI version not so fine.

The project is huge and highly proprietary to Honeywell Aerospace. Composed of more than 2000 routines, and two extra FORTRAN libraries. Additionally there is C code ( built with the C compiler that is part of Visual Studio 2005 ) and Java code built with netbeans.

I did a little test with the java.exe where I specified the heap size with the Xmx command. The highest value I could give it ( without being told that I could not ask for that much heap ) was 834M and it still crashed with the "not enough storage" message.

Any suggestions on how to figure out exactly what is wrong would be greatly appreciated.

[TimP]

Quoting - e013805

"not enough storage is available to process this command" when it attempts to load the DLL. The machine itself has plenty of RAM ( 3.25 GB ). Any advice on how to "fix" the Intel DLL so it will load or how to tell Java that it can grab enough RAM to load the DLL??

A common situation with XP32 is unexpected resident applications hogging virtual space. You would have to clean up the installation by trial and error to make more space available. No doubt some of the special Windows utilities could help you identify the culprits, but I'm no expert on that.

[Steven_L_Intel1]

I guess the first thing I would do is ask for a link map and see which modules contributing to the DLL are significantly larger than for CVF. This is a linker property. The map will show the "address range" for each object module.

[e013805]

Quoting - Steve Lionel (Intel)

I guess the first thing I would do is ask for a link map and see which modules contributing to the DLL are significantly larger than for CVF. This is a linker property. The map will show the "address range" for each object module.

I did find a "Generate mapfile" command under the linker in Visual Studio 1998 where my Compaq compiler resides - though understanding the file it generated looks a bit difficult. There is a colum titled "Rva+Base" with numbers that sort of look like hex except lower case letters.

I do not see a similer command in Visual Studio 2005 under the linker for my DLL project there. Any suggestions?

[Steven_L_Intel1]

Linker > Debug > Generate Map File

You want to look at the differences between Address values. You might first look at the earlier section with Start and Length to identify the image section that is larger.

[e013805]

Quoting - Steve Lionel (Intel)

Linker > Debug > Generate Map File

You want to look at the differences between Address values. You might first look at the earlier section with Start and Length to identify the image section that is larger.

Yikes. Very strange stuff in those files. I have attached them ( I hope ).

Does anything in there jump out at you?

Thanks.

[Steven_L_Intel1]

Looks as if the Intel build is a Debug configuration, but not the Compaq build. Also, the Intel build is linked statically but the Compaq build is linked to the DLL libraries. What are the command line options shown in the Fortran > Command Line property page for the Intel build?

Even so, data sizes seem much larger than I would have expected.

[e013805]

Quoting - Steve Lionel (Intel)

Looks as if the Intel build is a Debug configuration, but not the Compaq build. Also, the Intel build is linked statically but the Compaq build is linked to the DLL libraries. What are the command line options shown in the Fortran > Command Line property page for the Intel build?

Even so, data sizes seem much larger than I would have expected.

Looks like this

/nologo /debug:full /Od /fpp /I"..Includes" /DIntelWindows /warn:interfaces /real_size:64 /module:"Debug" /object:"Debug" /traceback /check:bounds /libs:static /threads /dbglibs /c

Actually I think both are debug builds as the CVF library build ( which goes into the DLL build )options are these:

/check:bounds /compile_only /dbglibs /debug:full /fpp /iface:nomixed_str_len_arg /imsl /include:"../Includes" /list:"Debug/" /nologo /real_size:64 /show:include

[Steven_L_Intel1]

Do you see similar differences for a release build? Are any of the .obj files built by IVF noticeably larger than those from CVF?

[e013805]

Quoting - Steve Lionel (Intel)

Do you see similar differences for a release build? Are any of the .obj files built by IVF noticeably larger than those from CVF?

We have never actually used the "release" feature.

The largest subroutine is called WINDOW_ON_THE_FLY, for the CVF build the obj file is 533 KB and for the IVF build it is 1,954. The second largest is called PLOT_ON_THE_FLY with numbers of 408 KB for CVF and 1,246 KB for IVF.

Amiddle sizedroutine is PARSE_TABLE_VS which is 108 KB for CVF and 220 KB for IVF.

[Steven_L_Intel1]

For WINDOW_ON_THE_FLY, please show the results from the following command for each object:

dumpbin WINDOW_ON_THE_FLY.obj

You'll need to do this from a Fortran build environment command prompt. You can use the same window to show the results for both the CVF and IVF object. You should get output that looks like this:

File Type: COFF OBJECT

Summary

6C .data
B7 .drectve
40 .rdata
3B0 .text

[e013805]

Quoting - Steve Lionel (Intel)

For WINDOW_ON_THE_FLY, please show the results from the following command for each object:

dumpbin WINDOW_ON_THE_FLY.obj

You'll need to do this from a Fortran build environment command prompt. You can use the same window to show the results for both the CVF and IVF object. You should get output that looks like this:

File Type: COFF OBJECT

Summary

6C .data
B7 .drectve
40 .rdata
3B0 .text

OK, for the Compaq object file I get this:

Dump of file WINDOW_ON_THE_FLY.obj

File Type: COFF OBJECT

Summary

70 .bss
4 .data
9A4 .debug$S
58 .debug$T
BF .drectve
E0 .rdata
47610 .text
3B01 .trace

And for the Intel object file I get this:

Dump of file WINDOW_ON_THE_FLY.obj

File Type: COFF OBJECT

Summary

197E4 .debug$S
170 .debug$T
B8 .drectve
A800 .rdata
1049A0 .text
822C .trace

[Steven_L_Intel1 · Accepted solution]

Try the Intel build with /check:bounds disabled. My guess is that the size will be much smaller. The Intel-generated error message has much more information than the CVF message, but this takes more code.

[e013805]

Quoting - Steve Lionel (Intel)

Try the Intel build with /check:bounds disabled. My guess is that the size will be much smaller. The Intel-generated error message has much more information than the CVF message, but this takes more code.

WOW!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

My FORTRAN .lib file went from 92,700 KB with bounds checking to 52,800 without

My DLL file went from 49,680 KB with bounds checking to 19,240 without

Which begs the question, why did whoever programmed this very useful feature into the compiler make it so costly in executable size??? Ouch!

Not only does it slim down the dll by 61%, it solves the java "not enough storage" problem when it launches using the dll.

Steve, thank you very, very, very much for your valuable assistance.

[Steven_L_Intel1]

I'm glad that I was able to help. As to why - we had many requests to provide more information than CVF, which said simply that a bounds violation had occurred. What we do now is report the variable name, the index number, the attempted index and the declared bounds of the array. All of this requires more code and data. Yes, it could be streamlined in some ways, but it's not typically an issue for debuig builds. Initially, every array reference created its own copy of the message text, which made things MUCH worse. That at least was fixed so that there was only one copy per routine.