Re: [patch] IBM HDAPS accelerometer driver, with probing.
From: Alexey Dobriyan
Date: Sat Aug 27 2005 - 06:26:40 EST
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/