Array optimizing problem in C++?

On Sun, 23 Mar 2008 15:40:44 +0000, Jon Harrop <usenet@jdh30.plus.com>
wrote:

>g++:   4.080  g++ -O3 bench.cpp -o bench; time ./bench
>g++2:  4.080  g++ -O3 bench2.cpp -o bench2; time ./bench2
>ocaml: 4.048  ocamlopt bench.ml -o bench; time ./bench
>java:  4.016  javac Arrays.java; time java Arrays

Make sure you are using server VM to run it ... that is,
java -server Arrays

Razii wrote: 
>
> 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.
> ...

I don't really see much sense in comparing Java performance with C++
performance. What might be more interesting is the effect of the 'restrict'
specifier supported by C99 compilers (and many C89/90 and C++ compielers as 
an
extension), which is intended to assist compiler in performing exactly this 
kind
of optimizations.

--
Best regards,
Andrey Tarasevich

In article <vl3cu35hllp13rd3bvdnta8ko2srnudtp2@4ax.com>,
DONTwhatevere3e@hotmail.com says...

[ ... ]

> 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.

Or maybe it did make a difference, and C++ would have won by a much
larger margin if it hadn't been for aliasing problems. If you're looking
at heavy-duty numeric programming (which is where this sort of problem
typically arises) the normal standard of comparison is Fortran.

--
Later,
Jerry.

The universe is a figment of its own imagination.

On Sun, 23 Mar 2008 16:50:29 -0600, Jerry Coffin <jcoffin@taeus.com>
wrote:

>Or maybe it did make a difference, and C++ would have won by a much
>larger margin if it hadn't been for aliasing problems.

No it's not. The compiler probably inlined the method, so there was no
aliasing problem here.

>If you're looking
>at heavy-duty numeric programming (which is where this sort of problem
>typically arises) the normal standard of comparison is Fortran.

If you read the post carefully, you would have noticed that Kanze was
discussing java and c++.  Why would I use Fortran?

jason.cipriani@gmail.com wrote:
> On Mar 23, 11:40 am, Jon Harrop <use...@jdh30.plus.com> wrote: 
>
> Only sometimes; and it's a valid optimization.

No, that is completely wrong. Valid optimizations must not break correct
code as -ffast-math does. This is why -ffast-math is not enabled by any -On
setting. Read the documentation.

> Specifically, in this case, the results are identical.

They may appear identical on your machine with your compiler but that is
certainly not true in general. In particular, the -ffast-math option breaks
this program on my computer, giving incorrect results.

> Mostly, in my experience, you start
> to lose precision with -ffast-math when you start doing things beyond
> simple arithmetic, such as sqrt() and cos(), or when you get into the
> realm of overflows and NaNs.
>
> In case anybody is curious the Intel compiler yields similar results
> to VS, and to GCC with SSE3 enabled (but no -ffast-math), which is the
> expected results:
>
> icl /Ox /QxP /Qipo /Qunroll-aggressive smooth.cpp
>
> Was about 7400 ms for me. With:
>
> icl /Ox /QxP /Qipo /Qprec-div- /Qunroll-aggressive smooth.cpp
>
> Dropping it down to 1100 ms (ICC's /Qprec-div- is similar in spirit to
> GCC's -ffast-math).
>
> Following are 3 source files and a Makefile, I used MinGW GCC 3.4.5;
> you will want to implement your own tick()/tock() functions; the
> windows.h #include is only for those. The output, for me, is:
>
> $ ./smooth.exe
> no -ffast-math: 8796.27
> -ffast-math: 923.052
> 1e-014
> delta: 0
> they are precisely equal.

Compiling with -ffast-math gives 25% incorrect results on this machine (AMD
Athlon(tm) 64 X2 Dual Core Processor 4400+, g++ 4.2.3):

$ g++ -O3 test1.cpp -o test1
$ ./test1 >output.txt
$ g++ -O3 -ffast-math test1.cpp -o test1
$ ./test1 >output2.txt
$ diff output.txt output2.txt | wc
21242   42480  615958

Note: I replaced "rand()" in "fill" with "i" to make the program
deterministic.

Here are some of the differing results (correct results first):

49361.00000000000000000000
49362.00000000000000000000
49363.00000000000000000000
49364.00000000000000000000
49365.00000000000000000000

49360.99999999998544808477
49361.99999999997817212716
49362.99999999995634425431
49363.99999999992724042386
49364.99999999989813659340

As you can see, enabling -ffast-math really does break this program. As I
said, this is not a valid optimization.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u

Razii wrote:
> On Sun, 23 Mar 2008 16:50:29 -0600, Jerry Coffin <jcoffin@taeus.com>
> wrote: 
>
> No it's not. The compiler probably inlined the method, so there was no
> aliasing problem here.

This benchmark appears to run several times faster with -ffast-math on
several machines. Until we find out why, I don't believe there is any point
in speculating about the relative importance of aliasing in this context.
 
>
> If you read the post carefully, you would have noticed that Kanze was
> discussing java and c++.  Why would I use Fortran?

Using Fortran instead of Java would remove a lot of irrelevant
complications, like JIT, HotSpot, slow startup times, ugly programmers etc.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u

On Sun, 23 Mar 2008 15:40:44 +0000, Jon Harrop <usenet@jdh30.plus.com>
wrote:

>  let src = Array.init n (fun _ -> Random.float 1.) in

Is there a difference between float and double in OCaml? If yes,
wouldn't it make difference here?

On Sun, 23 Mar 2008 13:41:36 -0700 (PDT), courpron@gmail.com wrote:

>On Mar 23, 6:54_pm, Razii <DONTwhatever...@hotmail.com> wrote: 
>
>The smooth function must not be inlined.


#define NO_ALIASING_OPTIMIZATION

const int len = 50000;

__declspec(noinline)
#ifndef NO_ALIASING_OPTIMIZATION
void smooth (int*   dest,  int *  src )
#else
void smooth (int*  __restrict dest,  int * __restrict src )
#endif
{
for ( int i = 0 ; i < len - 2 ; i++ )
dest[ i ] = src[ i ] + src[ i + 1 ] + src[ i + 2 ];
}


With  #define NO_ALIASING_OPTIMIZATION

Time smooth(): 687 ms

Without #define NO_ALIASING_OPTIMIZATION

Time smooth(): 812 ms

Both are faster than Java anyway (especially for int version, with
double the difference was smaller).

On Sun, 23 Mar 2008 22:49:17 -0500, Razii
<DONTwhatevere3e@hotmail.com> wrote:

>Both are faster than Java anyway (especially for int version, with
>double the difference was smaller).

Oh, you also changed the loop inside smooth function

mine was
for (int i = 1 ; i < len - 1 ; i++ ) {
dest[ i - 1 ] = (src[ i - 1 ] + src[ i ] + src[ i + 1 ]) / 3 ;

you changed that to

for ( int i = 0 ; i < len - 2 ; i++ )
dest[ i ] = src[ i ] + src[ i + 1 ] + src[ i + 2 ];

(you also removed division by 3)

I was wondering why the difference increased...

On Sun, 23 Mar 2008 09:10:59 -0700 (PDT), courpron@gmail.com wrote:

>The
>"restrict" keyword should be added in the next C++ standard

The problem is C++ is already suffering from bloating problem.