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;
next prev 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).