On Saturday 27 August 2005 13:35, Alexey Dobriyan wrote:
> See? The difference is 64 vs 451 bytes.
Disabling unlikely() doesn't make much difference because the compiler
generates the probability internally then and reorders anyways
(that is why many unlikelys are completely useless
because the
On Sad, 2005-08-27 at 02:29 -0300, Arnaldo Carvalho de Melo wrote:
> > unlikely() can result in better, smaller, faster code. and it acts as a
> > nice directive to programmers reading the code.
>
> Agreed, keep them :-)
If the unlikely() hints are being used correctly and the compiler is
doing
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
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
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
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
On Sad, 2005-08-27 at 02:29 -0300, Arnaldo Carvalho de Melo wrote:
unlikely() can result in better, smaller, faster code. and it acts as a
nice directive to programmers reading the code.
Agreed, keep them :-)
If the unlikely() hints are being used correctly and the compiler is
doing the
On Saturday 27 August 2005 13:35, Alexey Dobriyan wrote:
See? The difference is 64 vs 451 bytes.
Disabling unlikely() doesn't make much difference because the compiler
generates the probability internally then and reorders anyways
(that is why many unlikelys are completely useless
because the
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
Em Fri, Aug 26, 2005 at 07:37:59PM -0400, Robert Love escreveu:
> On Fri, 2005-08-26 at 17:44 -0500, Dmitry Torokhov wrote:
>
> > Is this function used in a hot path to warrant using "unlikely"? There
> > are to many "unlikely" in the code for my taste.
>
> unlikely() can result in better,
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
From: Andi Kleen <[EMAIL PROTECTED]>
Date: 27 Aug 2005 04:34:07 +0200
> "David S. Miller" <[EMAIL PROTECTED]> writes:
>
> > From: Alexey Dobriyan <[EMAIL PROTECTED]>
> > Date: Sat, 27 Aug 2005 02:58:48 +0400
> >
> > > What's the point of having unlikely() attached to every possible if ()?
> >
"David S. Miller" <[EMAIL PROTECTED]> writes:
> From: Alexey Dobriyan <[EMAIL PROTECTED]>
> Date: Sat, 27 Aug 2005 02:58:48 +0400
>
> > What's the point of having unlikely() attached to every possible if ()?
>
> If can result in smaller code, for one thing, even if it
> isn't a performance
On Fri, 2005-08-26 at 17:44 -0500, Dmitry Torokhov wrote:
> Is this function used in a hot path to warrant using "unlikely"? There
> are to many "unlikely" in the code for my taste.
unlikely() can result in better, smaller, faster code. and it acts as a
nice directive to programmers reading the
From: Alexey Dobriyan <[EMAIL PROTECTED]>
Date: Sat, 27 Aug 2005 02:58:48 +0400
> What's the point of having unlikely() attached to every possible if ()?
If can result in smaller code, for one thing, even if it
isn't a performance critical path.
-
To unsubscribe from this list: send the line
On Fri, Aug 26, 2005 at 06:18:45PM -0400, Robert Love wrote:
> Attached patch provides a driver for the IBM Hard Drive Active
> Protection System (hdaps) on top of 2.6.13-rc6-mm2.
> --- linux-2.6.13-rc6-mm2/drivers/hwmon/hdaps.c
> +++ linux/drivers/hwmon/hdaps.c
> +static int hdaps_probe(struct
On 8/26/05, Robert Love <[EMAIL PROTECTED]> wrote:
> +static void hdaps_calibrate(void)
> +{
> + int x, y, ret;
> +
> + ret = accelerometer_read_pair(HDAPS_PORT_XPOS, HDAPS_PORT_YPOS, ,
> );
> + if (unlikely(ret))
> + return;
> +
> + rest_x = x;
> +
Andrew,
Attached patch provides a driver for the IBM Hard Drive Active
Protection System (hdaps) on top of 2.6.13-rc6-mm2.
Over the previous post, it contains several fixes and improvements,
including a dev->probe() routine and a DMI whitelist.
Robert Love
Driver for the IBM HDAPS
Andrew,
Attached patch provides a driver for the IBM Hard Drive Active
Protection System (hdaps) on top of 2.6.13-rc6-mm2.
Over the previous post, it contains several fixes and improvements,
including a dev-probe() routine and a DMI whitelist.
Robert Love
Driver for the IBM HDAPS
On 8/26/05, Robert Love [EMAIL PROTECTED] wrote:
+static void hdaps_calibrate(void)
+{
+ int x, y, ret;
+
+ ret = accelerometer_read_pair(HDAPS_PORT_XPOS, HDAPS_PORT_YPOS, x,
y);
+ if (unlikely(ret))
+ return;
+
+ rest_x = x;
+ rest_y = y;
On Fri, Aug 26, 2005 at 06:18:45PM -0400, Robert Love wrote:
Attached patch provides a driver for the IBM Hard Drive Active
Protection System (hdaps) on top of 2.6.13-rc6-mm2.
--- linux-2.6.13-rc6-mm2/drivers/hwmon/hdaps.c
+++ linux/drivers/hwmon/hdaps.c
+static int hdaps_probe(struct
From: Alexey Dobriyan [EMAIL PROTECTED]
Date: Sat, 27 Aug 2005 02:58:48 +0400
What's the point of having unlikely() attached to every possible if ()?
If can result in smaller code, for one thing, even if it
isn't a performance critical path.
-
To unsubscribe from this list: send the line
On Fri, 2005-08-26 at 17:44 -0500, Dmitry Torokhov wrote:
Is this function used in a hot path to warrant using unlikely? There
are to many unlikely in the code for my taste.
unlikely() can result in better, smaller, faster code. and it acts as a
nice directive to programmers reading the code.
From: Andi Kleen [EMAIL PROTECTED]
Date: 27 Aug 2005 04:34:07 +0200
David S. Miller [EMAIL PROTECTED] writes:
From: Alexey Dobriyan [EMAIL PROTECTED]
Date: Sat, 27 Aug 2005 02:58:48 +0400
What's the point of having unlikely() attached to every possible if ()?
If can result in
David S. Miller [EMAIL PROTECTED] writes:
From: Alexey Dobriyan [EMAIL PROTECTED]
Date: Sat, 27 Aug 2005 02:58:48 +0400
What's the point of having unlikely() attached to every possible if ()?
If can result in smaller code, for one thing, even if it
isn't a performance critical path.
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
Em Fri, Aug 26, 2005 at 07:37:59PM -0400, Robert Love escreveu:
On Fri, 2005-08-26 at 17:44 -0500, Dmitry Torokhov wrote:
Is this function used in a hot path to warrant using unlikely? There
are to many unlikely in the code for my taste.
unlikely() can result in better, smaller, faster
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,
28 matches
Mail list logo
