I wrote a Fortran to C++ conversion program that I used to convert selected
LAPACK sources. Comparing runtimes with different compilers I get:
absolute relative
ifort 11.1.0721.790s1.00
gfortran 4.4.42.470s1.38
g++ 4.4.4 2.9
On Tue, Aug 10, 2010 at 6:51 PM, Ralf W. Grosse-Kunstleve
wrote:
> I wrote a Fortran to C++ conversion program that I used to convert selected
> LAPACK sources. Comparing runtimes with different compilers I get:
>
> absolute relative
> ifort 11.1.072 1.790s 1
lf W. Grosse-Kunstleve
Cc: gcc@gcc.gnu.org
Sent: Tue, August 10, 2010 8:47:18 PM
Subject: Re: food for optimizer developers
On Tue, Aug 10, 2010 at 6:51 PM, Ralf W. Grosse-Kunstleve
wrote:
> I wrote a Fortran to C++ conversion program that I used to convert selected
> LAPACK sources. Compa
On 8/10/2010 9:21 PM, Ralf W. Grosse-Kunstleve wrote:
Most of the time is spent in this function...
void
dlasr(
str_cref side,
str_cref pivot,
str_cref direct,
int const& m,
int const& n,
arr_cref c,
arr_cref s,
arr_ref a,
int const& lda)
in this loop:
Hi Tim,
> Do you mean you are adding an additional level of functions and hoping
> for efficient in-lining?
Note that my questions arise in the context of automatic code generation:
http://cci.lbl.gov/fable
Please compare e.g. the original LAPACK code with the generated C++ code
to see why th
On 08/11/2010 10:59 AM, Ralf W. Grosse-Kunstleve wrote:
> My original posting shows that gfortran and g++ don't do as good
> a job as ifort in generating efficient machine code. Note that the
> loss going from gfortran to g++ isn't as bad as going from ifort to
> gfortran. This gives me hope that t
On 08/10/2010 09:51 PM, Ralf W. Grosse-Kunstleve wrote:
I wrote a Fortran to C++ conversion program that I used to convert selected
LAPACK sources. Comparing runtimes with different compilers I get:
absolute relative
ifort 11.1.0721.790s1.00
gfortran 4
Hi Richard,
> How about using an automatic converter to arrange for C++ code to
> call into the generated Fortran code instead? Create nice classes
> and wrappers and such, but in the end arrange for the Fortran code
> to be called to do the real work.
I found it very labor intensive to maintain
Hi Vladimir,
Thanks for the feedback! Very interesting.
> Intel optimization compiler team (besides researchers) is much bigger than
>whole GCC community.
That's a surprise to me. I have to say that the GCC community has done amazing
work, as you came within factor 1.4 (gfortran) and 1.6 (g++
On Thu, Aug 12, 2010 at 8:46 AM, Ralf W. Grosse-Kunstleve
wrote:
> Hi Vladimir,
>
> Thanks for the feedback! Very interesting.
>
>
>> Intel optimization compiler team (besides researchers) is much bigger than
>>whole GCC community.
>
> That's a surprise to me. I have to say that the GCC community
On 11/08/2010 23:04, Vladimir Makarov wrote:
On 08/10/2010 09:51 PM, Ralf W. Grosse-Kunstleve wrote:
I wrote a Fortran to C++ conversion program that I used to convert
selected
LAPACK sources. Comparing runtimes with different compilers I get:
absolute relative
ifort 11.1.072 1.790s 1.00
gfortr
On Thu, Aug 12, 2010 at 09:51:42AM +0200, Steven Bosscher wrote:
> On Thu, Aug 12, 2010 at 8:46 AM, Ralf W. Grosse-Kunstleve
> wrote:
> > Hi Vladimir,
> >
> > Thanks for the feedback! Very interesting.
> >
> >
> >> Intel optimization compiler team (besides researchers) is much bigger than
> >>whol
Steve Kargl wrote:
# gfc4x 9.814 9.358 8.622 9.810 Note1 9.172 8.958 9.022
Column 5 compiled with -march=native -O2 -ffast-math
# Note 1: STOP DLAMC1 failure (10)
That's probably because a standard compile of the LAPACK sources only
compiles {S|D}LAM* with -O0.
The code is sim
On Thu, Aug 12, 2010 at 08:47:34PM +0200, Toon Moene wrote:
> Steve Kargl wrote:
>
> ># gfc4x 9.814 9.358 8.622 9.810 Note1 9.172 8.958 9.022
>
> Column 5 compiled with -march=native -O2 -ffast-math
>
> ># Note 1: STOP DLAMC1 failure (10)
>
> That's probably because a standard compile
Hi Steve,
> > Can you tell how you obtained the performance numbers you are using?
> > There may be a few compiler flags you could add to reduce that ratio
> > of 1.4 to something better.
> >
>
> Without knowing the compiler options, the results of any benchmark
> are meaningless.
I used
gfor
On Aug 12 2010, Steve Kargl wrote:
Your observation re-enforces the notion that doing
benchmarks properly is difficult. I forgot about
the lapack inquiry routines. One would think that
some 20+ year after F90, that Dongarra and colleagues
would use the intrinsic numeric inquiry functions.
Al
Ralf W. Grosse-Kunstleve wrote:
Without knowing the compiler options, the results of any benchmark
are meaningless.
I used
gfortran -o dsyev_test_gfortran -O3 -ffast-math dsyev_test.f
If you work on a 32bit x86 system, you really should use -march=native
and possibly -mfpmath=sse - otherw
On Sat, Aug 14, 2010 at 12:08:21AM +0200, Tobias Burnus wrote:
>
> In terms of options, I think -funroll-loops should also be used as it
> usually improves performance (it is not enabled by any -O... option).
>
I wonder if gfortran should check if -O and -O2 is given,
and then add -funroll-loop
18 matches
Mail list logo
