Re: What exactly is our CRC algorithm?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org, Andres Freund <andres(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: What exactly is our CRC algorithm?
Date: 2015-04-02 15:58:09
Message-ID: 20150402155809.GE17586@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-04-02 20:57:24 +0530, Abhijit Menon-Sen wrote:
> At 2015-04-02 17:58:23 +0300, hlinnaka(at)iki(dot)fi wrote:
> >
> > We're only using inline assembly to force producing SSE 4.2 code, even
> > when -msse4.2 is not used. That feels wrong.
>
> Why? It feels OK to me (and to Andres, per earlier discussions about
> exactly this topic). Doing it this way allows the binary to run on a
> non-SSE4.2 platform (and not use the CRC instructions).

Right. And SSE4.2 isn't that widespread yet.

> > I believe the GCC way to do this would be to put the SSE4.2-specific
> > code into a separate source file, and compile that file with
> > "-msse4.2". And when you compile with -msse4.2, gcc actually also
> > supports the _mm_crc32_u8/u64 intrinsics.

To me this seems like a somewhat pointless exercise. I actually think
from a performance POV it's better to have all the functions in one
source file, so the compiler can inline things into the trampoline if it
feels like it.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-04-02 16:00:52 Re: varlena.c hash_any() and hash_uint32() calls require DatumGetUInt32()
Previous Message Robert Haas 2015-04-02 15:55:31 Re: [COMMITTERS] pgsql: Centralize definition of integer limits.