From: Mikael Pettersson <mikpe@it.uu.se>
To: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: Wedson Almeida Filho <wedsonaf@gmail.com>,
Joe Perches <joe@perches.com>,
Rusty Russell <rusty@rustcorp.com.au>,
"Tim Abbott" <tabbott@ksplice.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] lib: One less subtraction in binary search iterations.
Date: Tue, 9 Jul 2013 11:19:07 +0200 [thread overview]
Message-ID: <20955.54667.360558.574423@pilspetsen.it.uu.se> (raw)
In-Reply-To: <51DBC021.5040805@synopsys.com>
Vineet Gupta writes:
> On 07/09/2013 09:21 AM, Wedson Almeida Filho wrote:
> > On Sat, Jul 6, 2013 at 9:59 PM, Joe Perches <joe@perches.com> wrote:
> >>
> >> Not correct.
> >>
> >>> while (start < end) {
> >>> - size_t mid = start + (end - start) / 2;
> >>> + size_t mid = (start + end) / 2;
> >>
> >> size_t start = 0x80000000;
> >> size_t end = 0x80000001;
> >
> > Good point, they aren't equivalent in all cases.
> >
> > For the overflow to happen though, we need an array with at least
> > N/2+1 entries, where N is the address space size. The array wouldn't
> > fit in addressable memory if the element size is greater than 1, so
> > this can only really happen when the element size is 1. Even then, it
> > would require the kernel range to be greater than half of all
> > addressable memory, and allow an allocation taking that much memory. I
> > don't know all architectures where linux runs, but I don't think such
> > configuration is likely to exist.
> >
>
> It does. In ARC port (arch/arc), the untranslated address space starts at
> 0x8000_0000 and this is where kernel is linked at. So all ARC kernel addresses
> (code/data) lie in that range. This means you don't need special corner case for
> this trip on ARC - it will break rightaway - unless I'm missing something.
start and end aren't addresses but array indices relative to 'base'.
So even on ARC you should be safe, as long as no array has SIZE_MAX/2
or more elements.
I'm however far from convinced this micro-optimization is worth the
obvious source code quality reduction. Surely the eliminated subtraction
is in the noise compared to the multiplies, indirect function calls,
and memory dereferences (in the cmp functions)?
It should be possible to eliminate the multiplies, since no array can
cross the -1/0 address boundary. But even that is questionable: does
anyone have perf data showing that bsearch performance is a problem?
next prev parent reply other threads:[~2013-07-09 9:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-06 23:07 Wedson Almeida Filho
2013-07-07 4:59 ` Joe Perches
2013-07-09 3:51 ` Wedson Almeida Filho
2013-07-09 4:12 ` Joe Perches
2013-07-09 4:58 ` Wedson Almeida Filho
2013-07-09 6:37 ` [PATCH v2] " Wedson Almeida Filho
2013-07-15 5:07 ` Rusty Russell
2013-07-09 7:47 ` [PATCH] " Vineet Gupta
2013-07-09 9:19 ` Mikael Pettersson [this message]
2013-07-08 1:46 ` Rusty Russell
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=20955.54667.360558.574423@pilspetsen.it.uu.se \
--to=mikpe@it.uu.se \
--cc=Vineet.Gupta1@synopsys.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=tabbott@ksplice.com \
--cc=wedsonaf@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®