Re: New CRC algorithm: Slicing by 8

From: Jeremy Drake <pgsql(at)jdrake(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>, mark(at)mark(dot)mielke(dot)cc, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New CRC algorithm: Slicing by 8
Date: 2006-10-23 19:16:19
Message-ID: Pine.BSO.4.64.0610231212560.5201@resin.csoft.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 23 Oct 2006, Tom Lane wrote:

> Jeremy Drake <pgsql(at)jdrake(dot)com> writes:
> > So at this point I realize that intel's compiler is optimizing the loop
> > away, at least for the std crc and probably for both. So I make mycrc an
> > array of 2, and substript mycrc[j&1] in the loop.
>
> That's not a good workaround, because making mycrc expensive to access
> means your inner loop timing isn't credible at all. Instead try making the
> buffer array nonlocal --- malloc it, perhaps.

That did not make any difference. The way I see it, the only way to
convince the compiler it really needs to do this loop more than once is to
make it think it is not overwriting the same variable every time. The
subscript was the cheapest way I could think of to do that. Any other
suggestions on how to do this are welcome.

>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>
>

--
I like being single. I'm always there when I need me.
-- Art Leo

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-10-23 19:21:09 Re: New CRC algorithm: Slicing by 8
Previous Message Tom Lane 2006-10-23 19:12:07 Re: New CRC algorithm: Slicing by 8