Hi

I've checked the FAQ and previous forum posts but I can't see our issue raised anywhere.

We've recently moved Salford FTN95 compilers from v6.35 to v8.10. Overall, we're happy with compilation and the differences in the numerical accuracy in the calculations are very small (in the iterative process we use).

The only problem we have so far is that the size of the executables has ballooned by a consistent factor of 18 (e.g. 2Mb → 36Mb, 6Mb → 108Mb). Is this to be expected or are we missing a newer compiler option to reduce them back to the previous sizes? I welcome your thoughts and suggestions

(Our default compiler options for the .LIB are /LIST /INTL /LOGL /EXPLIS with /DEBUG or /CHECK or /UNDEF as necessary. We should also add the /OPTIMISE).

Kind regards

Ian

Using the /CHECK option will definitely increase the size of the executable.

For my code, the difference between the /CHECK and the /RELEASE versions is about 20%, all using V8.10.0. Sorry I don't go back to 6.35.....

The difference in executable size between /optimise /debug /check and /undef can be progressively quite dramatic.

The other main influence can be the use of /save or using the SAVE attribute or DATA statements for large arrays.

Having lots of arrays that are ALLOCATE and using /optimise or /debug should result in a smaller executable. Size is mainly related to what arrays are 'imaged' in the executable.

John

I think Silverfrost had some way to find largest static arrays in memory but it was not convenient. Ideally to have in Debugger an option to see all largest arrays both static and dynamically opening in real time with just one single click

Thanks for the replies - it's given us a few pointers to explore further (see below). I should also clarify that we were using the following compiler options /LIST /INTL /LOGL /EXPLIS (with /DEBUG /CHECK and /UNDEF only used for development and debugging).

Today, I've managed to find a bit of time to re-compile the same code using Silverfrost v6.35, v7.1, v7.2 and v8.1 to explore the differences between release versions

The consistent 18x jump in executable sizes occurred when we switched from v7.1 to v7.2 with the same code and compiler options (and v8.1 executables are similar sizes to v7.2). Therefore, something has changed with the v7.2 compiler.

To check whether it's wider issue, I've also compiled another of our software products using v6.35 and v8.1. However, the executable sizes are identical so there's something specific about our particular code base for the first product.

I welcome any further thoughts as we're out of ideas - may be one for Silverfrost support?

Thanks

Ian

I would look at the FTN95 command line options as viewed from the lis file. The most likely reason for the change in size is the use of /save and or /undef (say) with these applied in some indirect way such as via a ftn95.cfg config file.

The lis file should show the actual options in use.

I assume that the builds for the different versions are made on the same machine. If not then there may be other factors that come into play.

Quoted from Ian Wright The consistent 18x jump in executable sizes occurred when we switched from v7.1 to v7.2 with the same code and compiler options (and v8.1 executables are similar sizes to v7.2). Therefore, something has changed with the v7.2 compiler.

To check whether it's wider issue, I've also compiled another of our software products using v6.35 and v8.1. However, the executable sizes are identical so there's something specific about our particular code base for the first product.

