From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Performance improvements for src/port/snprintf.c
Date: Wed, 26 Sep 2018 17:40:22 -0700
Message-ID: <20180927004022.lfhffbj3roxzf5ca@alap3.anarazel.de> (raw)
In-Reply-To: <15882.1538007944@sss.pgh.pa.us>
References: <11787.1534530779@sss.pgh.pa.us>
<2238.1534716465@sss.pgh.pa.us>
<f5dd41da-911c-fd97-1b78-e0f8c0141897@postgrespro.ru>
<15785.1536776055@sss.pgh.pa.us>
<20180926220419.lorxpb564gakdjkz@alap3.anarazel.de>
<20180926221814.el5nwmkez6zfmzbz@alap3.anarazel.de>
<14302.1538005507@sss.pgh.pa.us>
<20180926235821.zmpxqv66ob7v2ffi@alap3.anarazel.de>
<15882.1538007944@sss.pgh.pa.us>
On 2018-09-26 20:25:44 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2018-09-26 19:45:07 -0400, Tom Lane wrote:
> >> No, there are no additional layers that weren't there before ---
> >> snprintf.c's snprintf() slots in directly where the platform's did before.
>
> > Hm? What I mean is that we can't realistically be faster with the
> > current architecture, because for floating point we end up doing glibc
> > sprintf() in either case.
>
> Oh, you mean specifically for the float conversion case. I still say
> that I will *not* accept judging this code solely on the float case.
Oh, it should definitely not be judged solely based on floating point,
we agree.
> The string and integer cases are at least as important if not more so.
I think the integer stuff has become a *little* bit less important,
because we converted the hot cases over to pg_lto etc.
> >> Interesting. strfromd() is a glibc-ism, and a fairly recent one at
> >> that (my RHEL6 box doesn't seem to have it).
>
> > It's C99 afaict.
>
> It's not in POSIX 2008, and I don't see it in my admittedly-draft
> copy of C99 either. But that's not real relevant -- I don't see
> much reason not to use it if we want a quick and dirty answer for
> the platforms that have it.
Right, I really just wanted some more baseline numbers.
> If we had more ambition, we might consider stealing the float
> conversion logic out of the "stb" library that Alexander pointed
> to upthread. It says it's public domain, so there's no license
> impediment to borrowing some code ...
Yea, I started to play around with doing so with musl, but based on
early my benchmarks it's not fast enough to bother. I've not integrated
it into our code, but instead printed two floating point numbers with
your test:
musl 5000000 iterations:
snprintf time = 3144.46 ms total, 0.000628892 ms per iteration
pg_snprintf time = 4215.1 ms total, 0.00084302 ms per iteration
ratio = 1.340
glibc 5000000 iterations:
snprintf time = 1680.82 ms total, 0.000336165 ms per iteration
pg_snprintf time = 2629.46 ms total, 0.000525892 ms per iteration
ratio = 1.564
So there's pretty clearly no point in even considering starting from
musl.
Greetings,
Andres Freund
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andres@anarazel.de, tgl@sss.pgh.pa.us, a.kuzmenkov@postgrespro.ru, pgsql-hackers@lists.postgresql.org
Subject: Re: Performance improvements for src/port/snprintf.c
In-Reply-To: <20180927004022.lfhffbj3roxzf5ca@alap3.anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox