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

Nathan Bossart <nathandbossart@gmail.com>

From: Nathan Bossart <nathandbossart@gmail.com>

To: "Chiranmoy.Bhattacharya@fujitsu.com" <Chiranmoy.Bhattacharya@fujitsu.com>

Cc: Tom Lane <tgl@sss.pgh.pa.us>, David Rowley <dgrowleyml@gmail.com>, John Naylor <johncnaylorls@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-01-25T22:07:27Z

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 →

Optimize hex_encode() and hex_decode() using SIMD.
- ec8719ccbfcd 19 (unreleased) landed
Speed up hex_encode with bytewise lookup
- e24d77080b36 18.0 landed

On Wed, Jan 22, 2025 at 10:58:09AM +0000, Chiranmoy.Bhattacharya@fujitsu.com wrote:
>> The functions that test the length before potentially calling a function
>> pointer should probably be inlined (see pg_popcount() in pg_bitutils.h).
>> I wouldn't be surprised if some compilers are inlining this stuff
>> already, but it's probably worth being explicit about it.
> 
> Should we implement an inline function in "utils/builtins.h", similar to
> pg_popcount()? Currently, we have not modified the header file, everything
> is statically implemented in encode.c.

Yeah, that's what I'm currently thinking we should do.

-- 
nathan