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
-
Speed up printing of integers in snprintf.c.
- 3c17926eedd5 15.0 landed