Re: Auto-vectorization speeds up multiplication of large-precisionnumerics

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Auto-vectorization speeds up multiplication of large-precisionnumerics
Дата
Msg-id 2b619caf-7f88-fb4c-43ff-ef337d667ff3@2ndquadrant.com
обсуждение исходный текст
Ответ на Auto-vectorization speeds up multiplication of large-precision numerics  (Amit Khandekar <amitdkhan.pg@gmail.com>)
Ответы Re: Auto-vectorization speeds up multiplication of large-precision numerics  (Amit Khandekar <amitdkhan.pg@gmail.com>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: proposal: possibility to read dumped table's name from file
Следующее
От: Andres Freund
Дата:
Сообщение: Re: global barrier & atomics in signal handlers (Re: Atomicoperations within spinlocks)