On 2017-03-27 12:18:37 -0400, Tom Lane wrote:
> I wrote:
> > As to the point of whether it actually helps or not ...
> > on gcc 4.4.7 (RHEL 6), it makes things *WORSE*. We go from about half of
> > the dispatches getting routed through a common location, to *all* of them
> > (except one; for some odd reason the first EEO_NEXT in EEOP_NULLIF
> > survives as a separate jump). This seems like a bug, but there it is.
>
> So after a bit of googling, this is a very longstanding complaint:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39284
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
>
> (hm, think I know the second submitter)
I don't think that's precisely the same issue - as long as some of the
goto branches survive, we're not hitting the full brunt of the compgoto
thing. I think we're essentially avoiding some of that because we're
"precomputing" the dispatch_table lookup.
To count the number of jumps I used:
gdb -batch -ex 'disassemble/s ExecInterpExpr' execExprInterp.o|grep jmpq|grep
-v ExecInterpExpr|wc -l
which'll only include indirect jumps (since otherwise jumps will look
like "jmpq 0x35f2 <ExecInterpExpr+2066>")
standard flags -fno-crossjumping
gcc-5 (5.4.1-8): 34 82
gcc-6 (6.3.0-8): 34 82
gcc-7 (7.0.1): 71 108
gcc-snapshot: 72 108
So that doesn't look too bad.
> My feeling at this point is that we might be better off disabling
> the computed-goto case by default. At the very least, we're going
> to need a version check that restricts it to latest gcc.
In my measurements it's still faster in at least gcc-5/6, even without
the option (largely because it avoids array bounds checks on the jump
table built for the switch).
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
