This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: search/search_n vs find/find_if


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]