From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Subject: Re: [musl] Superfluous shift in qsort()?
Date: Thu, 2 Jul 2020 16:44:47 +0200 [thread overview]
Message-ID: <20200702144447.GB6635@voyager> (raw)
In-Reply-To: <20200701212309.5ooyvfq47sh4llwi@mae>
On Wed, Jul 01, 2020 at 11:23:09PM +0200, Valentin Ochs wrote:
> On Wed, Jul 01, 2020 at 04:44:56PM -0400, Rich Felker wrote:
> > On Wed, Jul 01, 2020 at 08:50:26PM +0200, Markus Wichmann wrote:
> > > Hi all,
> > >
> > > I noticed something while reading code today: Near the end of qsort(),
> > > we have this gem:
> > >
> > > shl(p, 2);
> > > pshift -= 2;
> > > p[0] ^= 7;
> > > shr(p, 1);
> > >
> > > Now, I don't know if I am missing something, but don't the shl and the
> > > shr partially cancel out? Isn't this the same as
> > >
> > > shl(p, 1);
> > > p[0] ^= 3;
> > >
> > > As it is, it isn't wrong, just weird.
> >
> > Assuming non-overflow, I think they're equivalent (also assuming you
> > keep the pshift-=2).
>
> Yes, it looks that way. I'm afraid I don't have any further insight -
> it's been quite a while since I thought about the qsort code, and I've
> not been doing much work on algorithms over the last couple of years.
> The only thing I can think of is that one could figure out which
> behaviour with regard to overflow in shl() should be the valid one. I
> suspect that replacing it would be valid and this is some transformation
> I did while implementing smoothsort without realizing that this can be
> simplified.
>
> Cheers,
> Valentin
>
Overflow on shl() is completely impossible. To overflow a shl(p, 2), we
would need the penultimate bit in p to be set. Every bit in p stands in for
a tree of that order, so if bit n is set, the heap contains a tree with
a number of elements equal to the n'th Leonardo number.
I don't know how big the Leonardo number corresponding to the
penultimate bit is, but I do know that halfway through the upper word
(wasn't the factor something like 1.44 or so?), the Leonardo numbers get
too big to be contained in a machine word. Meaning that tree would be
way too large to be addressed.
I concur that this looks like a missed optimization opportunity, and not
a deliberate design decision.
Ciao,
Markus
next prev parent reply other threads:[~2020-07-02 14:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-01 18:50 Markus Wichmann
2020-07-01 20:44 ` Rich Felker
2020-07-01 21:23 ` Valentin Ochs
2020-07-02 14:44 ` Markus Wichmann [this message]
2020-07-06 22:01 ` Rich Felker
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=20200702144447.GB6635@voyager \
--to=nullplan@gmx.net \
--cc=musl@lists.openwall.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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).