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

Ovanes Markarian writes:

On Tue, Apr 28, 2009 at 5:05 PM, arm2arm 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