From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Mats Kindahl <mats(at)timescale(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: glibc qsort() vulnerability |
Date: | 2024-02-09 18:40:14 |
Message-ID: | 20240209184014.sobshkcsfjix6u4r@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2024-02-09 18:50:53 | Re: POC: Extension for adding distributed tracing - pg_tracing |
Previous Message | Andres Freund | 2024-02-09 18:34:50 | Re: Popcount optimization using AVX512 |