|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
Ian Wright
Joined: 02 Apr 2009 Posts: 13 Location: Epsom, UK
|
Posted: Tue Jun 27, 2017 3:10 pm Post subject: FTN95 v8.1 - very large executables compared to v6.35 |
|
|
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 |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Tue Jun 27, 2017 4:13 pm Post subject: |
|
|
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..... |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Wed Jun 28, 2017 12:30 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2828 Location: South Pole, Antarctica
|
Posted: Sat Jul 01, 2017 12:29 am Post subject: |
|
|
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 |
|
Back to top |
|
|
Ian Wright
Joined: 02 Apr 2009 Posts: 13 Location: Epsom, UK
|
Posted: Mon Jul 17, 2017 7:10 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Mon Jul 17, 2017 8:57 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1892
|
Posted: Mon Jul 17, 2017 11:06 pm Post subject: Re: |
|
|
Ian Wright wrote: | 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.
Code: |
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.
Last edited by mecej4 on Wed Jul 19, 2017 2:57 am; edited 1 time in total |
|
Back to top |
|
|
Ian Wright
Joined: 02 Apr 2009 Posts: 13 Location: Epsom, UK
|
Posted: Tue Jul 18, 2017 8:13 pm Post subject: |
|
|
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
_ |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Wed Jul 19, 2017 12:26 am Post subject: |
|
|
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 |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Wed Jul 19, 2017 1:24 am Post subject: |
|
|
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) |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Wed Jul 19, 2017 8:14 am Post subject: |
|
|
/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. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|