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>
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-22T10:58:09Z
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

> The approach looks generally reasonable to me, but IMHO the code needs
  much more commentary to explain how it works.

Added comments to explain the SVE implementation.

> I would be interested to see how your bytea test compares with the
improvements added in commit e24d770 and with sending the data in binary.

The following are the bytea test results with commit e24d770.
The same query and tables were used.

With commit e24d770:
Query exec time: 2.324 sec
hex_encode function time: 0.72 sec

Pre-commit e24d770:
Query exec time: 2.858 sec
hex_encode function time: 1.228 sec

SVE patch:
Query exec time: 1.654 sec
hex_encode_sve function time: 0.085 sec

> 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.

---
Chiranmoy