Re: Auto-vectorization speeds up multiplication of large-precision numerics

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Auto-vectorization speeds up multiplication of large-precision numerics
Date: 2020-07-10 13:05:15
Message-ID: 77576efa-2e30-746e-8707-d029f88f69bb@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-06-10 14:15, Amit Khandekar wrote:
>> Well, how do we make sure we keep it that way? How do we prevent some
>> random rearranging of the code or some random compiler change to break
>> this again?
> I believe the compiler rearranges the code segments w.r.t. one another
> when those are independent of each other. I guess the compiler is able
> to identify that. With our case, it's the for loop. There are some
> variables used inside it, and that would prevent it from moving the
> for loop. Even if the compiler finds it safe to move relative to
> surrounding code, it would not spilt the for loop contents themselves,
> so the for loop will remain intact, and so would the vectorization,
> although it seems to keep an unrolled version of the loop in case it
> is called with smaller iteration counts. But yes, if someone in the
> future tries to change the for loop, it would possibly break the
> auto-vectorization. So, we should have appropriate comments (patch has
> those). Let me know if you find any possible reasons due to which the
> compiler would in the future stop the vectorization even when there is
> no change in the for loop.

We normally don't compile with -O3, so very few users would get the
benefit of this. We have CFLAGS_VECTOR for the checksum code. I
suppose if we are making the numeric code vectorizable as well, we
should apply this there also.

I think we need a bit of a policy decision from the group here.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2020-07-10 13:30:07 Re: Default gucs for EXPLAIN
Previous Message Tomas Vondra 2020-07-10 12:09:14 Re: WIP: BRIN multi-range indexes