On 27/01/15 00:51, Andres Freund wrote:
On 2015-01-26 15:35:44 -0800, Peter Geoghegan wrote:
On Mon, Jan 26, 2015 at 3:12 PM, Andrew Gierth
<and...@tao11.riddles.org.uk> wrote:
Obvious overheads in float8 comparison include having to check for NaN,
and the fact that DatumGetFloat8 on 64bit doesn't get inlined and forces
a store/load to memory rather than just using a register. Looking at
those might be more beneficial than messing with abbreviations.
Aren't there issues with the alignment of double precision floating
point numbers on x86, too? Maybe my information there is at least
partially obsolete. But it seems we'd have to control for this to be
sure.
I think getting rid of the function call for DatumGetFloat8() would be
quite the win. On x86-64 the conversion then should amount to mov
%rd?,-0x8(%rsp);movsd -0x8(%rsp),%xmm0 - that's pretty cheap. Both
instructions have a cycle count of 1 + L1 access latency (4) + 2 because
they use the same exection port. So it's about 12 fully pipelineable
cycles. 2 if the pipeline can kept busy otherwise. I doubt that'd be
noticeable if the conversion were inlined.
IIRC the DatumGetFloat8 was quite visible in the perf when I was writing
the array version of width_bucket. It was one of the motivations for
making special float8 version since not having to call it had
significant effect. Sadly I don't remember if it was the function call
itself or the conversion anymore.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
