On 02/24/2017 06:47 PM, Bruce Momjian wrote:
On Sat, Jan 21, 2017 at 09:02:25PM +0200, Ants Aasma wrote:
It might be worth looking into using the CRC CPU instruction to reduce this
overhead, like we do for the WAL checksums. Since that is a different
algorithm it would be a compatibility break and we would need to support the
old algorithm for upgraded clusters..
We looked at that when picking the algorithm. At that point it seemed
that CRC CPU instructions were not universal enough to rely on them.
The algorithm we ended up on was designed to be fast on SIMD hardware.
Unfortunately on x86-64 that required SSE4.1 integer instructions, so
with default compiles there is a lot of performance left on table. A
low hanging fruit would be to do CPU detection like the CRC case and
enable a SSE4.1 optimized variant when those instructions are
available. IIRC it was actually a lot faster than the naive hardware
CRC that is used for WAL and about on par with interleaved CRC.
Uh, I thought already did compile-time testing for SSE4.1 and used them
if present. Why do you say "with default compiles there is a lot of
performance left on table?"
Compile-time is not enough - we build binary packages that may then be
installed on machines without the SSE4.1 instructions available.
On Intel this may not be a huge issue - the first microarchitecture with
SSE4.1 was "Nehalem", announced in 2007, so we're only left with very
old boxes based on "Intel Core" (and perhaps the even older P6).
On AMD, it's a bit worse - the first micro-architecture with SSE4.1 was
Bulldozer (late 2011). So quite a few CPUs out there, even if most
people use Intel.
In any case, we can't just build x86-64 packages with compile-time
SSE4.1 checks.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
