Re: [PATCH v4] Avoid manual shift-and-test logic in AllocSetFreeIndex - Mailing list pgsql-hackers

From Greg Stark
Subject Re: [PATCH v4] Avoid manual shift-and-test logic in AllocSetFreeIndex
Date
Msg-id 407d949e0907201421m1eb26ef9u171f2790e5ef16f7@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH v4] Avoid manual shift-and-test logic in AllocSetFreeIndex  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH v4] Avoid manual shift-and-test logic in AllocSetFreeIndex  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Jul 20, 2009 at 8:37 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Anyone want to see if they can beat that?  Some testing on other
> architectures would help too.

Hm, I took the three implementations so far (normal, unrolled, and
clz) as well as the two from
http://graphics.stanford.edu/~seander/bithacks.html#IntegerLogObvious
and got some very strange results:


normal:       1.494s
clz:          2.214s
unrolled:     2.966s
lookup table: 0.001s
float hack:  11.930s


I can't see why the unrolled implementation is slower than the
non-unrolled so I'm suspecting something's wrong with my #ifdefs but I
don't see it.

I do think the code I grabbed from the stanford page might be
off-by-one for our purposes but I haven't looked closely at that.

I also wonder if this microbenchmark is actually ok because it's
testing the same value over and over so any branch-prediction will
shine unrealistically well.



--
greg
http://mit.edu/~gsstark/resume.pdf

Attachment

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] large object does not exist after pg_migrator
Next
From: Robert Haas
Date:
Subject: Re: [PATCH] SE-PgSQL/tiny rev.2193