| От | Nathan Bossart |
|---|---|
| Тема | Re: [PATCH] Hex-coding optimizations using SVE on ARM. |
| Дата | |
| Msg-id | aMLpq9_wOz_tnHmm@nathan обсуждение исходный текст |
| Ответ на | Re: [PATCH] Hex-coding optimizations using SVE on ARM. ("Chiranmoy.Bhattacharya@fujitsu.com" <Chiranmoy.Bhattacharya@fujitsu.com>) |
| Ответы |
Re: [PATCH] Hex-coding optimizations using SVE on ARM.
|
| Список | pgsql-hackers |
On Thu, Sep 11, 2025 at 10:43:56AM +0000, Chiranmoy.Bhattacharya@fujitsu.com wrote: > One possible improvement would be to use a vectorized table lookup > instead of compare and add. I compared v6 and v7 Neon versions, and v6 is > always faster. I’m not sure if SSE2 has a table lookup similar to Neon. I'm not finding a simple way to do that kind of table lookup in SSE2. Part of the reason v6 performs better is because you've unrolled the loop to process 2 vector's worth of input data in each iteration. This trades performance with smaller inputs for gains with larger ones. But even if I do something similar for v7, v6 still wins most of the time. My current philosophy with this stuff is to favor simplicity, maintainability, portability, etc. over extracting the absolute maximum amount of performance gain, so I think we should proceed with the simd.h approach. But I'm curious how others feel about this. v8 is an attempt to fix the casting error on MSVC. -- nathan
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера