pgsql: Speed up tail processing when hashing aligned C strings, take tw
Speed up tail processing when hashing aligned C strings, take two After encountering the NUL terminator, the word-at-a-time loop exits and we must hash the remaining bytes. Previously we calculated the terminator's position and re-loaded the remaining bytes from the input string. This was slower than the unaligned case for very short strings. We already have all the data we need in a register, so let's just mask off the bytes we need and hash them immediately. In addition to endianness issues, the previous attempt upset valgrind in the way it computed the mask. Whether by accident or by wisdom, the author's proposed method passes locally with valgrind 3.22. Ants Aasma, with cosmetic adjustments by me Discussion: https://postgr.es/m/CANwKhkP7pCiW_5fAswLhs71-JKGEz1c1%2BPC0a_w1fwY4iGMqUA%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a365d9e2e8c1ead27203a4431211098292777d3b Modified Files -- src/include/common/hashfn_unstable.h | 46 1 file changed, 36 insertions(+), 10 deletions(-)
Re: pgsql: Speed up tail processing when hashing aligned C strings
On Sun, Mar 31, 2024 at 12:32 PM John Naylor wrote: > > Speed up tail processing when hashing aligned C strings Skink reports valgrind error with Conditional jump or move depends on uninitialised value(s) I'll revert this soon to analyze, but first I'd like to see if any big-endian animals have any issue.
pgsql: Speed up tail processing when hashing aligned C strings
Speed up tail processing when hashing aligned C strings After encountering the NUL terminator, the word-at-a-time loop exits and we must hash the remaining bytes. Previously we calculated the terminator's position and re-loaded the remaining bytes from the input string. We already have all the data we need in a register, so let's just mask off the bytes we need and hash them immediately. The mask can be cheaply computed without knowing the terminator's position. We still need that position for the length calculation, but the CPU can now do that in parallel with other work, shortening the dependency chain. Ants Aasma and John Naylor Discussion: https://postgr.es/m/CANwKhkP7pCiW_5fAswLhs71-JKGEz1c1%2BPC0a_w1fwY4iGMqUA%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/07f0f6abfc7f6c55cede528d9689dedecefc734a Modified Files -- src/include/common/hashfn_unstable.h | 44 1 file changed, 34 insertions(+), 10 deletions(-)