| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Jeremy Kerr <jk(at)ozlabs(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [PATCH v4] Avoid manual shift-and-test logic in AllocSetFreeIndex |
| Date: | 2009-07-20 21:21:29 |
| Message-ID: | 407d949e0907201421m1eb26ef9u171f2790e5ef16f7@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jul 20, 2009 at 8:37 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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.
| Attachment | Content-Type | Size |
|---|---|---|
| testit.c | text/x-csrc | 3.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2009-07-20 21:26:04 | Re: [PATCH] SE-PgSQL/tiny rev.2193 |
| Previous Message | Bruce Momjian | 2009-07-20 20:55:07 | Re: [GENERAL] large object does not exist after pg_migrator |