On Tue, Feb 19, 2008 at 10:28:46AM +0100, Andi Kleen wrote:
> > Sometimes, for performance critical paths, I would like gcc to be dumb and
> > follow *my* code and not its hard-coded probabilities.
>
> If you really want that, simple: just disable optimization @)
already tried. It fixed some
On Tuesday 19 February 2008 20:57, Andi Kleen wrote:
> On Tue, Feb 19, 2008 at 08:46:46PM +1100, Nick Piggin wrote:
> > I think it was just a simple context switch benchmark, but not lmbench
> > (which I found to be a bit too variable). But it was a long time ago...
>
> Do you still have it?
>
>
On Tue, Feb 19, 2008 at 08:46:46PM +1100, Nick Piggin wrote:
> On Tuesday 19 February 2008 20:25, Andi Kleen wrote:
> > On Tue, Feb 19, 2008 at 01:33:53PM +1100, Nick Piggin wrote:
>
> > > I actually once measured context switching performance in the scheduler,
> > > and removing the unlikely
On Tuesday 19 February 2008 20:25, Andi Kleen wrote:
> On Tue, Feb 19, 2008 at 01:33:53PM +1100, Nick Piggin wrote:
> > I actually once measured context switching performance in the scheduler,
> > and removing the unlikely hint for testing RT tasks IIRC gave about 5%
> > performance drop.
>
>
> Sometimes, for performance critical paths, I would like gcc to be dumb and
> follow *my* code and not its hard-coded probabilities.
If you really want that, simple: just disable optimization @)
> Maybe one thing we would need would be the ability to assign probabilities
> to each branch based
On Tue, Feb 19, 2008 at 01:33:53PM +1100, Nick Piggin wrote:
> On Tuesday 19 February 2008 01:39, Andi Kleen wrote:
> > Arjan van de Ven <[EMAIL PROTECTED]> writes:
> > > you have more faith in the authors knowledge of how his code actually
> > > behaves than I think is warranted :)
> >
> > iirc
Sometimes, for performance critical paths, I would like gcc to be dumb and
follow *my* code and not its hard-coded probabilities.
If you really want that, simple: just disable optimization @)
Maybe one thing we would need would be the ability to assign probabilities
to each branch based on
On Tuesday 19 February 2008 20:25, Andi Kleen wrote:
On Tue, Feb 19, 2008 at 01:33:53PM +1100, Nick Piggin wrote:
I actually once measured context switching performance in the scheduler,
and removing the unlikely hint for testing RT tasks IIRC gave about 5%
performance drop.
OT: what
On Tue, Feb 19, 2008 at 01:33:53PM +1100, Nick Piggin wrote:
On Tuesday 19 February 2008 01:39, Andi Kleen wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
you have more faith in the authors knowledge of how his code actually
behaves than I think is warranted :)
iirc there was a mm
On Tue, Feb 19, 2008 at 08:46:46PM +1100, Nick Piggin wrote:
On Tuesday 19 February 2008 20:25, Andi Kleen wrote:
On Tue, Feb 19, 2008 at 01:33:53PM +1100, Nick Piggin wrote:
I actually once measured context switching performance in the scheduler,
and removing the unlikely hint for
On Tuesday 19 February 2008 20:57, Andi Kleen wrote:
On Tue, Feb 19, 2008 at 08:46:46PM +1100, Nick Piggin wrote:
I think it was just a simple context switch benchmark, but not lmbench
(which I found to be a bit too variable). But it was a long time ago...
Do you still have it?
I thought
On Tue, Feb 19, 2008 at 10:28:46AM +0100, Andi Kleen wrote:
Sometimes, for performance critical paths, I would like gcc to be dumb and
follow *my* code and not its hard-coded probabilities.
If you really want that, simple: just disable optimization @)
already tried. It fixed some
On Tue, Feb 19, 2008 at 08:46:03AM +1100, Michael Ellerman wrote:
> On Mon, 2008-02-18 at 16:13 +0200, Adrian Bunk wrote:
> > On Mon, Feb 18, 2008 at 03:01:35PM +0100, Geert Uytterhoeven wrote:
> > > On Mon, 18 Feb 2008, Adrian Bunk wrote:
> > > >
> > > > This means it generates faster code with
On Tuesday 19 February 2008 16:58, Willy Tarreau wrote:
> On Tue, Feb 19, 2008 at 01:33:53PM +1100, Nick Piggin wrote:
> > > Note in particular the last predictors; assuming branch ending
> > > with goto, including call, causing early function return or
> > > returning negative constant are not
On Tue, Feb 19, 2008 at 01:33:53PM +1100, Nick Piggin wrote:
> > Note in particular the last predictors; assuming branch ending
> > with goto, including call, causing early function return or
> > returning negative constant are not taken. Just these alone
> > are likely 95+% of the unlikelies in
On Tuesday 19 February 2008 13:40, Arjan van de Ven wrote:
> On Tue, 19 Feb 2008 13:33:53 +1100
>
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Actually one thing I don't like about gcc is that I think it still
> > emits cmovs for likely/unlikely branches, which is silly (the gcc
> > developers
On Tue, 19 Feb 2008 13:33:53 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> Actually one thing I don't like about gcc is that I think it still
> emits cmovs for likely/unlikely branches, which is silly (the gcc
> developers seem to be in love with that instruction). If that goes
> away, then
On Tuesday 19 February 2008 01:39, Andi Kleen wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
> > you have more faith in the authors knowledge of how his code actually
> > behaves than I think is warranted :)
>
> iirc there was a mm patch some time ago to keep track of the actual
> unlikely
On Mon, 2008-02-18 at 16:13 +0200, Adrian Bunk wrote:
> On Mon, Feb 18, 2008 at 03:01:35PM +0100, Geert Uytterhoeven wrote:
> > On Mon, 18 Feb 2008, Adrian Bunk wrote:
> > >
> > > This means it generates faster code with a current gcc for your platform.
> > >
> > > But a future gcc might e.g.
On Feb 18, 2008 6:01 AM, Geert Uytterhoeven
<[EMAIL PROTECTED]> wrote:
> > This means it generates faster code with a current gcc for your platform.
> >
> > But a future gcc might e.g. replace the whole loop with a division
> > (gcc SVN head (that will soon become gcc 4.3) already does
> >
On Mon, 18 Feb 2008 13:11:06 -0500
[EMAIL PROTECTED] wrote:
> On Mon, 18 Feb 2008 14:27:10 GMT, David Howells said:
>
> > __builtin_expect() is useful on FRV where you _have_ to give each
> > branch and conditional branch instruction a measure of probability
> > whether the branch will be taken.
On Mon, 18 Feb 2008 14:27:10 GMT, David Howells said:
> __builtin_expect() is useful on FRV where you _have_ to give each branch and
> conditional branch instruction a measure of probability whether the branch
> will be taken.
What does gcc do the 99.998% of the time we don't have
David Howells wrote:
> Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
>
>> Hence shouldn't we ask the gcc people what's the purpose of
>> __builtin_expect(), if it doesn't live up to its promise?
>
> __builtin_expect() is useful on FRV where you _have_ to give each branch and
> conditional branch
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> you have more faith in the authors knowledge of how his code actually behaves
> than I think is warranted :)
iirc there was a mm patch some time ago to keep track of the actual unlikely
values at runtime and it showed indeed some wrong ones. But
Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> Hence shouldn't we ask the gcc people what's the purpose of
> __builtin_expect(), if it doesn't live up to its promise?
__builtin_expect() is useful on FRV where you _have_ to give each branch and
conditional branch instruction a measure of
On Mon, Feb 18, 2008 at 03:01:35PM +0100, Geert Uytterhoeven wrote:
> On Mon, 18 Feb 2008, Adrian Bunk wrote:
> >
> > This means it generates faster code with a current gcc for your platform.
> >
> > But a future gcc might e.g. replace the whole loop with a division
> > (gcc SVN head (that will
On Mon, 18 Feb 2008, Adrian Bunk wrote:
> On Sun, Feb 17, 2008 at 10:50:03PM +1100, Michael Ellerman wrote:
> > On Sat, 2008-02-16 at 10:39 -0800, Arjan van de Ven wrote:
> >...
> > > for mordern (last 10 years) x86 cpus... the cpu branchpredictor is better
> > > than the coder in general. Same
On Sun, Feb 17, 2008 at 10:50:03PM +1100, Michael Ellerman wrote:
> On Sat, 2008-02-16 at 10:39 -0800, Arjan van de Ven wrote:
>...
> > for mordern (last 10 years) x86 cpus... the cpu branchpredictor is better
> > than the coder in general. Same for most other architectures.
> >
> > unlikely()
On Sun, Feb 17, 2008 at 10:50:03PM +1100, Michael Ellerman wrote:
On Sat, 2008-02-16 at 10:39 -0800, Arjan van de Ven wrote:
...
for mordern (last 10 years) x86 cpus... the cpu branchpredictor is better
than the coder in general. Same for most other architectures.
unlikely() creates
On Mon, 18 Feb 2008, Adrian Bunk wrote:
On Sun, Feb 17, 2008 at 10:50:03PM +1100, Michael Ellerman wrote:
On Sat, 2008-02-16 at 10:39 -0800, Arjan van de Ven wrote:
...
for mordern (last 10 years) x86 cpus... the cpu branchpredictor is better
than the coder in general. Same for most
On Mon, Feb 18, 2008 at 03:01:35PM +0100, Geert Uytterhoeven wrote:
On Mon, 18 Feb 2008, Adrian Bunk wrote:
This means it generates faster code with a current gcc for your platform.
But a future gcc might e.g. replace the whole loop with a division
(gcc SVN head (that will soon become
Geert Uytterhoeven [EMAIL PROTECTED] wrote:
Hence shouldn't we ask the gcc people what's the purpose of
__builtin_expect(), if it doesn't live up to its promise?
__builtin_expect() is useful on FRV where you _have_ to give each branch and
conditional branch instruction a measure of probability
Arjan van de Ven [EMAIL PROTECTED] writes:
you have more faith in the authors knowledge of how his code actually behaves
than I think is warranted :)
iirc there was a mm patch some time ago to keep track of the actual unlikely
values at runtime and it showed indeed some wrong ones. But the
David Howells wrote:
Geert Uytterhoeven [EMAIL PROTECTED] wrote:
Hence shouldn't we ask the gcc people what's the purpose of
__builtin_expect(), if it doesn't live up to its promise?
__builtin_expect() is useful on FRV where you _have_ to give each branch and
conditional branch
On Mon, 18 Feb 2008 14:27:10 GMT, David Howells said:
__builtin_expect() is useful on FRV where you _have_ to give each branch and
conditional branch instruction a measure of probability whether the branch
will be taken.
What does gcc do the 99.998% of the time we don't have likely/unlikely
On Mon, 18 Feb 2008 13:11:06 -0500
[EMAIL PROTECTED] wrote:
On Mon, 18 Feb 2008 14:27:10 GMT, David Howells said:
__builtin_expect() is useful on FRV where you _have_ to give each
branch and conditional branch instruction a measure of probability
whether the branch will be taken.
What
On Feb 18, 2008 6:01 AM, Geert Uytterhoeven
[EMAIL PROTECTED] wrote:
This means it generates faster code with a current gcc for your platform.
But a future gcc might e.g. replace the whole loop with a division
(gcc SVN head (that will soon become gcc 4.3) already does
transformations
On Mon, 2008-02-18 at 16:13 +0200, Adrian Bunk wrote:
On Mon, Feb 18, 2008 at 03:01:35PM +0100, Geert Uytterhoeven wrote:
On Mon, 18 Feb 2008, Adrian Bunk wrote:
This means it generates faster code with a current gcc for your platform.
But a future gcc might e.g. replace the whole
On Tuesday 19 February 2008 01:39, Andi Kleen wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
you have more faith in the authors knowledge of how his code actually
behaves than I think is warranted :)
iirc there was a mm patch some time ago to keep track of the actual
unlikely values at
On Tue, 19 Feb 2008 13:33:53 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
Actually one thing I don't like about gcc is that I think it still
emits cmovs for likely/unlikely branches, which is silly (the gcc
developers seem to be in love with that instruction). If that goes
away, then branch
On Tuesday 19 February 2008 13:40, Arjan van de Ven wrote:
On Tue, 19 Feb 2008 13:33:53 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
Actually one thing I don't like about gcc is that I think it still
emits cmovs for likely/unlikely branches, which is silly (the gcc
developers seem to be in
On Tue, Feb 19, 2008 at 01:33:53PM +1100, Nick Piggin wrote:
Note in particular the last predictors; assuming branch ending
with goto, including call, causing early function return or
returning negative constant are not taken. Just these alone
are likely 95+% of the unlikelies in the
On Tuesday 19 February 2008 16:58, Willy Tarreau wrote:
On Tue, Feb 19, 2008 at 01:33:53PM +1100, Nick Piggin wrote:
Note in particular the last predictors; assuming branch ending
with goto, including call, causing early function return or
returning negative constant are not taken. Just
On Tue, Feb 19, 2008 at 08:46:03AM +1100, Michael Ellerman wrote:
On Mon, 2008-02-18 at 16:13 +0200, Adrian Bunk wrote:
On Mon, Feb 18, 2008 at 03:01:35PM +0100, Geert Uytterhoeven wrote:
On Mon, 18 Feb 2008, Adrian Bunk wrote:
This means it generates faster code with a current gcc
On Sat, 2008-02-16 at 10:39 -0800, Arjan van de Ven wrote:
> > >> > you found a great set of bugs..
> > >> > but to be honest... I suspect it's just best to remove unlikely
> > >> > altogether for these cases; unlikely() is almost a
> > >> > go-faster-stripes thing, and if you don't know how to
On Sun, Feb 17, 2008 at 01:45:23AM -0800, Andrew Pinski wrote:
> On Feb 16, 2008 9:58 AM, Willy Tarreau <[EMAIL PROTECTED]> wrote:
> > Last but not least, gcc 4 tends to emit stupid checks, to the point that I
> > have replaced unlikely(x) with (x) in my code when gcc >= 4 is detected.
> > What
>
On Feb 16, 2008 9:58 AM, Willy Tarreau <[EMAIL PROTECTED]> wrote:
> Last but not least, gcc 4 tends to emit stupid checks, to the point that I
> have replaced unlikely(x) with (x) in my code when gcc >= 4 is detected. What
> I observe is that the following code :
>
> if (unlikely(p == NULL))
On Feb 16, 2008 9:58 AM, Willy Tarreau [EMAIL PROTECTED] wrote:
Last but not least, gcc 4 tends to emit stupid checks, to the point that I
have replaced unlikely(x) with (x) in my code when gcc = 4 is detected. What
I observe is that the following code :
if (unlikely(p == NULL)) ...
On Sun, Feb 17, 2008 at 01:45:23AM -0800, Andrew Pinski wrote:
On Feb 16, 2008 9:58 AM, Willy Tarreau [EMAIL PROTECTED] wrote:
Last but not least, gcc 4 tends to emit stupid checks, to the point that I
have replaced unlikely(x) with (x) in my code when gcc = 4 is detected.
What
I observe
On Sat, 2008-02-16 at 10:39 -0800, Arjan van de Ven wrote:
you found a great set of bugs..
but to be honest... I suspect it's just best to remove unlikely
altogether for these cases; unlikely() is almost a
go-faster-stripes thing, and if you don't know how to use it you
On 02/16/2008 08:08 AM, Roel Kluin wrote:
> The patch below was not yet tested. If it's correct as it is, please comment.
> - if (unlikely(plug) == NO_IRQ) {
> + if (unlikely(plug == NO_IRQ)) {
A good catch! I'll put it in with some other 2.6.25 bug fixes.
-Geoff
--
To unsubscribe
On Sat, 16 Feb 2008 10:31:26 -0800
Geoff Levand <[EMAIL PROTECTED]> wrote:
> On 02/16/2008 09:42 AM, Arjan van de Ven wrote:
> > On Sat, 16 Feb 2008 18:33:16 +0100
> > Willy Tarreau <[EMAIL PROTECTED]> wrote:
> >
> >> On Sat, Feb 16, 2008 at 09:25:52AM -0800, Arjan van de Ven wrote:
> >> > On
On 02/16/2008 09:42 AM, Arjan van de Ven wrote:
> On Sat, 16 Feb 2008 18:33:16 +0100
> Willy Tarreau <[EMAIL PROTECTED]> wrote:
>
>> On Sat, Feb 16, 2008 at 09:25:52AM -0800, Arjan van de Ven wrote:
>> > On Sat, 16 Feb 2008 17:08:01 +0100
>> > Roel Kluin <[EMAIL PROTECTED]> wrote:
>> >
>> > >
On Sat, 16 Feb 2008 18:58:49 +0100
> > If you think unlikely() means something else, we should fix what it
> > maps to towards gcc ;) (to.. be empty ;)
>
> eventhough the gcc docs say it's just a hint to help the compiler
> optimize the branch it takes by default, I too have noticed that it
>
On Sat, Feb 16, 2008 at 09:42:26AM -0800, Arjan van de Ven wrote:
> On Sat, 16 Feb 2008 18:33:16 +0100
> Willy Tarreau <[EMAIL PROTECTED]> wrote:
>
> > On Sat, Feb 16, 2008 at 09:25:52AM -0800, Arjan van de Ven wrote:
> > > On Sat, 16 Feb 2008 17:08:01 +0100
> > > Roel Kluin <[EMAIL PROTECTED]>
On Sat, 16 Feb 2008 18:33:16 +0100
Willy Tarreau <[EMAIL PROTECTED]> wrote:
> On Sat, Feb 16, 2008 at 09:25:52AM -0800, Arjan van de Ven wrote:
> > On Sat, 16 Feb 2008 17:08:01 +0100
> > Roel Kluin <[EMAIL PROTECTED]> wrote:
> >
> > > The patch below was not yet tested. If it's correct as it is,
On Sat, Feb 16, 2008 at 09:25:52AM -0800, Arjan van de Ven wrote:
> On Sat, 16 Feb 2008 17:08:01 +0100
> Roel Kluin <[EMAIL PROTECTED]> wrote:
>
> > The patch below was not yet tested. If it's correct as it is, please
> > comment. ---
> > Fix Unlikely(x) == y
> >
>
> you found a great set of
On Sat, 16 Feb 2008 17:08:01 +0100
Roel Kluin <[EMAIL PROTECTED]> wrote:
> The patch below was not yet tested. If it's correct as it is, please
> comment. ---
> Fix Unlikely(x) == y
>
you found a great set of bugs..
but to be honest... I suspect it's just best to remove unlikely altogether for
The patch below was not yet tested. If it's correct as it is, please comment.
---
Fix Unlikely(x) == y
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
---
diff --git a/arch/powerpc/platforms/ps3/interrupt.c
b/arch/powerpc/platforms/ps3/interrupt.c
index 3a6db04..a14e5cd 100644
---
The patch below was not yet tested. If it's correct as it is, please comment.
---
Fix Unlikely(x) == y
Signed-off-by: Roel Kluin [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/platforms/ps3/interrupt.c
b/arch/powerpc/platforms/ps3/interrupt.c
index 3a6db04..a14e5cd 100644
---
On Sat, Feb 16, 2008 at 09:25:52AM -0800, Arjan van de Ven wrote:
On Sat, 16 Feb 2008 17:08:01 +0100
Roel Kluin [EMAIL PROTECTED] wrote:
The patch below was not yet tested. If it's correct as it is, please
comment. ---
Fix Unlikely(x) == y
you found a great set of bugs..
but to be
On Sat, Feb 16, 2008 at 09:42:26AM -0800, Arjan van de Ven wrote:
On Sat, 16 Feb 2008 18:33:16 +0100
Willy Tarreau [EMAIL PROTECTED] wrote:
On Sat, Feb 16, 2008 at 09:25:52AM -0800, Arjan van de Ven wrote:
On Sat, 16 Feb 2008 17:08:01 +0100
Roel Kluin [EMAIL PROTECTED] wrote:
On Sat, 16 Feb 2008 17:08:01 +0100
Roel Kluin [EMAIL PROTECTED] wrote:
The patch below was not yet tested. If it's correct as it is, please
comment. ---
Fix Unlikely(x) == y
you found a great set of bugs..
but to be honest... I suspect it's just best to remove unlikely altogether for
these
On Sat, 16 Feb 2008 18:58:49 +0100
If you think unlikely() means something else, we should fix what it
maps to towards gcc ;) (to.. be empty ;)
eventhough the gcc docs say it's just a hint to help the compiler
optimize the branch it takes by default, I too have noticed that it
more often
On 02/16/2008 09:42 AM, Arjan van de Ven wrote:
On Sat, 16 Feb 2008 18:33:16 +0100
Willy Tarreau [EMAIL PROTECTED] wrote:
On Sat, Feb 16, 2008 at 09:25:52AM -0800, Arjan van de Ven wrote:
On Sat, 16 Feb 2008 17:08:01 +0100
Roel Kluin [EMAIL PROTECTED] wrote:
The patch below was not
On Sat, 16 Feb 2008 10:31:26 -0800
Geoff Levand [EMAIL PROTECTED] wrote:
On 02/16/2008 09:42 AM, Arjan van de Ven wrote:
On Sat, 16 Feb 2008 18:33:16 +0100
Willy Tarreau [EMAIL PROTECTED] wrote:
On Sat, Feb 16, 2008 at 09:25:52AM -0800, Arjan van de Ven wrote:
On Sat, 16 Feb 2008
On Sat, 16 Feb 2008 18:33:16 +0100
Willy Tarreau [EMAIL PROTECTED] wrote:
On Sat, Feb 16, 2008 at 09:25:52AM -0800, Arjan van de Ven wrote:
On Sat, 16 Feb 2008 17:08:01 +0100
Roel Kluin [EMAIL PROTECTED] wrote:
The patch below was not yet tested. If it's correct as it is,
please
On 02/16/2008 08:08 AM, Roel Kluin wrote:
The patch below was not yet tested. If it's correct as it is, please comment.
- if (unlikely(plug) == NO_IRQ) {
+ if (unlikely(plug == NO_IRQ)) {
A good catch! I'll put it in with some other 2.6.25 bug fixes.
-Geoff
--
To unsubscribe from
68 matches
Mail list logo
