Re: glibc qsort() vulnerability

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: glibc qsort() vulnerability
Дата
Msg-id 20240209184014.sobshkcsfjix6u4r@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: glibc qsort() vulnerability  ("Andrey M. Borodin" <x4mmm@yandex-team.ru>)
Список pgsql-hackers
Hi,

On 2024-02-09 13:19:49 +0500, Andrey M. Borodin wrote:
> > On 8 Feb 2024, at 06:52, Nathan Bossart <nathandbossart@gmail.com> wrote:
> > For the same compASC() test, I see an ~8.4% improvement with your int64
> > code and a ~3.4% improvement with this:
>
> If we care about branch prediction in comparison function, maybe we could
> produce sorting that inlines comparator, thus eliminating function call to
> comparator? We convert comparison logic to int, to extract comparison back
> then.

We have some infrastructure for that actually, see sort_template.h.  But
perhaps we should define a static inline of the generic pg_qsort() even. OTOH,
plenty places that'll just end up to a pointless amount of code emitted to
sort ~5 elements on average.


> I bet “call" is more expensive than “if".

Not really in this case. The call is perfectly predictable - a single qsort()
will use the same callback for every comparison, whereas the if is perfectly
*unpredictable*.  A branch mispredict is far more expensive than a correctly
predicted function call.

Greetings,

Andres



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Popcount optimization using AVX512
Следующее
От: Andres Freund
Дата:
Сообщение: Re: POC: Extension for adding distributed tracing - pg_tracing