New expression evaluator and indirect jumps

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: New expression evaluator and indirect jumps
Date: 2017-04-02 00:36:42
Message-ID: CAMp0ubcPXTq84GSw=f5xx+ZLGYDozbTXY0_JprummL6tKyV-Pw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres,

Thank you for your great work on the expression evaluator:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b8d7f053c5c2bf2a7e8734fe3327f6a8bc711755

I was looking at the dispatch code, and it goes to significant effort
(using computed goto) to generate many indirect jumps instead of just
one. The reasoning is that CPUs can do better branch prediction when
it can predict separately for each of the indirect jumps.

But the paper here: https://hal.inria.fr/hal-01100647/document claims
that it's not really needed on newer CPUs because they are better at
branch prediction. I skimmed it, and if I understand correctly, modern
branch predictors use some history, so it can predict based on the
instructions executed before it got to the indirect jump.

I tried looking through the discussion on this list, but most seemed
to resolve around which compilers generated the assembly we wanted
rather than how much it actually improved performance. Can someone
please point me to the numbers? Do they refute the conclusions in the
paper, or are we concerned about a wider range of processors?

Regards,
Jeff Davis

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-04-02 00:54:45 Re: New expression evaluator and indirect jumps
Previous Message Ashutosh Sharma 2017-04-01 22:44:41 Re: Page Scan Mode in Hash Index