| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Auto-vectorization speeds up multiplication of large-precision numerics |
| Date: | 2020-06-09 22:50:26 |
| Message-ID: | 2b619caf-7f88-fb4c-43ff-ef337d667ff3@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2020-06-09 13:50, Amit Khandekar wrote:
> Also, the regress/sql/numeric_big test itself speeds up by 80%
That's nice. I can confirm the speedup:
-O3 without the patch:
numeric ... ok 737 ms
test numeric_big ... ok 1014 ms
-O3 with the patch:
numeric ... ok 680 ms
test numeric_big ... ok 580 ms
Also:
-O2 without the patch:
numeric ... ok 693 ms
test numeric_big ... ok 1160 ms
-O2 with the patch:
numeric ... ok 677 ms
test numeric_big ... ok 917 ms
So the patch helps either way. But it also seems that without the
patch, -O3 might be a bit slower in some cases. This might need more
testing.
> For the for loop to be auto-vectorized, I had to simplify it to
> something like this :
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?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2020-06-09 22:54:08 | Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks) |
| Previous Message | Justin Pryzby | 2020-06-09 22:30:42 | Re: proposal: possibility to read dumped table's name from file |