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: Optimising std::find on x86 and PPC


Chris Jefferson <caj@cs.york.ac.uk> writes:

| Paolo Carlini wrote:
| 
| > Paolo Carlini wrote:
| >
| >> Besided what Gaby and Benjamin already replied, out of curiosity,
| >> what the loop
| >> unroller is doing, right now?!? Nothing!?!
| >
| >
| > More explicitly, and in the "right" spirit for the library: let's
| > suppose we remove completely any ad-hoc loop-unrolling by hand, can
| > we trust the loop-unroller to do a decent work both on x86-linux and
| > darwin-powerpc? This is something worth
| > investigating, IMHO... and in case the loop unroller does crazy
| > things file immediately a PR.
| >
| Only one minor point on this.. in 4.0, we really either need our
| unrolled code, or a better loop optimiser unless we want to take a 40%
| speed hit on std::find... so if we remove it and they can't get the
| loop optimiser fixed, either the current version or (I'd perfer, but
| won't force) the new version I originally posted should go back in.

You've found an issue with the compiler middle-end; that is where it
should be fixed.  I bet the amount of user codes with simple for-loops
(as found in std::find) is far larger than the use of std::find.  So
the proper fix is to to the compiler so that we actually get a real
benefit instead of crippling the library with n versions of different
sort of hacks.  Cure the disease, not the symptoms.

-- Gaby


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