Horton

Re: [PATCH] Hex-coding optimizations using SVE on ARM.

Chiranmoy.Bhattacharya@fujitsu.com <chiranmoy.bhattacharya@fujitsu.com>

View thread
From: "Chiranmoy.Bhattacharya@fujitsu.com" <Chiranmoy.Bhattacharya@fujitsu.com>
To: Nathan Bossart <nathandbossart@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: John Naylor <johncnaylorls@gmail.com>, David Rowley <dgrowleyml@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "Devanga.Susmitha@fujitsu.com" <Devanga.Susmitha@fujitsu.com>, "Ragesh.Hajela@fujitsu.com" <Ragesh.Hajela@fujitsu.com>
Date: 2025-09-12T18:49:01Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Optimize hex_encode() and hex_decode() using SIMD.

  2. Speed up hex_encode with bytewise lookup

> My current philosophy with this stuff is to favor simplicity,
> maintainability, portability, etc. over extracting the absolute maximum
> amount of performance gain, so I think we should proceed with the simd.h
> approach. But I'm curious how others feel about this.

>  +1. The maintainability aspect is critical over the long run.
> Also, there's a very real danger of optimizing for the specific
> hardware and test case you are working with, leading to actually
> worse performance with future hardware.

Using simd.h does make it easier to maintain.
Is there a plan to upgrade simd.h to use SSE4 or SSSE3 in the future?
Since SSE2 is much older, it lacks some of the more specialized intrinsics.
For example, vectorized table lookup can be implemented via [0], and
it’s available in SSSE3 and later x86 instruction sets.

[0] https://www.felixcloutier.com/x86/pshufb

-----
Chiranmoy