All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: xenomai@xenomai.org
Subject: Re: [Xenomai-core] Re: [patch, RFC] detect unhandled interrupts
Date: Wed, 30 Aug 2006 18:20:54 +0200	[thread overview]
Message-ID: <17653.47846.660686.886474@domain.hid> (raw)
In-Reply-To: <b647ffbd0608300903x4ee0571fq627901c7805b87ee@domain.hid>

Dmitry Adamushko wrote:
 > > > I had it also in mind and grepped use cases of "unlikely" in kernel/
 > > > directory. There are a number of unlikely (a op. b) but none of
 > > > unlikely(a) op. unlikely (b).
 > > >
 > > > Out of curiosity, one may disassemble code for both cases. My feeling
 > > > though, unlikely(a && b) is at least not worse (cpu and compiler-wise)
 > > > but don't want to speculate as I'm quite uneducated bozo here :)
 > > >
 > >
 > > Since likely/unlikely are hints given to the compiler for optimizing
 > > branches, you might want to give it all the information you have at hand
 > > immediately, to augment your chances to have it do the right thing [just
 > > in case the optimizer has no more short-term memory than a red fish...]
 > 
 > 
 > 
 > (1) if (unlikely(a) && unlikely(b))
 > (2) if (unlikely(a && b))
 > 
 > (1) results in 1 more "je" instruction on the path of the CPU to a "likely"
 > branch than in case of (2).
 > And as someone more educated in this field has just told me (hopefully I got
 > it correct), any conditional jump leads to the pipeline flushing (maybe
 > recent CPUs can avoid it indeed in case a condition is false).
 > 
 > So the code that contains less conditional && unconditional jumps is more
 > pipeline-friendly.
 > 
 > And a compiler is not (always) "smart" (should it be though?) enough to make
 > the following transformation :
 > 
 > unlikely(a) && unlikely(b) => unlikely(a + b)

If I was a compiler, I would evaluate the two differently. When
evaluating a && b, there are three branches: !a, a && !b, a && b, the
first two of which jump to the same block, but that's not important.

when writing unlikely(a) && unlikely(b), you mean that !a is likely, 
a && !b is at the same time likely and unlikely (so, probably unlikely
if we assume that the probability of the association is the product of
the elementary probabilities) a && b is unlikely.

when writing unlikely(a && b), you mean that !a and a && !b are likely,
whereas a && b is unlikely.

-- 


					    Gilles Chanteperdrix.


  reply	other threads:[~2006-08-30 16:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-29 19:28 [Xenomai-core] [patch, RFC] detect unhandled interrupts Dmitry Adamushko
     [not found] ` <44F496D7.60609@domain.hid>
2006-08-29 19:38   ` [Xenomai-core] " Dmitry Adamushko
2006-08-29 19:50 ` Jan Kiszka
2006-08-29 20:34   ` Dmitry Adamushko
2006-08-30 13:18     ` Philippe Gerum
2006-08-30 16:03       ` Dmitry Adamushko
2006-08-30 16:20         ` Gilles Chanteperdrix [this message]
2006-08-30 13:29     ` Jan Kiszka
2006-08-30 17:10       ` Dmitry Adamushko
2006-08-30 17:25         ` Dmitry Adamushko
2006-08-31  8:12           ` Dmitry Adamushko
2006-08-30 17:33         ` Jan Kiszka
2006-08-30 17:55       ` Philippe Gerum
2006-08-30 18:50         ` Jan Kiszka
2006-08-30 20:47           ` Philippe Gerum
2006-08-30 20:55             ` Jan Kiszka
2006-08-30 20:59               ` Philippe Gerum
2006-08-30 21:01                 ` Jan Kiszka
2006-08-30 21:58                   ` Philippe Gerum
2006-08-31  8:31 ` [Xenomai-core] " Philippe Gerum
2006-08-31 19:11   ` Jan Kiszka
2006-08-31 19:31     ` Philippe Gerum
2006-08-31 19:49       ` Jan Kiszka
2006-08-31 19:48     ` Philippe Gerum
2006-08-31 20:02     ` Dmitry Adamushko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17653.47846.660686.886474@domain.hid \
    --to=gilles.chanteperdrix@xenomai.org \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.