From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Heikki Linnakangas <hlinnaka@iki.fi>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        pgsql-hackers@postgresql.org
Subject: Re: WIP: Faster Expression Processing v4
In-reply-to: <13918.1490410879@sss.pgh.pa.us>
References: <28270.1490289299@sss.pgh.pa.us>
 <20170323174004.a2ez7kygx5ngqxlp@alap3.anarazel.de>
 <8011.1490305255@sss.pgh.pa.us> <26088.1490315792@sss.pgh.pa.us>
 <20170324004734.3a2dokbfofiz6ylu@alap3.anarazel.de>
 <30270.1490318779@sss.pgh.pa.us>
 <20170324013412.qy7ltnnqv5m7qiuc@alap3.anarazel.de>
 <31825.1490320683@sss.pgh.pa.us>
 <20170324020003.4rt63xty7xpb4akq@alap3.anarazel.de>
 <22215.1490369187@sss.pgh.pa.us>
 <20170324182742.3r4qndpugtx6ga3t@alap3.anarazel.de>
 <22833.1490390175@sss.pgh.pa.us> <13918.1490410879@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Fri, 24 Mar 2017 23:01:19 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5767.1490458935.1@sss.pgh.pa.us>
Date: Sat, 25 Mar 2017 12:22:15 -0400
Message-ID: <5768.1490458935@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

More random musing ... have you considered making the jump-target fields
in expressions be relative rather than absolute indexes?  That is,
EEO_JUMP would look like

		op += (stepno); \
		EEO_DISPATCH(); \

instead of

		op = &state->steps[stepno]; \
		EEO_DISPATCH(); \

I have not carried out a full patch to make this work, but just making
that one change and examining the generated assembly code looks promising.
Instead of this

	movslq	40(%r14), %r8
	salq	$6, %r8
	addq	24(%rbx), %r8
	movq	%r8, %r14
	jmp	*(%r8)

we get this

	movslq	40(%r14), %rax
	salq	$6, %rax
	addq	%rax, %r14
	jmp	*(%r14)

which certainly looks like it ought to be faster.  Also, the real reason
I got interested in this at all is that with relative jumps, groups of
steps would be position-independent within the steps array, which would
enable some compile-time tricks that seem impractical with the current
definition.

BTW, now that I've spent a bit of time looking at the generated assembly
code, I'm kind of disinclined to believe any arguments about how we have
better control over branch prediction with the jump-threading
implementation.  At least with current gcc (6.3.1 on Fedora 25) at -O2,
what I see is multiple places jumping to the same indirect jump
instruction :-(.  It's not a total disaster: as best I can tell, all the
uses of EEO_JUMP remain distinct.  But gcc has chosen to implement about
40 of the 71 uses of EEO_NEXT by jumping to the same couple of
instructions that increment the "op" register and then do an indirect
jump :-(.

So it seems that we're at the mercy of gcc's whims as to which instruction
dispatches will be distinguishable to the hardware; which casts a very
dark shadow over any benchmarking-based arguments that X is better than Y
for branch prediction purposes.  Compiler version differences are likely
to matter a lot more than anything we do.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers