On Sat, Aug 27, 2005 at 01:12:50AM -0500, Dmitry Torokhov wrote: > On Saturday 27 August 2005 00:34, Arnaldo Carvalho de Melo wrote: > > Em Fri, Aug 26, 2005 at 09:06:22PM -0700, Mitchell Blank Jr escreveu: > > > Andi Kleen wrote: > > > > - it doesn't seem to help that much on modern CPUs with good > > > > branch prediction and big icaches anyways. > > > > > > Really? I would think that as pipelines get deeper (although that trend > > > seems to have stopped, thankfully) and Icache-miss penalties get > > > relatively > > > larger we'd see unlikely() becoming MORE of a benefit, not less. Storing > > > the used part of a "hot" function in 1 Icacheline instead of 4 seems like > > > an obvious win. > > > > > > Personally I've never found unlikely() to be ugly; if anything I think > > > it serves as a nice little human-readable comment about whats going on > > > in the control-flow. I guess I'm in the minority on that one, though. > > > > Hey, even if unlikely was: > > > > #define unlikely(x) (x) > > > > I'd find it useful :-) > > > > Aside from annotating performance-critical sections what other purpose > would it carry? It's not like you should not pay attention to teh code > in these branches even if the are unlikely to be taken. So if code is > not in hot path likely/unlikely just litter the code. > > Btw, does it actually generate smaller code for constructs like > > if (unlikely(blah)) > goto out;
Well, with my usual .config (-O2) and gcc-3.3.5-something it does: text data bss dec hex filename 3614 303 1696 5613 15ed drivers/hwmon/hdaps.o 3678 303 1696 5677 162d drivers/hwmon/hdaps.o (unlikely()s removed) Fortunately, there is -Os: text data bss dec hex filename 3163 303 1696 5162 142a drivers/hwmon/hdaps.o 3163 303 1696 5162 142a drivers/hwmon/hdaps.o (unlikely()s removed) See? The difference is 64 vs 451 bytes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
