On 2018-09-26 17:40:22 -0700, Andres Freund wrote: > On 2018-09-26 20:25:44 -0400, Tom Lane wrote: > > Andres Freund <and...@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.
Hm, stb's results just for floating point isn't bad. The above numbers were for %f %f. But as the minimal usage would be about the internal usage of dopr(), here's comparing %.*f: 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 Greetings, Andres Freund
