Re: Speed up JSON escape processing with SIMD plus other optimisations - Mailing list pgsql-hackers

From David Rowley
Subject Re: Speed up JSON escape processing with SIMD plus other optimisations
Date
Msg-id CAApHDvptffkvmUVqx2ULMyZGoMsbt2B8b5op5hwBk2pZudzjdw@mail.gmail.com
Whole thread Raw
In response to Re: Speed up JSON escape processing with SIMD plus other optimisations  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Speed up JSON escape processing with SIMD plus other optimisations
List pgsql-hackers
On Thu, 1 Aug 2024 at 16:15, David Rowley <dgrowleyml@gmail.com> wrote:
> I'm pretty happy with this now so I'd like to commit this and move on
> to other work.  Doing "#define ESCAPE_JSON_MAX_LOOKHEAD 512", seems
> like the right thing. If anyone else wants to verify my results or
> take a look at the patch, please do so.

I did some more testing on this on a few different machines;  apple M2
Ultra, AMD 7945HX and with a Raspberry Pi 4.

I've attached the results as graphs with the master time normalised to
1.  I tried out quite a few different values for flushing the buffer,
256 bytes in powers of 2 up to 8192 bytes.  It seems like each machine
has its own preference to what this should be set to, but no machine
seems to be too picky about the exact value. They're all small enough
values to fit in L1d cache on each of the CPUs. Test 4 shouldn't
change much as there's no SIMD going on in that test. You might notice
a bit of noise from all machines for test 4, apart from the M2.  You
can assume a similar level of noise for tests 1 to 3 on each of the
machines.  The Raspberry Pi does seem to prefer not flushing the
buffer until the end (listed as "patched" in the graphs). I suspect
that's because that CPU does better with less code. I've not taken
these results quite as seriously since it's likely a platform that we
wouldn't want to prefer when it comes to tuning optimisations. I was
mostly interested in not seeing regressions.

I think, if nobody else thinks differently, I'll rename
ESCAPE_JSON_MAX_LOOKHEAD to ESCAPE_JSON_FLUSH_AFTER and set it to 512.
The exact value does not seem to matter too much and 512 seems fine.
It's better for the M2 than the 7945HX, but not by much.

I've also attached the script I ran to get these results and also the
full results.

David

Attachment

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Fix inappropriate uses of atol()
Next
From: Melanie Plageman
Date:
Subject: Re: Draft release notes for next week's releases are up