Prev: passing a type of different KIND to a C function from Fortran ?binding
Next: ALLOCATABLE array as MPI buffer
From: steve on 3 Jun 2010 01:45
On Jun 2, 9:00 pm, Hifi-Comp <wenbinyu.hea...(a)gmail.com> wrote:
> On May 28, 9:25 am, Tobias Burnus <bur...(a)net-b.de> wrote:
>
>
>
> > On 05/28/2010 03:04 PM, Hifi-Comp wrote:
>
> > > I get the following error message after I execute: gfortran -Ofast -
> > > march=native -flto -fwhole-program test.f90
>
> > > f951.exe: error: invalid option argument '-Ofast'
>
> > Well, that option is really new - not even one week old. Thus, better
> > stick to -O3 -ffast-math  (assuming that your programs are -ffast-math
> > save).
>
> > > f951.exe: error: unrecognized command line option "-flto"
> > > Fatal Error: Option -fwhole-program is not supported for Fortran
> > > gcc version 4.5.0 20090421 (experimental) [trunk revision 146519]
>
> > That's more than one year old, i.e. you have essentially a 4.4.0-release
> > compiler and thus you miss essentially all new 4.5 features:http://gcc.gnu.org/gcc-4.5/changes.html
>
> > > I downloaded gfortran fromhttp://mingw-w64.sourceforge.net/. Where
> > > can I download a more recent build version of gfortran for WinXP?
>
> > 32bit or 64bit Windows? MinGW64 of course features the latter, but it
> > also has 32bit builds.
>
> > I have admittedly not a real overview about Windows builds; looking athttp://gcc.gnu.org/wiki/GFortranBinaries, I think you could try:
>
> >http://sourceforge.net/projects/mingw-w64/files/
>
> > MinGW (32bit):  Toolchains targetting Win32 -> Personal Builds
> > sezero_20100527 -> mingw-w32-bin_i686-mingw_20100527_sezero.zip
>
> > MinGW (64bit):  Toolchains targetting Win64 -> Personal Builds ->
> > sezero_20100527 -> mingw-w64-bin_x86_64-mingw_20100527_sezero.zip
>
> > The file names there follow the scheme <target>-<host>. Where "target"
> > is the system for which you want to compile for (e.g. "mingw-w64"
> > compiles for the 64bit version of Windows) and "host" means on which
> > system you want to compile (e.g. "i686-mingw" means that you want to
> > compile on 32bit windows). On that site you find also binaries to
> > compile for Window (or WINE ;-) on Linux or on Darwin/MacOS.
>
> > Tobias
>
> I can get similar speed using gfortran 4.6. However, I have the
> following two questions:
> 1. How is it possible that DNAD run is even more efficient than
> Analysis run?
> 2. The significant speedup is enabled mainly by -fwhole-program.
> However, it seems only applicable to a single file. If the real codes
> have many separate files and even including some dlls, how can we
> still achieve this? For example for my simple problem, if we put three
> separate files dnad.f90 containing module dnad, cputime.f90 containing
> module cputime, and test.f90 containg program test, how can the
> compilation and linking be optimized?

I see three questions instead of the two. The
answer to your question is to read the documentation supplied
with the compiler. See -lto -fprofile-generate -fprofile-use.
From: Hifi-Comp on 3 Jun 2010 07:24
On Jun 3, 1:45 am, steve <kar...(a)comcast.net> wrote:
> On Jun 2, 9:00 pm, Hifi-Comp <wenbinyu.hea...(a)gmail.com> wrote:
>
>
>
>
>
> > On May 28, 9:25 am, Tobias Burnus <bur...(a)net-b.de> wrote:
>
> > > On 05/28/2010 03:04 PM, Hifi-Comp wrote:
>
> > > > I get the following error message after I execute: gfortran -Ofast -
> > > > march=native -flto -fwhole-program test.f90
>
> > > > f951.exe: error: invalid option argument '-Ofast'
>
> > > Well, that option is really new - not even one week old. Thus, better
> > > stick to -O3 -ffast-math  (assuming that your programs are -ffast-math
> > > save).
>
> > > > f951.exe: error: unrecognized command line option "-flto"
> > > > Fatal Error: Option -fwhole-program is not supported for Fortran
> > > > gcc version 4.5.0 20090421 (experimental) [trunk revision 146519]
>
> > > That's more than one year old, i.e. you have essentially a 4.4.0-release
> > > compiler and thus you miss essentially all new 4.5 features:http://gcc.gnu.org/gcc-4.5/changes.html
>
> > > > I downloaded gfortran fromhttp://mingw-w64.sourceforge.net/. Where
> > > > can I download a more recent build version of gfortran for WinXP?
>
> > > 32bit or 64bit Windows? MinGW64 of course features the latter, but it
> > > also has 32bit builds.
>
> > > I have admittedly not a real overview about Windows builds; looking athttp://gcc.gnu.org/wiki/GFortranBinaries, I think you could try:
>
> > >http://sourceforge.net/projects/mingw-w64/files/
>
> > > MinGW (32bit):  Toolchains targetting Win32 -> Personal Builds
> > > sezero_20100527 -> mingw-w32-bin_i686-mingw_20100527_sezero.zip
>
> > > MinGW (64bit):  Toolchains targetting Win64 -> Personal Builds ->
> > > sezero_20100527 -> mingw-w64-bin_x86_64-mingw_20100527_sezero.zip
>
> > > The file names there follow the scheme <target>-<host>. Where "target"
> > > is the system for which you want to compile for (e.g. "mingw-w64"
> > > compiles for the 64bit version of Windows) and "host" means on which
> > > system you want to compile (e.g. "i686-mingw" means that you want to
> > > compile on 32bit windows). On that site you find also binaries to
> > > compile for Window (or WINE ;-) on Linux or on Darwin/MacOS.
>
> > > Tobias
>
> > I can get similar speed using gfortran 4.6. However, I have the
> > following two questions:
> > 1. How is it possible that DNAD run is even more efficient than
> > Analysis run?
> > 2. The significant speedup is enabled mainly by -fwhole-program.
> > However, it seems only applicable to a single file. If the real codes
> > have many separate files and even including some dlls, how can we
> > still achieve this? For example for my simple problem, if we put three
> > separate files dnad.f90 containing module dnad, cputime.f90 containing
> > module cputime, and test.f90 containg program test, how can the
> > compilation and linking be optimized?
>
> I see three questions instead of the two.  The
> answer to your question is to read the documentation supplied
> with the compiler.  See -lto -fprofile-generate -fprofile-use.- Hide quoted text -
>
> - Show quoted text -

