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: Implementing normal algorithms using predicate versions


chris wrote:

While we are discussing optimisations,

Yes, I think we should always keep in mind, that, due to *structural* limitations of the current optimizers, which definitely will not be fixed in the short term, it's not uncommon that one O(n^2) (or even O(n^3) :( algorithm (either in time or memory) "explodes". The net effect is that power users around the world, in particular those using automatically generated / heavily template based code often cannot use -O2. Also, more commonly, test/debud builds in my personal experience had better maintaining a decent (I'm saying *decent*) performance.


I wonder if a liberal spreading of "inline" might not be useful?

Please correct me if I'm getting the english meaning wrong (I'm Italian, to be clear), but I would advice against using the word "liberal" if you are not 100% sure that Gawain Bolton is currently off-line in a tiny desert island of the Pacific, or something similar ;) ;)


I'm not so much thinking about inlining small functions just because they are small, I trust g++ to decide when to do that itself. I was more thinking that when we have "dispatching" functions for specialisations (such as these), we should either inline the dispatching function, or the functions which are dispatched to perhaps?

Personally, while it is the less obvious choice, I would probably inline the dispatching functions, as they should after inlining in theory compile away to nothing at all.

Seriously, I think we are already doing that, basically, in various existing algorithms?!? For instance in find.


Paolo.


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