Re: [PATCH v2] src/port/snprintf.c: Optimize the common base=10 case in fmtint

Japin Li <japinli@hotmail.com>

From: Japin Li <japinli@hotmail.com>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: pgsql-hackers@postgresql.org, tgl@sss.pgh.pa.us, mark.dilger@enterprisedb.com, andres@anarazel.de, pgsql-hackers@lists.postgresql.org
Date: 2021-10-27T01:36:35Z
Lists: pgsql-hackers
On Wed, 27 Oct 2021 at 04:58, Arjan van de Ven <arjan@linux.intel.com> wrote:
> [PATCH v2] src/port/snprintf.c: Optimize the common base=10 case in fmtint
>
> fmtint() turns an integer into a string for a given base, and to do this
> it does a divide/modulo operation iteratively.
> The only possible base values are 8, 10 and 16
>
> On just about any CPU, divides are a pretty expensive operation, generally
> 10x to 20x or more expensive than adds or multiplies.
>
> By special casing the base values, the compiler (gcc or other) can (and will)
> replace the divide by a multiply with 0xcccccccccccccccd (for base 10) or bitops
> for base 8 and 16, yielding a lot faster code.
>
> I considered a switch statement, but since base 10 is the most common by far,
> I implemented it as a series of if/else statements with a likely() marking the 10 case.
>
> Even though this only shows up in the database creation phase of pgbench and not so much
> during the normal run time, the optimization is simple and high value enough that
> in my opinion it's worth doing
>
>


+		if (likely(base == 10)) {
+			do
+			{
+				convert[sizeof(convert) - (++vallen)] = cvt[uvalue % 10];
+				uvalue = uvalue / 10;
+			} while (uvalue);
+		} else if (base == 16) {

Why do we need likely() for base=10, however, base=16 and base=8 don't need?

-- 
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.



Commits

  1. Speed up printing of integers in snprintf.c.