| user923005 2007-03-28, 4:18 am |
| On Mar 27, 10:49 pm, "highegg" <high...@gmail.com> wrote:
>
> Perhaps. I see you specified a whole bunch of options for the MSVSC++
> compiler (out of those I only recall that the /G are for code
> generation, /O are presumably optimizers), while you just specify -O3
> for g95. Additional options for g95 (as well as other compilers) may
> include -ffast-math (equivalent to /fp:fast for VC++ ?), -fomit-frame-
> pointer, -march=athlon (or something similar), -funroll-loops.
> g95 has almost all optimizations turned off by default.
> Even if you do so, do not expect miracles. Two things need to be
> noted:
I have an AMD machine, so I did like you suggest:
dcorbit@DCORBIT64 /f/tmp
$ g95 -O3 -Wall -ffast-math -fomit-frame-pointer -march=athlon -
funroll-loops
test_fpu.f90
In file test_fpu.f90:83
91 FORMAT (A,I4,2('/',I2.2))
1
Warning (110): Label 91 at (1) defined but not used
In file test_fpu.f90:2293
INTEGER :: i , info , j , l , ncola , nrowa , nrowb
1
Warning (112): Variable 'ncola' at (1) is set but never used
test_fpu.f90: In function 'dtrmv_':
test_fpu.f90:3611: warning: 'kx' may be used uninitialized in this
function
dcorbit@DCORBIT64 /f/tmp
$ ./a
Benchmark running, hopefully as only ACTIVE task
Test1 - Gauss 2000 (101x101) inverts 12.7 sec Err= 0.000000000000003
Test2 - Crout 2000 (101x101) inverts 7.0 sec Err= 0.000000000000001
Test3 - Crout 2 (1001x1001) inverts 11.6 sec Err= 0.000000000000002
Test4 - Lapack 2 (1001x1001) inverts 8.0 sec Err= 0.000000000000643
total = 39.3 sec
> the Fortran code may not be written with speed in mind. Note that
> array arithmetic has to create a temporary array if necessary. It is
> up to the compiler to determine whether or not it is necessary.
> Especially tough might be tricks like this (snipped from TEST_FPU.f90)
> b((/m,k/),:) = b((/k,m/),:)
>
> although the swapping here can be done with one temp variable, this is
> probably going to create a 2xsize(b,2) temporary array, copy the
> righthand side to it, the copy it to the lefthand side. A more speed-
> friendly coding could look like this:
>
> elemental subroutine swap(a,b)
> real,intent(inout)::a,b
> real:: tmp
> tmp = a; a = b; b = tmp
> end subroutine
> ...
> call swap(b(m,:),b(k,:))
>
> or the good old DO loop.
>
> Moreover, it is important to note that g95 isn't the top optimizing
> compiler out there; to be honest, it may well be the bottom. It was
> not created with aggresive optimizations in mind - and especially
> optimizing of complicated array expressions is a tough task. I think
> that gfortran (the newer versions) can perform better, but I would
> consider more fair a comparison with a commercial Windows compiler,
> like Intel Visual Fortran. Don't have that one.
gfortran barfed:
dcorbit@DCORBIT64 /f/tmp
$ gfortran -O3 -Wall test_fpu.f90
In file test_fpu.f90:83
91 FORMAT (A,I4,2('/',I2.2))
1
Warning: Label 91 at (1) defined but not used
test_fpu.f90: In function 'gauss':
test_fpu.f90:106: internal compiler error: in gfc_conv_ss_descriptor,
at fortran/trans-array.c:1235
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
dcorbit@DCORBIT64 /f/tmp
$ gfortran --version
GNU Fortran 95 (GCC 4.0.1 20050608 (prerelease))
Copyright (C) 2005 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
dcorbit@DCORBIT64 /f/tmp
> Still, it is hard to tell whether a C code is equivalent to some
> Fortran code. I did not closely review your C code to see how close it
> gets.
>
> regards,
> Jaroslav (not remotely a Fortran guru)
|