topic Executable size in Intel® Fortran Compiler

Executable size

lklawrie — Thu, 14 Mar 2013 11:21:10 GMT

Our rather large executable just went from 22MB to 39MB (several developers have added to the code but mostly bug fixes).

What should I look for to see what caused the change?

IVF 13. Latest update

You can reduce the code size

jimdempseyatthecove — Thu, 14 Mar 2013 12:23:47 GMT

You can reduce the code size by reducing the number of processor designs. Look at /Qx{code}, /Qax{code}, /arch:{code} and /QxHost

Also, Interprocedural Optimizationqs (IPO) are enabled by default. This performs more inlining of code (increases code size to reduce execution time). Use /Qip to control the degree of or disable IPO.

Jim Dempsey

New compiler releases

TimP — Thu, 14 Mar 2013 14:40:26 GMT

New compiler releases continually tinker with thresholds for in-lining, so Jim's suggestions are good.

You might also try dumpbin /dependents to see if you changed any libraries from .dll to static link.

I'm talking about no change

lklawrie — Fri, 15 Mar 2013 12:17:20 GMT

I'm talking about no change in compiler settings from one to the next. Same compiler. I don't necessarily want to reduce code size. I want to know why it suddenly changed -- is there something in the code that would cause that?

That ratio of size change is

andrew_4619 — Fri, 15 Mar 2013 14:25:05 GMT

That ratio of size change is what I from release (with no traceback info) to full debug configuration.

>> I want to know why it

jimdempseyatthecove — Fri, 15 Mar 2013 14:43:00 GMT

>> I want to know why it suddenly changed -- is there something in the code that would cause that.

As stated earlier:

Newer compilers support newer processor features. Examples of which are: SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX2 (others?). When the compiler is instructed to compile for all supported processors, the compiler may elect to generate multiple code paths, where the choice of code path is made at run time (i.e. code can run fast on all platforms). The newer compilers will generally generate more code paths than prior compilers. You as a programmer, can elect to generate all code paths, some code paths, fewer code paths or one code path. The path(s) of which are under your control.

Newer compilers will also perform more aggressive inlining of code. Subroutine FOO may have been "CALL"'d by way of formal CALL instruction in earlier version for each CALL statement, but in newer compiler the body of FOO may have been inserted in place of the CALL statement (thus increasing code size while reducing execution time). You as the programmer can control the degree of inlining with /Qip... as well as with !DEC$ compiler directives.

It makes little sense for each improvement in compiler to default to NOT using those improvements.

Jim Dempsey

@Jimd... The OP did say he

andrew_4619 — Fri, 15 Mar 2013 15:09:30 GMT

@Jimd... The OP did say he has not changed compliler

Same compiler. Same settings

lklawrie — Fri, 15 Mar 2013 15:10:43 GMT

Same compiler. Same settings. Increase in size. No increase in debug info that I can remember. Same traceback setting.

I guess I will go through one by one with the changes in source.

Answered my own question.

lklawrie — Fri, 15 Mar 2013 19:50:58 GMT

Answered my own question. Was not any of the suggestions -- rather a static addition of array sizes. (rather than allocatable).