Re: Is ther any sense in *= and matrices?

[Ole-Hjalmar Kristensen <oleh@vlinux.voxelvision.no>]

18k11tm001@sneakemail.com (Russ) writes:

> "Bobby D. Bryant" <bdbryant@mail.utexas.edu> wrote in message news:<pan.2003.06.09.14.53.15.912223@mail.utexas.edu>...
> > On Sun, 08 Jun 2003 21:27:13 -0700, Russ wrote:
> > 
> > > "Bobby D. Bryant" <bdbryant@mail.utexas.edu> wrote in message
> > > news:<pan.2003.06.08.22.56.37.297066@mail.utexas.edu>...
> > >> On Sun, 08 Jun 2003 11:51:31 -0700, Russ wrote:
> > >> 
> > >> > "John R. Strohm" <strohm@airmail.net> wrote in message
> > >> > news:<bbumef$fnq@library2.airnews.net>...
> >  
> > >> >> With all due respect, ladies and gentlemen, it has been known for a
> > >> >> very long time that the difference in "efficiency" between A := A +
> > >> >> B and A += B is lost in the noise floor compared to the improvements
> > >> >> that can be gotten by improving the algorithms involved.
> > >> > 
> > >> > Oh, really? I just did a test in C++ with 3x3 matrices. I added them
> > >> > together 10,000,000 times using "+", then "+=". The "+=" version took
> > >> > about 19 seconds, and the "+" version took about 55 seconds. That's
> > >> > just shy of a factor of 3, folks. If that's your "noise floor," I
> > >> > can't help wonder what kind of "algorithms" you are dealing with!
> > >> 
> > >> I'm just curious why the compiler didn't generate the same code for
> > >> both versions.
> > > 
> > > The compiler didn't generate the code. I did.
> > 
> > No, I'm talking about the compiler's machine-code output.  You wrote in
> > C++, right?
> 
> Yes, I wrote it in C++. I would not have expected the compiler to
> generate the same code for both versions. I did not use any
> optimization flag, by the way, but even if I had, I still would not
> have expected the same executable. If you think it should, your beef
> is with the gcc folks.

You cannot do source level optimizations based on runs with the
optimizer turned off.  For example, you usually need some level of
optimization to turn inlining on, and without inlining, the peephole
optimizer cannot do as much.

When that is said, my run of tmoran's code shows a relatively large
performance penalty for the function version, which supports your argument.
It just shows that you cannot expect the same results on different systems.

oleh@VOLGA /cygdrive/c/div
$ g++ -O3 -funroll-loops -o moran-add moran-add.cpp

oleh@VOLGA /cygdrive/c/div
$ time ./moran-add
Go 1000 180 450
real    0m0.655s
user    0m0.660s
sys     0m0.010s

Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************