I ran a test on a medium size package, which uses the JPL maths library ( http://www.netlib.org/math/index.html ) to solve the NIST NLS problem set ( http://www.itl.nist.gov/div898/strd/nls/nls_main.shtml ).

I used /opt /p6 to compile 32-bit objects, and find that FTN95 7.1 and 7.2 gave identical OBJ file sizes. FTN95 8.1 gave OBJ file sizes that differed by less than 1 percent in size. The EXE sizes were nearly identical.

                7.1     8.1                
                                           
amachsal.obj   1,124   1,124               
compjpl.obj   35,740  35,702               
divset.obj    55,238  55,448               
dnlsfu.obj     5,016   5,016               
dq7rfh.obj     4,520   4,520               
drn2g.obj     23,096  23,404               
drnsg.obj      7,792   7,792               
idsm.obj       7,994   7,994               
                                           
EXE          140,520 141,000 bytes         

Perhaps you can do a side-by-side comparison with two different compiler versions, using the same set of compiler options (check your FTN95.CFG files first!) and then compare the sizes of the individual object files in your project.

Paul / mecej4

Thanks again for the additional suggestions. We've now identified the source of the problem but not why it occurs.

Our executables are compiled using a set of common libraries plus program specific object routines. The common libraries are generated using FTN95 /MKLIB with SLINK to combine the various OBJs & LIBs into executables.

The significant differences in executable size is due to the changes in size of the common libraries, but not the object routines, when using FTN95 /MKLIB command between FTN95 v7.1 and v7.2 compilers. For example, in v7.1 one of Common Libraries is 824Kb whereas in v7.2 it has grown to 11,428Kb.

However, if we convert the same Common library to .OBJ using FTN95 and separately run SLIM to produce the .LIB, the v7.1 and v7.2 .LIB sizes are identical at 689Kb. Our Main Program includes many common libraries and the executable size in v7.1 is 6.2Mb and 108.7Mb in v7.2.

It suggests that there's something odd with how we're using FTN95 /MKLIB between v7.1 and v7.2 but we don't know what! (As an aside, the .LIB files generated using SLIM are also smaller than the FTN95 /MKLIB route).

[Post update: I should confirm that we are not using the FTN95.CFG to add extra compilation parameters. Our standard compilation options are /LIST /INTL /LOGL /EXPLIS and are correctly reported in the .LIS file.]

I welcome any further thoughts & thanks again.

Ian

For information, the table compares the file sizes for the various permutations.

**All_values_in_Kb_____FTN95_/MKLIB_______FTN95.OBJ_then_SLIM **

**Routine____________Salf v7.1___Salf v7.2____Salf v7.1___Salf v7.2 **_ MAINPROG.FOR____________170________170_________170________170 MAINPROG.OBJ___________________________________106________106 MAINPROG.EXE___________6,174____108,731________7,302______7,302 _
*COMMONLIB1.FOR_________1,102______1,102_______1,102______1,102 COMMONLIB1.OBJ_________________________________682_______682 COMMONLIB1.LIB___________824_____11,428_________689_______689 *_

Ian,

I am surprised by your noted change from V7.1 to V7.2. It would be good if you could split up the program and report the size of the .obj files and .exe, as mecej4 has shown. When changing from 6 mb to 109 mb, can you identify what might be 103 mb in size ? I think you need to split mainprog.for into multiple files and report on the .obj files for the FTN95/MKLIB option. Even COMMONLIB1.LIB grew ? (I have 18 copies of FTN95 available but I did not install Ver 7.2, going from Ver 7.1 to Ver 8.0_beta1. Not sure why?)

I have given up on problems of .exe sizes. In comparison to other compilers, FTN95 typically produces very small .exe files. This is partly due to FTN95 using dynamic libraries, while some other compilers use a static build.

From my experience with FTN95, the size increases if I:

use /check or /undef

have large arrays that are saved, either with a /save or data

use clearwin+ routines

I have also noted some significant variation in .exe size with the different beta versions of V8.0, although V8.1 has cleaned that up in some cases. I still find V8.1 & clearwin+ with /64 appears to be larger than a few years ago.

Below is a list of .exe sizes for an analysis program I have been working on for a long time. FTN95 compiles: 1,439 KB v 4.5.0 20/10/2004 1,483 KB V 6.10 1/06/2012 1,598 KB v 7.10.0 23/10/2014 1,641 KB v 8.00 beta.14 4/2/2016 1,477 KB V 8.05 1/10/2016 1.491 KB V 8.10 18/07/2017

gFortran compiles: 1,246 KB gcc version 4.9.1 (MinGW-W64 project) 2,181 KB gcc version 5.3.1 20160512 (Silverthrone) 2,878 KB gcc version 4.9.1 (GCC equation.com) 3,006 KB gcc version 5.3.0 (GCC equation.com) 3,634 KB gcc version 6.2.0 (GCC equation.com) 4,976 KB gcc version 6.3.0 (GCC equation.com) 5,190 KB gcc version 7.1.0 (GCC equation.com)

There is considerably more variation between compilers, where FTN95 and MinGW use .dll's while Silverthrone and equation.com are static builds. All these compiles were for a release build, not a /check build.

I am actually surprised how little variation there is with FTN95 for the program I reviewed.

John

I found a history of some builds for a program including clearwin+. They indicate the use of /check increases .exe size. Ver 8.0 beta_1 produced a very large .exe but was later fixed.

1,662 KB [FTN95/x64 Ver. 8.10.0 9/03/2017 ( no /check ) 1,651 KB [FTN95/Win32 Ver. 8.00 beta.30 1/02/2016 ( no /check ) 9,195 KB [FTN95/Win32 Ver. 8.00 beta.1 14/10/2015 ( /64 so no /check) 2,673 KB [FTN95/Win32 Ver. 6.10.0 28/11/2011 (/check for 1 of 67 files) 4,072 KB [FTN95/Win32 Ver. 5.40.0 1/06/2010 (/check for 16 of 74 files) 2,532 KB [FTN95/Win32 Ver. 5.30.0 9/06/2009 (/check for 1 of 68 files)

/MKLIB causes FTN95 to spawn SLIM. SLIM is the library manager that creates static library archives from object code.

SLINK can also be used to create static library archives by using the 'archive' command.

If the output from SLIM is only used as input to SLINK then I can't see any advantage to calling SLIM. SLINK accepts both raw .obj files and .lib archives.

What SLIM does in this context is to change the file extension from .obj to .lib and (presumably) add some header information. (Maybe something clever happens if multiple files are compiled with one call to FTN95).

I can't think of any changes to FTN95 that might relate to this issue. It is just possible that using SLIM allows duplicates to occur or allows the inclusion of redundant routines but I don't see how this could happen.

I can only conclude that there is some subtle difference in the build processes that are being used. As a long shot, different operating systems have different limits on the length of a command line. So something that was previously ignored might come into play with a later operating system.