search/search_n vs find/find_if

[Paolo Carlini]

Chris Jefferson wrote:

> I had been thinking about this, in particular I'd thought about 
> delegating find to find_if, and in general mapping between those 
> functions which accept a parameter and those which accept a function 
> predicate by something like (note: not actual C++ code!)
>
> template<typename T>
> struct __equalobject
> {
>   T& __obj;
>   __equalobject(T& __inobj) : __obj(__inobj)
>   {}
>   bool operator()(T& __inobj)
>   { return __obj == __inobj; }
> };
>
> As I imagine that such a class should be optimised away. There are a 
> few pairs like find/find_if with this kind of behaviour. While -O2 on 
> x86 optimises down to what you would expect, I didn't have time to 
> check others. Also as find is so small I wasn't sure it was worth the 
> effort of delegating it to find_if.

Ah, yes, now I remember that you posted (pseudo)code like the above! 
Indeed, if we are reasonably sure that -O2 is able to deal well with 
this case too, why not? Seems another nice clean-up, akin to the 
previous one. Please further explore it, and also the special case of 
search/search_n, which we are slighlty de-optimizing, right now, this is 
bad... Then, we can actually envisage plugging-in a new search_n for 
random access iterators ;)

> On the unrolling issue, both linux-x86 and darwin, the automatic 
> unrolling gets within about 10% to 15% of the unrolled code. However 
> for at least 4.0 I would be tempted to leave the manual unrolling, as 
> removing it just to decrease speed by 10% seems a little pointless :)

Definitely, I was just curious...

Paolo.