pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org, Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>
Subject: Re: Performance improvements for src/port/snprintf.c
Date: Fri, 05 Oct 2018 23:59:15 -0400
Message-ID: <15405.1538798355@sss.pgh.pa.us> (raw)
In-Reply-To: <87o9c7ahjh.fsf@news-spur.riddles.org.uk>
References: <28321.1538585692@sss.pgh.pa.us>
	<20181003170043.thdyezozi343dkuc@alap3.anarazel.de>
	<2132.1538587869@sss.pgh.pa.us>
	<20181003173639.tncawup2nnkp7vbv@alap3.anarazel.de>
	<2435.1538588403@sss.pgh.pa.us>
	<20181003174513.wxjxfj7eepytnlqa@alap3.anarazel.de>
	<3316.1538589695@sss.pgh.pa.us>
	<20181003183552.xaams6fau3i7oybj@alap3.anarazel.de>
	<6797.1538592539@sss.pgh.pa.us>
	<30726.1538754899@sss.pgh.pa.us>
	<20181005165819.h7gdzcbwhnhofq2b@alap3.anarazel.de>
	<87sh1jaiyq.fsf@news-spur.riddles.org.uk>
	<13967.1538795773@sss.pgh.pa.us>
	<87o9c7ahjh.fsf@news-spur.riddles.org.uk>

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
>  Tom> Oh yeah?  Where's the code for this?

> Upstream code is at https://github.com/ulfjack/ryu
> ...
> I attach the patch I've used for testing, which has these changes from
> upstream Ryu:

Thanks.  Just scanning through the code quickly, I note that it assumes
IEEE float format, which is probably okay but I suppose we might want
a configure switch to disable it (and revert to platform sprintf).
I couldn't immediately figure out if it's got endianness assumptions;
but even if it does, that'd likely only affect the initial disassembly
of the IEEE format, so probably not a huge deal.

I wonder which variant of the code you were testing (e.g. HAS_UINT128
or not).

There's a pretty large gap between this code and PG coding conventions,
both as to layout and portability rules.  I wonder if we'd be better off
to implement the algorithm afresh instead of whacking this particular
code past the point of unrecognizability.

> The regression tests for
> float8 fail of course since Ryu's output format differs (it always
> includes an exponent, but the code for that part can be tweaked without
> touching the main algorithm).

Yeah, one would hope.  But I wonder whether it always produces the
same low-order digits, and if not, whether people will complain.
We just had somebody griping about a change in insignificant zeroes
in timestamp output :-(.  Still, seems worth further investigation.

			regards, tom lane




view thread (65+ messages)  latest in thread

Message-ID: <15405.1538798355@sss.pgh.pa.us>
Permalink:  ../15405.1538798355@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/15405.1538798355@sss.pgh.pa.us

 · 

reply

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: tgl@sss.pgh.pa.us, andrew@tao11.riddles.org.uk, andres@anarazel.de, thomas.munro@enterprisedb.com, a.kuzmenkov@postgrespro.ru
  Subject: Re: Performance improvements for src/port/snprintf.c
  In-Reply-To: <15405.1538798355@sss.pgh.pa.us>

* 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