Re: Array optimizing problem in C++?
On Mar 23, 4:08 am, Razii <DONTwhatever...@hotmail.com> wrote:
From an old post by James Kanze
On Apr 9 2003, 5:42 pm, ka...@gabi-soft.de (James Kanze) wrote:
When I pass an "array" to a function in C/C++, I actually pass
a pointer to the first element. And the compiler, when it compiles the
function, only sees pointers -- it has no way of determining any
relationship between them. Consider, for example, a smoothing function
(in C or earlier C++):
void
smooth( double* dest,
double const* src,
size_t len )
{
for ( size_t i = 1 ; i < len - 1 ; ++ i ) {
dest[ i - 1 ] = (src[ i - 1 ] + src[ i ] + src[ i + 1 ]) / 3 ;
}
}
The compiler cannot arrange to use the src[ i + 1 ] value from the
preceding pass through the loop as the src[ i ] value in the current
pass, since the write to dest[ i - 1 ] might have changed it. In Java,
it can, since two arrays are either identical or disjoint.
This sort of code shows up frequently. In benchmarks from Java
suppliers comparing Java to C++, of course:-). But also in any number
of applications dealing with physical measures: meteorology, geophysical
research (oil prospection), etc.
Out of curiosity, I tried to test if the above is true. It didn't make
any difference. In fact, C++ was a bit faster (not by much, just 6%).
Probably due to array bound check in Java, if there is in indeed an
issue with C++ arrays, overall there is no difference.
If you are going for blinding speed be sure to use proper optimization
flags; otherwise you are only calculating benchmarks for poorly
optimized code, which, like most of your benchmarks, is meaningless:
$ g++ -O0 smooth.cpp
9884.867 ms
$ g++ -O3 smooth.cpp
8791.123 ms
$ g++ -O3 -mfpmath=sse -msse3 -march=prescott -ffast-math smooth.cpp
1207.944 ms
$ g++ -O3 -mfpmath=sse -msse3 -march=prescott -ffast-math -funroll-
loops smooth.cpp
1084.385 ms
This is your code slightly modified to use QueryPerformanceCounter for
timing (using Windows). Most of the speed up is a result of -ffast-
math.
Based on the quality and rigor of the other tests I've seen you do,
I'd guess that you missed a few optimization flags on the Java side as
well.
Jason