Horton

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

Nathan Bossart <nathandbossart@gmail.com>

View thread
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Rowley <dgrowleyml@gmail.com>, John Naylor <johncnaylorls@gmail.com>, "Chiranmoy.Bhattacharya@fujitsu.com" <Chiranmoy.Bhattacharya@fujitsu.com>, "Devanga.Susmitha@fujitsu.com" <Devanga.Susmitha@fujitsu.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "Ragesh.Hajela@fujitsu.com" <Ragesh.Hajela@fujitsu.com>
Date: 2025-01-17T17:15:29Z
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

With commit e24d770 in place, I took a closer look at hex_decode(), and I
concluded that doing anything better without intrinsics would likely
require either a huge lookup table or something with complexity rivalling
the instrinsics approach (while also not rivalling its performance).  So, I
took a closer look at the instrinsics patches and had the following
thoughts:

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

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

* Finally, I think we should ensure we've established a really strong case
  for this optimization.  IME these intrinsics patches require a ton of
  time and energy, and the code is often extremely complex.  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.

-- 
nathan