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
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++
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 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
ssize_t i2) const
{
return
(i2 - origin[1]) * all[0]
+ (i1 - origin[0]);
}
The array pointer is buried as elems_ member in the arr_ref<> class template.
How can I apply __restrict in this case?
Ralf
- Original Message
From: Andrew Pinski
To: Ra
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
Andrew Pinski wrote:
> Yes it is intentional. It is an extension of an already existing
> error with non templates. The code is invalid, though the C++
> standard does make a mention, this does not have to be diagnostic.
Thanks for the quick reply! This is great, I like the change since it
enfor
I'm testing our C++ code with
g++ (GCC) 4.3.0 20070919 (experimental)
That's SVN revision 128608, gcc_trunk.
I'm getting many errors like this:
% g++ -c changes_meaning.cpp
changes_meaning.cpp:8: error: declaration of 'typedef struct ns::foo
ns::bar::foo'
changes_meaning.cpp:4: error: changes mea
Under Linux, gcc/g++-compiled code happily continues running after
producing NAN and INF. Often it is time-consuming to backtrack to the
actual source of the numerical problems. In addition, such problems may
go undetected for some time, which can cause all kinds of confusion.
Other
platforms sto
