Re: [Boost-users] Boost.MultiIndex question on merge

Subject: Re: [Boost-users] Boost.MultiIndex question on merge
From: tom fogal (tfogal_at_[hidden])
Date: 2009-04-30 01:12:52

Ovanes Markarian <om_boost_at_[hidden]> writes:
> On Tue, Apr 28, 2009 at 5:05 PM, arm2arm <arm2arm_at_[hidden]> wrote:
> > To: Ovanes
> > Are there gain in the speed if  I would use the for_each?
> > I am always avoiding to use for_each  to allow the compiler (like INTEL)
> > auto-parallelize the regions.
> > But for this particular case Is not a issue.
> >
> to be honest, that's strange. I know from MSVC that using std::algorithms
> allows parallelisation.

I find this very strange.  Gcc accepted some parallelized STL
implementation too in recent years, and I always questioned it.  For
example, 25.1.1/1 in c++98 (for_each def'n):

  Effects: Applies f to the result of dereferencing every iterator in
           the range [first, last), starting from first and proceeding
           to last - 1.

How could you possibly parallelize that?  It's defined to operate in
series.  I guess if the compiler could prove that `f' had no side
effects, and there were no volatiles involved, it might be possible (is
that strong enough to prove that that execution order is irrelevant?
hrm..)  It seems like the former would run up against solving the
aliasing problem, though.  What am I missing here?

(Granted, I can't recall the last time I wrote a for_each that *relied*
on that execution order.  Further, I could probably be convinced that
requiring a particular ordering here was a specification mistake.
Still, a standard is a standard.)

-tom