This is the mail archive of the libstdc++@sourceware.cygnus.com mailing list for the libstdc++ project. See the libstdc++ home page for more information.


[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]

Re: valarrays broken



Gabriel Dos Reis wrote:

> Actually that was an oversight. I'll send you a patch as soon as I'm
> back (I'm currently out for one week).
>

Fine. I was afraid a major redesign is necessary to fix this without 
performance loss. 

> In fact the bug does not show up (in most cases) with optimization
> option -Ox (x>1) turned on. You can trigger it with -O0.
> 

Yes, -O3 seems to be save.
That has enabled me to do some performance tests. 
I have taken the operation a = b + 3.0 * c as test 
with a, b and c being arrays.

This is the speed in MFLOPS:

Size        1  valarray:    4.37  C-code:    7.36
Size        2  valarray:    7.56  C-code:   11.49
Size        4  valarray:   10.36  C-code:   14.46
Size        8  valarray:   13.98  C-code:   17.85
Size       16  valarray:   15.53  C-code:   19.97
Size       32  valarray:   17.12  C-code:   21.51
Size       64  valarray:   18.24  C-code:   22.08
Size      128  valarray:   18.24  C-code:   20.46
Size      256  valarray:   18.64  C-code:   20.46
Size      512  valarray:   18.64  C-code:   20.97
Size     1024  valarray:   18.64  C-code:   18.64
Size     2048  valarray:    4.69  C-code:    4.71
Size     4096  valarray:    4.69  C-code:    4.71
Size     8192  valarray:    4.42  C-code:    4.56
Size    16384  valarray:    8.39  C-code:    9.75
Size    32768  valarray:    7.29  C-code:    8.31
Size    65536  valarray:    6.55  C-code:    7.11            

Really good work!

> 
> I don't know how long it took to Nathan to uglify the complete code.
> 
> I'm afraid I don't clearly understand your point. My initial version
> was not uglified. But I strongly agree with the uglification policy as
> it enables one to use snapshots of the library in user applications
> (for testing purposes).

What kind of user application could break if you write

  template<typename Tp>
  inline valarray<Tp>
  valarray<Tp>::operator[] (const valarray<bool>& m) const
  {
      size_t s (0);
      for (size_t i=0; i<m.size(); ++i)
          if (m[i]) ++s;
      return valarray<Tp> (mask_array<Tp> (_Array<Tp>(M_data), s,
                                         _Array<bool> (m)));
  }


instead of 

  template<typename _Tp>
  inline valarray<_Tp>
  valarray<_Tp>::operator[] (const valarray<bool>& __m) const
  {
      size_t __s (0);
      for (size_t __i=0; __i<__m.size(); ++__i)
          if (__m[__i]) ++__s;
      return valarray<_Tp> (mask_array<_Tp> (_Array<_Tp>(_M_data), __s,
                                         _Array<bool> (__m)));
  }

?

IMO, it is rather unlikely that someone has code like `#define i he he'.

Regards,
Thomas Kunert