When I try to use gfortran -flto, it tells me that LTO support has not
been enabled in this configuration.
gfortran -v gives me the following information
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=c:/program files/gfortran/bin/../libexec/gcc/i586-
pc-mingw32
/4.6.0/lto-wrapper.exe
Target: i586-pc-mingw32
Configured with: ../gcc-trunk/configure --prefix=/mingw --enable-
languages=c,for
tran --with-gmp=/home/brad/gfortran/dependencies --disable-werror --
enable-threa
ds --disable-nls --build=i586-pc-mingw32 --enable-libgomp --disable-
shared --dis
able-win32-registry --with-dwarf2 --disable-sjlj-exceptions :
(reconfigured) ../
gcc-trunk/configure --prefix=/mingw --enable-languages=c,fortran --
with-gmp=/hom
e/brad/gfortran/dependencies --disable-werror --enable-threads --
disable-nls --b
uild=i586-pc-mingw32 --enable-libgomp --disable-shared --disable-win32-
registry
--with-dwarf2 --disable-sjlj-exceptions
Thread model: win32
gcc version 4.6.0 20100524 (experimental) [trunk revision 159774]
(GCC)
From: Tobias Burnus on 7 Jun 2010 02:56
Hifi-Comp wrote:
> I can get similar speed using gfortran 4.6. However, I have the
> following two questions:
> 1. How is it possible that DNAD run is even more efficient than
> Analysis run?

No idea - I did not bother to look at the generated internal code
(-fdump-tree-all) nor at the assembler.

> 2. The significant speedup is enabled mainly by -fwhole-program.

I think -fwhole-file not -fwhole-program is the crucial option for your
example.

-fwhole-file: A Fortran-only option which causes the compiler to
remember all declarations in the whole file and not only in the scoping
unit. (This option will be the default at some point and is what the
middle-end of the compiler actually expects from all front ends. The
flag is not yet 100% working: it might lead in some few cases to an
internal compiler error or to linking errors; however, if a program
compiles and links, it should work.)

-fwhole-program: There are no other parts of the program, which call
subroutines/functions in the program, which allows to remove unused or
everywhere inlined procedures (and some other optimizations.

> However, it seems only applicable to a single file.

-fwhole-file can be always used. Regarding -fwhole-program: That's kind
of correct, except that with -flto/-fwhopr (LTO = link-time
optimization) one can also use it when with several files (also mixing,
e.g. C++ with Ada and Fortran).


> If the real codes
> have many separate files and even including some dlls, how can we
> still achieve this?

LTO you can also use with DLLs, though using -fwhole-program when
generating a DLL does not make much sense. (As one wants to call the
functions in a DLL from an out-side program ...). Note: LTO only applies
to statical linking - thus, it won't inline functions from a DLL (but
other than that, dynamic linking of course does not harm.)

(For completeness: LTO works since GCC 4.5.0, but on Windows and MacOS
systems only since a couple of weeks in the 4.6 developer version.)

* * *

See 4.5 release notes and the compiler documentations:

http://gcc.gnu.org/gcc-4.5/changes.html

http://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfwhole_002dfile_007d-224

http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto-813


Tobias
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: passing a type of different KIND to a C function from Fortran ?binding
Next: ALLOCATABLE array as MPI buffer