qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PULL 3/7] qxl: refactor rounding up to a nearest power of 2
Date: Thu, 5 Mar 2015 16:12:01 +0100	[thread overview]
Message-ID: <20150305151200.GA3361@potion.redhat.com> (raw)
In-Reply-To: <87twxzai0i.fsf@blackfin.pond.sub.org>

2015-03-05 10:52+0100, Markus Armbruster:
> Gerd Hoffmann <kraxel@redhat.com> writes:
> 
> > From: Radim Krčmář <rkrcmar@redhat.com>
> >
> > We already have pow2floor, mirror it and use instead of a function with
> > similar results (same in used domain), to clarify our intent.
> >
> > Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
> > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> [...]
> > +/* round up to the nearest power of 2 (0 if overflow) */
> 
> Callers need to check for overflow, but that's the callers' problem.

It's obvious that the return value is 0 in this case -- the correct
result would have been a multiple of the modulo, but I wanted to be
explicit about it.

> > +uint64_t pow2ceil(uint64_t value)
> > +{
> > +    uint8_t nlz = clz64(value);
> 
> You convert the value of clz64() from int to uint8_t only to promote it
> right back to int in every single use.  Please don't muddy the waters
> that way.

Ok, the down-cast might cause some runtime overhead.
(I don't understand why the return value of clz64() is 'int' --
 using the smallest sufficient data type seems clearer to me.)

> > +    if (is_power_of_2(value)) {
> > +        return value;
> > +    }
> > +    if (!nlz) {
> > +        return 0;
> > +    }
> > +    return 1ULL << (64 - nlz);
> > +}
> 
> Doesn't really mirror pow2floor() in master, because that one uses
> int64_t.  Fine with me, because my "[PATCH 0/2] Proactive pow2floor()
> fix, and dead code removal" changes pow2floor() to uint64_t.

Yeah, I didn't understand why that returned 'int64_t' either.

I understood that pow2floor() used is_power_of_2() because it expected
higher probability of numbers that already are the power, so the clunky
code was balanced by a faster common case; and I duplicated this.
(clz64() without hardware support is slow.)

> Unfortunately, the two patches conflict.
> 
> This patch's implementation of pow2ceil() is needlessly complicated,
> just like pow2floor() in master.  Simpler:
> 
>     uint64_t pow2ceil2(uint64_t value)
>     {
>         int n = clz64(value - 1);
>         return n ? 1ull << (64 - n) : 0;

Mapping 0 to 0 is probably what we would want in most uses, but I'd name
the function differently then -- the closest power of 2 bigger than (or
equal to) 0 is 1, and 2^64 == 0, so the result was mathematically
correct.

We also lose the ability to detect overflow after the call, so callers
would have to do it before, with a code like
  'passed_value > DESTINATION_TYPE_MAX / 2 + 1'

> I can rebase my patch on top of this one, and clean things up to my
> taste.

Ok, thanks!

---
If eliminating is_power_of_2() and using the ternary operator is fine,
I'd write it like this:

    unsigned nlz = clz64(value - 1);
    return !value ? 1 : (nlz ? 1ULL << (64 - nlz) : 0);

If we don't believe that the compiler can optimize, and after applying
all I know about QEMU coding style:

    int nlz;

    if (!value) {
        return 1;
    }
    nlz = clz64(value - 1);
    return n ? 1ull << (64 - n) : 0;

  parent reply	other threads:[~2015-03-05 15:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-04 14:30 [Qemu-devel] [PULL 0/7] spice patch queue Gerd Hoffmann
2015-03-04 14:30 ` [Qemu-devel] [PULL 1/7] qxl: document minimal video memory for new modes Gerd Hoffmann
2015-03-04 14:30 ` [Qemu-devel] [PULL 2/7] spice: fix invalid memory access to vga.vram Gerd Hoffmann
2015-03-04 14:30 ` [Qemu-devel] [PULL 3/7] qxl: refactor rounding up to a nearest power of 2 Gerd Hoffmann
2015-03-05  4:57   ` Dongsheng Song
2015-03-05 15:35     ` Radim Krčmář
2015-03-05  9:52   ` Markus Armbruster
2015-03-05 10:11     ` Gerd Hoffmann
2015-03-05 15:12     ` Radim Krčmář [this message]
2015-03-04 14:30 ` [Qemu-devel] [PULL 4/7] vga: refactor vram_size clamping and rounding Gerd Hoffmann
2015-03-04 14:30 ` [Qemu-devel] [PULL 5/7] qxl: drop update_displaychangelistener call for secondary qxl devices Gerd Hoffmann
2015-03-04 14:30 ` [Qemu-devel] [PULL 6/7] hmp: info spice: Show string channel name Gerd Hoffmann
2015-03-04 14:30 ` [Qemu-devel] [PULL 7/7] hmp: info spice: take out webdav Gerd Hoffmann
2015-03-08 12:27 ` [Qemu-devel] [PULL 0/7] spice patch queue Peter Maydell

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=20150305151200.GA3361@potion.redhat.com \
    --to=rkrcmar@redhat.com \
    --cc=armbru@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.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 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).