Over in the what-about-%m thread, we speculated about replacing the
platform's *printf functions if they didn't support %m, which would
basically mean using src/port/snprintf.c on all non-glibc platforms,
rather than only on Windows as happens right now (ignoring some
obsolete platforms with busted
Over in the what-about-%m thread, we speculated about replacing the
platform's *printf functions if they didn't support %m, which would
basically mean using src/port/snprintf.c on all non-glibc platforms,
rather than only on Windows as happens right now (ignoring some
obsolete platforms with busted
On 2018-09-12 14:14:15 -0400, Tom Lane wrote:
> Alexander Kuzmenkov writes:
> > I benchmarked this, using your testbed and comparing to libc sprintf
> > (Ubuntu GLIBC 2.27-0ubuntu3) and another implementation I know [1], all
> > compiled with gcc 5.
>
> Thanks for reviewing!
>
> The cfbot noticed
On 2018-09-26 15:04:20 -0700, Andres Freund wrote:
> On 2018-09-12 14:14:15 -0400, Tom Lane wrote:
> > Alexander Kuzmenkov writes:
> > > I benchmarked this, using your testbed and comparing to libc sprintf
> > > (Ubuntu GLIBC 2.27-0ubuntu3) and another implementation I know [1], all
> > > compiled
On 2018-08-17 14:32:59 -0400, Tom Lane wrote:
> I've been looking into the possible performance consequences of that,
> in particular comparing snprintf.c to the library versions on macOS,
> FreeBSD, OpenBSD, and NetBSD. While it held up well in simpler cases,
> I noted that it was significantly s
Andres Freund writes:
> On 2018-09-26 15:04:20 -0700, Andres Freund wrote:
>> I assume this partially is just the additional layers of function calls
>> (psprintf, pvsnprintf, pg_vsnprintf, dopr) that are now done, in
>> addition to pretty much the same work as before (i.e. sprintf("%.*f")).
No,
Andres Freund writes:
> I kinda wonder if we shouldn't replace the non pg_* functions in
> snprintf.c with a more modern copy of a compatibly licensed libc. Looks
> to me like our implementation has forked off some BSD a fair while ago.
Maybe, but the benchmarking I was doing last month didn't co
On 2018-09-26 19:45:07 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-09-26 15:04:20 -0700, Andres Freund wrote:
> >> I assume this partially is just the additional layers of function calls
> >> (psprintf, pvsnprintf, pg_vsnprintf, dopr) that are now done, in
> >> addition to pretty mu
Andres Freund 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 arc
On 2018-09-26 20:25:44 -0400, Tom Lane wrote:
> Andres Freund 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 th
On 2018-09-26 17:40:22 -0700, Andres Freund wrote:
> On 2018-09-26 20:25:44 -0400, Tom Lane wrote:
> > Andres Freund 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
Hi,
On 2018-09-26 17:57:05 -0700, Andres Freund wrote:
> snprintf time = 1324.87 ms total, 0.000264975 ms per iteration
> pg time = 1434.57 ms total, 0.000286915 ms per iteration
> stbsp time = 552.14 ms total, 0.000110428 ms per iteration
Reading around the interwebz lead me to look at ryu
http
Here's a rebased version of <15785.1536776...@sss.pgh.pa.us>.
I think we should try to get this reviewed and committed before
we worry more about the float business. It would be silly to
not be benchmarking any bigger changes against the low-hanging
fruit here.
regards, t
Andres Freund writes:
> Reading around the interwebz lead me to look at ryu
> https://dl.acm.org/citation.cfm?id=3192369
> https://github.com/ulfjack/ryu/tree/46f4c5572121a6f1428749fe3e24132c3626c946
> That's an algorithm that always generates the minimally sized
> roundtrip-safe string output f
Hi,
On 2018-09-26 21:30:25 -0400, Tom Lane wrote:
> Here's a rebased version of <15785.1536776...@sss.pgh.pa.us>.
>
> I think we should try to get this reviewed and committed before
> we worry more about the float business. It would be silly to
> not be benchmarking any bigger changes against th
On Thu, Sep 27, 2018 at 1:18 PM Andres Freund wrote:
> On 2018-09-26 17:57:05 -0700, Andres Freund wrote:
> > snprintf time = 1324.87 ms total, 0.000264975 ms per iteration
> > pg time = 1434.57 ms total, 0.000286915 ms per iteration
> > stbsp time = 552.14 ms total, 0.000110428 ms per iteration
>
On 2018-09-26 21:44:41 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Reading around the interwebz lead me to look at ryu
>
> > https://dl.acm.org/citation.cfm?id=3192369
> > https://github.com/ulfjack/ryu/tree/46f4c5572121a6f1428749fe3e24132c3626c946
>
> > That's an algorithm that always ge
Andres Freund writes:
> On 2018-09-26 21:44:41 -0400, Tom Lane wrote:
>> BTW, were you thinking of plugging in strfromd() inside snprintf.c,
>> or just invoking it directly from float[48]out? The latter would
>> presumably be cheaper, and it'd solve the most pressing performance
>> problem, if no
> "Andres" == Andres Freund writes:
Andres> Hm, stb's results just for floating point isn't bad. The above
Andres> numbers were for %f %f. But as the minimal usage would be about
Andres> the internal usage of dopr(), here's comparing %.*f:
Andres> snprintf time = 1324.87 ms total, 0.0002
On Thu, Sep 27, 2018 at 3:55 PM Andrew Gierth
wrote:
> > "Andres" == Andres Freund writes:
> Andres> Hm, stb's results just for floating point isn't bad. The above
> Andres> numbers were for %f %f. But as the minimal usage would be about
> Andres> the internal usage of dopr(), here's compa
On September 26, 2018 8:53:27 PM PDT, Andrew Gierth
wrote:
>> "Andres" == Andres Freund writes:
>
> Andres> Hm, stb's results just for floating point isn't bad. The above
>Andres> numbers were for %f %f. But as the minimal usage would be about
> Andres> the internal usage of dopr(), here'
On September 26, 2018 9:04:08 PM PDT, Thomas Munro
wrote:
>On Thu, Sep 27, 2018 at 3:55 PM Andrew Gierth
> wrote:
>> > "Andres" == Andres Freund writes:
>> Andres> Hm, stb's results just for floating point isn't bad. The
>above
>> Andres> numbers were for %f %f. But as the minimal usage
Hi,
On 2018-09-26 21:30:25 -0400, Tom Lane wrote:
> Here's a rebased version of <15785.1536776...@sss.pgh.pa.us>.
>
> I think we should try to get this reviewed and committed before
> we worry more about the float business. It would be silly to
> not be benchmarking any bigger changes against th
Here's a version of this patch rebased over commit 625b38ea0.
That commit's fix for the possibly-expensive memset means that we need
to reconsider performance numbers for this patch. I re-ran my previous
tests, and it's still looking like this is a substantial win, as it makes
snprintf.c faster t
Andres Freund writes:
> I've looked through the patch. Looks good to me. Some minor notes:
[ didn't see this till after sending my previous ]
> - How about adding our own strchrnul for the case where we don't
> HAVE_STRCHRNUL? It's possible that other platforms have something
> similar, and
On 2018-10-02 17:54:31 -0400, Tom Lane wrote:
> Here's a version of this patch rebased over commit 625b38ea0.
>
> That commit's fix for the possibly-expensive memset means that we need
> to reconsider performance numbers for this patch. I re-ran my previous
> tests, and it's still looking like th
Andres Freund writes:
> On 2018-10-02 17:54:31 -0400, Tom Lane wrote:
>> Here's a version of this patch rebased over commit 625b38ea0.
> Cool. Let's get that in...
Cool, I'll push it shortly.
>> While there might be value in implementing our own float printing code,
>> I have a pretty hard tim
Hi,
On 2018-10-03 08:20:14 -0400, Tom Lane wrote:
> Andres Freund writes:
> >> While there might be value in implementing our own float printing code,
> >> I have a pretty hard time getting excited about the cost/benefit ratio
> >> of that. I think that what we probably really ought to do here i
I wrote:
> ... However, I did add recent glibc (Fedora 28)
> to the mix, and I was interested to discover that they seem to have
> added a fast-path for format strings that are exactly "%s", just as
> NetBSD did. I wonder if we should reconsider our position on doing
> that. It'd be a simple enou
Andres Freund writes:
> FWIW, it seems that using a local buffer and than pstrdup'ing that in
> float8out_internal is a bit faster, and would probably save a bit of
> memory on average:
> float8out using sprintf via pg_double_to_string, pstrdup:
> 15370.774
> float8out using strfromd via pg_double
Hi,
On 2018-10-03 12:07:32 -0400, Tom Lane wrote:
> Andres Freund writes:
> > FWIW, it seems that using a local buffer and than pstrdup'ing that in
> > float8out_internal is a bit faster, and would probably save a bit of
> > memory on average:
> > float8out using sprintf via pg_double_to_string,
Andres Freund writes:
> On 2018-10-03 12:07:32 -0400, Tom Lane wrote:
>> [ scratches head ... ] How would that work? Seems like it necessarily
>> adds a strlen() call to whatever we'd be doing otherwise. palloc isn't
>> going to be any faster just from asking it for slightly fewer bytes.
>> I t
Hi,
On 2018-10-03 11:59:27 -0400, Tom Lane wrote:
> I wrote:
> > ... However, I did add recent glibc (Fedora 28)
> > to the mix, and I was interested to discover that they seem to have
> > added a fast-path for format strings that are exactly "%s", just as
> > NetBSD did. I wonder if we should re
Hi,
On 2018-10-03 12:22:13 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-10-03 12:07:32 -0400, Tom Lane wrote:
> >> [ scratches head ... ] How would that work? Seems like it necessarily
> >> adds a strlen() call to whatever we'd be doing otherwise. palloc isn't
> >> going to be an
Andres Freund writes:
> On 2018-10-03 11:59:27 -0400, Tom Lane wrote:
>> I experimented with adding an initial check for "format is exactly %s"
>> at the top of dopr(), and couldn't get excited about that. Instrumenting
>> things showed that the optimization fired in only 1.8% of the calls
>> dur
Andres Freund writes:
> It seems the general "use strfromd if available" approach is generally
> useful, even if we need to serialize the precision.
Agreed.
> Putting it into an
> inline appears to be helpful, avoids some of the otherwise precision
> related branches. Do you have any feelings a
Hi,
On 2018-10-03 12:54:52 -0400, Tom Lane wrote:
> Andres Freund writes:
> > It seems the general "use strfromd if available" approach is generally
> > useful, even if we need to serialize the precision.
>
> Agreed.
>
> > Putting it into an
> > inline appears to be helpful, avoids some of the
I wrote:
> Andres Freund writes:
>> - I know it's not new, but is it actually correct to use va_arg(args, int64)
>> for ATYPE_LONGLONG?
> Well, the problem with just doing s/int64/long long/g is that the
> code would then fail on compilers without a "long long" type.
> We could ifdef our way arou
Andres Freund writes:
> On 2018-10-03 12:54:52 -0400, Tom Lane wrote:
>> (1) The need to use sprintf for portability means that we need very
>> tight constraints on the precision spec *and* the buffer size *and*
>> the format type (%f pretty much destroys certainty about how long the
>> output str
Hi,
On 2018-10-03 13:31:09 -0400, Tom Lane wrote:
> I do not see the point of messing with snprintf.c here. I doubt that
> strfromd is faster than the existing sprintf call (because the latter
> can use ".*" instead of serializing and deserializing the precision).
I'm confused, the numbers I pos
Hi,
On 2018-10-03 13:18:35 -0400, Tom Lane wrote:
> I wrote:
> > Andres Freund writes:
> >> - I know it's not new, but is it actually correct to use va_arg(args,
> >> int64)
> >> for ATYPE_LONGLONG?
>
> > Well, the problem with just doing s/int64/long long/g is that the
> > code would then fail
Andres Freund writes:
> On 2018-10-03 13:31:09 -0400, Tom Lane wrote:
>> I do not see the point of messing with snprintf.c here. I doubt that
>> strfromd is faster than the existing sprintf call (because the latter
>> can use ".*" instead of serializing and deserializing the precision).
> I'm co
On 2018-10-03 13:40:03 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-10-03 13:31:09 -0400, Tom Lane wrote:
> >> I do not see the point of messing with snprintf.c here. I doubt that
> >> strfromd is faster than the existing sprintf call (because the latter
> >> can use ".*" instead of
Andres Freund writes:
> On 2018-10-03 13:18:35 -0400, Tom Lane wrote:
>> Having said that, maybe there's a case for changing the type spec
>> in only the va_arg() call, and leaving snprintf's related local
>> variables as int64. (Is that what you actually meant?) Then,
>> if long long really is
Andres Freund writes:
> So when using pg's snprintf() to print a single floating point number
> with precision, we get nearly a 10% boost.
I just tested that using my little standalone testbed, and I failed
to replicate the result. I do see that strfromd is slightly faster,
but it's just a few p
On 2018-Oct-03, Tom Lane wrote:
> Andres Freund writes:
> BTW, so far as I can tell on F28, strfromd isn't exposed without
> "-D__STDC_WANT_IEC_60559_BFP_EXT__", which seems fairly scary;
> what else does that affect?
https://en.cppreference.com/w/c/experimental/fpext1
--
Álvaro Herrera
Hi,
On 2018-10-03 14:01:35 -0400, Tom Lane wrote:
> Andres Freund writes:
> > So when using pg's snprintf() to print a single floating point number
> > with precision, we get nearly a 10% boost.
>
> I just tested that using my little standalone testbed, and I failed
> to replicate the result. I
I wrote:
>> Hm. I guess that'd be a bit better, but I'm not sure it's worth it. How
>> about we simply add a static assert that long long isn't bigger than
>> int64?
> WFM, I'll make it happen.
Actually, while writing a comment to go with that assertion, I decided
this was dumb. If we're expecti
Andres Freund writes:
> On 2018-10-03 14:01:35 -0400, Tom Lane wrote:
>> BTW, so far as I can tell on F28, strfromd isn't exposed without
>> "-D__STDC_WANT_IEC_60559_BFP_EXT__", which seems fairly scary;
>> what else does that affect?
> So I don't think anything's needed to enable that in pg, giv
Andres Freund writes:
> [ let's use strfromd ]
So I'm having second thoughts about this, based on the fact that
strfromd() in't strictly a glibc-ism but is defined in an ISO/IEC
standard. That means that we can expect to see it start showing up
on other platforms (though a quick search did not f
Hi,
On 2018-10-05 11:54:59 -0400, Tom Lane wrote:
> Andres Freund writes:
> > [ let's use strfromd ]
>
> So I'm having second thoughts about this, based on the fact that
> strfromd() in't strictly a glibc-ism but is defined in an ISO/IEC
> standard. That means that we can expect to see it start
Andres Freund writes:
> On 2018-10-05 11:54:59 -0400, Tom Lane wrote:
>> I really think that what we ought to do is apply the float[48]out hack
>> I showed in <30551.1538517...@sss.pgh.pa.us> and call it good, at least
>> till such time as somebody wants to propose a full-on reimplementation of
>>
I stepped back a bit from the raw performance question and thought about
what we actually want functionally in snprintf's float handling. There
are a couple of points worth making:
* The fact that float[48]out explicitly handle NaN and Inf cases is a
leftover from when they had to cope with varyi
> "Andres" == Andres Freund writes:
Andres> I'm not convinced. Because of some hypothetical platform that
Andres> may introduce strfromd() in a broken/slower manner, but where
Andres> sprintf() is correct, we should not do the minimal work to
Andres> alleviate an actual performance bottle
Andrew Gierth writes:
> So here's a thing: I finally got to doing my performance tests for using
> the Ryu float output code in float[48]out.
> Ryu is so blazing fast that with it, COPY of a table with 2million rows
> of 12 random float8 columns (plus id) becomes FASTER in text mode than
> in bina
> "Tom" == Tom Lane writes:
>> Ryu is so blazing fast that with it, COPY of a table with 2million
>> rows of 12 random float8 columns (plus id) becomes FASTER in text
>> mode than in binary mode (rather than ~5x slower):
Tom> Oh yeah? Where's the code for this?
Upstream code is at http
Andrew Gierth 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 floa
> "Tom" == Tom Lane writes:
Tom> Thanks. Just scanning through the code quickly, I note that it
Tom> assumes IEEE float format, which is probably okay but I suppose we
Tom> might want a configure switch to disable it (and revert to
Tom> platform sprintf).
Yeah, but even s390 these days s
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Yeah, one would hope. But I wonder whether it always produces the
> Tom> same low-order digits, and if not, whether people will complain.
> It won't produce the same low-order digits in general, since it has a
> different objective: rath
> "Tom" == Tom Lane writes:
Tom> Now, "shortest value that converts back exactly" is technically
Tom> cool, but I am not sure that it solves any real-world problem that
Tom> we have.
Well, it seems to me that it is perfect for pg_dump.
Also it's kind of a problem that our default float o
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Now, "shortest value that converts back exactly" is technically
> Tom> cool, but I am not sure that it solves any real-world problem that
> Tom> we have.
> Well, it seems to me that it is perfect for pg_dump.
Perhaps. I was hoping for
> "Tom" == Tom Lane writes:
Tom> However, it seems like it should still be on the table to look at
Tom> other code that just does sprintf's job faster (such as the stb
Tom> code Alexander mentioned).
The stb sprintf is indeed a lot faster for floats than other sprintfs,
but (a) it's still
Hi,
On 2018-10-07 12:59:18 +0100, Andrew Gierth wrote:
> > "Tom" == Tom Lane writes:
>
> Tom> Now, "shortest value that converts back exactly" is technically
> Tom> cool, but I am not sure that it solves any real-world problem that
> Tom> we have.
>
> Well, it seems to me that it is perf
I wrote:
> [ snprintf-speedups-1.patch ]
Here's a slightly improved version of that, with two changes:
* Given the current state of the what-about-%m thread, it's no longer
academic how well this performs relative to glibc's version. I poked
at that and found that a lot of the discrepancy came f
I benchmarked this, using your testbed and comparing to libc sprintf
(Ubuntu GLIBC 2.27-0ubuntu3) and another implementation I know [1], all
compiled with gcc 5.4.0 with -O2. I used bigger decimals in one of the
formats, but otherwise they are the same as yours. Here is the table of
conversion
Alexander Kuzmenkov writes:
> I benchmarked this, using your testbed and comparing to libc sprintf
> (Ubuntu GLIBC 2.27-0ubuntu3) and another implementation I know [1], all
> compiled with gcc 5.
Thanks for reviewing!
The cfbot noticed that the recent dlopen patch conflicted with this in
confi
I wrote:
> [ snprintf-speedups-1.patch ]
Here's a slightly improved version of that, with two changes:
* Given the current state of the what-about-%m thread, it's no longer
academic how well this performs relative to glibc's version. I poked
at that and found that a lot of the discrepancy came f
I benchmarked this, using your testbed and comparing to libc sprintf
(Ubuntu GLIBC 2.27-0ubuntu3) and another implementation I know [1], all
compiled with gcc 5.4.0 with -O2. I used bigger decimals in one of the
formats, but otherwise they are the same as yours. Here is the table of
conversion
Alexander Kuzmenkov writes:
> I benchmarked this, using your testbed and comparing to libc sprintf
> (Ubuntu GLIBC 2.27-0ubuntu3) and another implementation I know [1], all
> compiled with gcc 5.
Thanks for reviewing!
The cfbot noticed that the recent dlopen patch conflicted with this in
confi
On 2018-09-12 14:14:15 -0400, Tom Lane wrote:
> Alexander Kuzmenkov writes:
> > I benchmarked this, using your testbed and comparing to libc sprintf
> > (Ubuntu GLIBC 2.27-0ubuntu3) and another implementation I know [1], all
> > compiled with gcc 5.
>
> Thanks for reviewing!
>
> The cfbot noticed
On 2018-09-26 15:04:20 -0700, Andres Freund wrote:
> On 2018-09-12 14:14:15 -0400, Tom Lane wrote:
> > Alexander Kuzmenkov writes:
> > > I benchmarked this, using your testbed and comparing to libc sprintf
> > > (Ubuntu GLIBC 2.27-0ubuntu3) and another implementation I know [1], all
> > > compiled
On 2018-08-17 14:32:59 -0400, Tom Lane wrote:
> I've been looking into the possible performance consequences of that,
> in particular comparing snprintf.c to the library versions on macOS,
> FreeBSD, OpenBSD, and NetBSD. While it held up well in simpler cases,
> I noted that it was significantly s
Andres Freund writes:
> On 2018-09-26 15:04:20 -0700, Andres Freund wrote:
>> I assume this partially is just the additional layers of function calls
>> (psprintf, pvsnprintf, pg_vsnprintf, dopr) that are now done, in
>> addition to pretty much the same work as before (i.e. sprintf("%.*f")).
No,
Andres Freund writes:
> I kinda wonder if we shouldn't replace the non pg_* functions in
> snprintf.c with a more modern copy of a compatibly licensed libc. Looks
> to me like our implementation has forked off some BSD a fair while ago.
Maybe, but the benchmarking I was doing last month didn't co
On 2018-09-26 19:45:07 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-09-26 15:04:20 -0700, Andres Freund wrote:
> >> I assume this partially is just the additional layers of function calls
> >> (psprintf, pvsnprintf, pg_vsnprintf, dopr) that are now done, in
> >> addition to pretty mu
Andres Freund 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 arc
On 2018-09-26 20:25:44 -0400, Tom Lane wrote:
> Andres Freund 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 th
On 2018-09-26 17:40:22 -0700, Andres Freund wrote:
> On 2018-09-26 20:25:44 -0400, Tom Lane wrote:
> > Andres Freund 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
Hi,
On 2018-09-26 17:57:05 -0700, Andres Freund wrote:
> snprintf time = 1324.87 ms total, 0.000264975 ms per iteration
> pg time = 1434.57 ms total, 0.000286915 ms per iteration
> stbsp time = 552.14 ms total, 0.000110428 ms per iteration
Reading around the interwebz lead me to look at ryu
http
Here's a rebased version of <15785.1536776...@sss.pgh.pa.us>.
I think we should try to get this reviewed and committed before
we worry more about the float business. It would be silly to
not be benchmarking any bigger changes against the low-hanging
fruit here.
regards, t
Andres Freund writes:
> Reading around the interwebz lead me to look at ryu
> https://dl.acm.org/citation.cfm?id=3192369
> https://github.com/ulfjack/ryu/tree/46f4c5572121a6f1428749fe3e24132c3626c946
> That's an algorithm that always generates the minimally sized
> roundtrip-safe string output f
Hi,
On 2018-09-26 21:30:25 -0400, Tom Lane wrote:
> Here's a rebased version of <15785.1536776...@sss.pgh.pa.us>.
>
> I think we should try to get this reviewed and committed before
> we worry more about the float business. It would be silly to
> not be benchmarking any bigger changes against th
On Thu, Sep 27, 2018 at 1:18 PM Andres Freund wrote:
> On 2018-09-26 17:57:05 -0700, Andres Freund wrote:
> > snprintf time = 1324.87 ms total, 0.000264975 ms per iteration
> > pg time = 1434.57 ms total, 0.000286915 ms per iteration
> > stbsp time = 552.14 ms total, 0.000110428 ms per iteration
>
On 2018-09-26 21:44:41 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Reading around the interwebz lead me to look at ryu
>
> > https://dl.acm.org/citation.cfm?id=3192369
> > https://github.com/ulfjack/ryu/tree/46f4c5572121a6f1428749fe3e24132c3626c946
>
> > That's an algorithm that always ge
Andres Freund writes:
> On 2018-09-26 21:44:41 -0400, Tom Lane wrote:
>> BTW, were you thinking of plugging in strfromd() inside snprintf.c,
>> or just invoking it directly from float[48]out? The latter would
>> presumably be cheaper, and it'd solve the most pressing performance
>> problem, if no
> "Andres" == Andres Freund writes:
Andres> Hm, stb's results just for floating point isn't bad. The above
Andres> numbers were for %f %f. But as the minimal usage would be about
Andres> the internal usage of dopr(), here's comparing %.*f:
Andres> snprintf time = 1324.87 ms total, 0.0002
On Thu, Sep 27, 2018 at 3:55 PM Andrew Gierth
wrote:
> > "Andres" == Andres Freund writes:
> Andres> Hm, stb's results just for floating point isn't bad. The above
> Andres> numbers were for %f %f. But as the minimal usage would be about
> Andres> the internal usage of dopr(), here's compa
On September 26, 2018 8:53:27 PM PDT, Andrew Gierth
wrote:
>> "Andres" == Andres Freund writes:
>
> Andres> Hm, stb's results just for floating point isn't bad. The above
>Andres> numbers were for %f %f. But as the minimal usage would be about
> Andres> the internal usage of dopr(), here'
On September 26, 2018 9:04:08 PM PDT, Thomas Munro
wrote:
>On Thu, Sep 27, 2018 at 3:55 PM Andrew Gierth
> wrote:
>> > "Andres" == Andres Freund writes:
>> Andres> Hm, stb's results just for floating point isn't bad. The
>above
>> Andres> numbers were for %f %f. But as the minimal usage
Hi,
On 2018-09-26 21:30:25 -0400, Tom Lane wrote:
> Here's a rebased version of <15785.1536776...@sss.pgh.pa.us>.
>
> I think we should try to get this reviewed and committed before
> we worry more about the float business. It would be silly to
> not be benchmarking any bigger changes against th
Here's a version of this patch rebased over commit 625b38ea0.
That commit's fix for the possibly-expensive memset means that we need
to reconsider performance numbers for this patch. I re-ran my previous
tests, and it's still looking like this is a substantial win, as it makes
snprintf.c faster t
Andres Freund writes:
> I've looked through the patch. Looks good to me. Some minor notes:
[ didn't see this till after sending my previous ]
> - How about adding our own strchrnul for the case where we don't
> HAVE_STRCHRNUL? It's possible that other platforms have something
> similar, and
On 2018-10-02 17:54:31 -0400, Tom Lane wrote:
> Here's a version of this patch rebased over commit 625b38ea0.
>
> That commit's fix for the possibly-expensive memset means that we need
> to reconsider performance numbers for this patch. I re-ran my previous
> tests, and it's still looking like th
Andres Freund writes:
> On 2018-10-02 17:54:31 -0400, Tom Lane wrote:
>> Here's a version of this patch rebased over commit 625b38ea0.
> Cool. Let's get that in...
Cool, I'll push it shortly.
>> While there might be value in implementing our own float printing code,
>> I have a pretty hard tim
Hi,
On 2018-10-03 08:20:14 -0400, Tom Lane wrote:
> Andres Freund writes:
> >> While there might be value in implementing our own float printing code,
> >> I have a pretty hard time getting excited about the cost/benefit ratio
> >> of that. I think that what we probably really ought to do here i
I wrote:
> ... However, I did add recent glibc (Fedora 28)
> to the mix, and I was interested to discover that they seem to have
> added a fast-path for format strings that are exactly "%s", just as
> NetBSD did. I wonder if we should reconsider our position on doing
> that. It'd be a simple enou
Andres Freund writes:
> FWIW, it seems that using a local buffer and than pstrdup'ing that in
> float8out_internal is a bit faster, and would probably save a bit of
> memory on average:
> float8out using sprintf via pg_double_to_string, pstrdup:
> 15370.774
> float8out using strfromd via pg_double
Hi,
On 2018-10-03 12:07:32 -0400, Tom Lane wrote:
> Andres Freund writes:
> > FWIW, it seems that using a local buffer and than pstrdup'ing that in
> > float8out_internal is a bit faster, and would probably save a bit of
> > memory on average:
> > float8out using sprintf via pg_double_to_string,
Andres Freund writes:
> On 2018-10-03 12:07:32 -0400, Tom Lane wrote:
>> [ scratches head ... ] How would that work? Seems like it necessarily
>> adds a strlen() call to whatever we'd be doing otherwise. palloc isn't
>> going to be any faster just from asking it for slightly fewer bytes.
>> I t
Hi,
On 2018-10-03 11:59:27 -0400, Tom Lane wrote:
> I wrote:
> > ... However, I did add recent glibc (Fedora 28)
> > to the mix, and I was interested to discover that they seem to have
> > added a fast-path for format strings that are exactly "%s", just as
> > NetBSD did. I wonder if we should re
1 - 100 of 130 matches
Mail list logo
