MIME-Version: 1.0
References: 
 <CAEudQApbWon+3Eb9x4WW_D-JkSt2mvfx99dXu9VZ4AeCuTh=fw@mail.gmail.com>
 <CAEudQApEfvhNT1fEPURzVcQH7G0A1ukh_ugoCGaErV6_dbndCQ@mail.gmail.com>
 <CAF+pBj_RS2KErTqQ6ORXjhVzmukG7Ve0wHU1Kq56xjJfFKwVqA@mail.gmail.com>
 <CAEudQAptRymgvmd5hQb2mk-Ft89XcSo_xvC74kv4JBA9v=D4Sg@mail.gmail.com>
 <CAF+pBj-K2bgNQRc9ih01WFmAWUaQtVbS37jLtYdYh5LOwOkF6A@mail.gmail.com>
In-Reply-To: 
 <CAF+pBj-K2bgNQRc9ih01WFmAWUaQtVbS37jLtYdYh5LOwOkF6A@mail.gmail.com>
From: Ranier Vilela <ranier.vf@gmail.com>
Date: Thu, 12 Mar 2026 11:35:04 -0300
Message-ID: 
 <CAEudQApqk6DXWgqSBdHyH7+wSxJuk7D-DwkGODUcGkUWpYu0UA@mail.gmail.com>
Subject: Re: Avoid multiple calls to memcpy (src/backend/access/index/genam.c)
To: Bryan Green <dbryan.green@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/mixed; boundary="000000000000faaf27064cd72c94"
Archived-At: 
 <https://www.postgresql.org/message-id/CAEudQApqk6DXWgqSBdHyH7%2BwSxJuk7D-DwkGODUcGkUWpYu0UA%40mail.gmail.com>
Precedence: bulk

--000000000000faaf27064cd72c94
Content-Type: multipart/alternative; boundary="000000000000faaf25064cd72c92"

--000000000000faaf25064cd72c92
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi.

Em seg., 9 de mar. de 2026 =C3=A0s 14:02, Bryan Green <dbryan.green@gmail.c=
om>
escreveu:

> I performed a micro-benchmark on my dual epyc (zen 2) server and version =
1
> wins for small values of n.
>
> 20 runs:
>
> n       version       min  median    mean     max  stddev  noise%
> -----------------------------------------------------------------------
> n=3D1     version1     2.440   2.440   2.450   2.550   0.024    4.5%
> n=3D1     version2     4.260   4.280   4.277   4.290   0.007    0.7%
>
> n=3D2     version1     2.740   2.750   2.757   2.880   0.029    5.1%
> n=3D2     version2     3.970   3.980   3.980   4.020   0.010    1.3%
>
> n=3D4     version1     4.580   4.595   4.649   4.910   0.094    7.2%
> n=3D4     version2     5.780   5.815   5.809   5.820   0.013    0.7%
>
> But, micro-benchmarks always make me nervous, so I looked at the actual
> instruction cost for my
> platform given the version 1 and version 2 code.
>
> If we count cpu cycles using the AMD Zen 2 instruction latency/throughput
> tables:  version 1 (loop body)
> has a critical path of ~5-6 cycles per iteration.  version 2 (loop body)
> has ~3-4 cycles per iteration.
>
> The problem for version 2 is that the call to memcpy is ~24-30 cycles due
> to the stub + function call + return
> and branch predictor pressure on first call.  This probably results in
> ~2.5 ns per iteration cost for version 2.
>
> So, no I wouldn't call it an optimization.  But, it will be interesting t=
o
> hear other opinions on this.
>
I made dirty and quick tests with two versions:
gcc 15.2.0
gcc -O2 memcpy1.c -o memcpy1

The first test was with keys 10000000 and 10000000 loops:
version1: on memcpy call
done in 1873 nanoseconds

version2: inlined memcpy
not finish

The second test was with keys 4 and 10000000 loops:
version1: one memcpy call
version2: inlined memcpy call

version1: done in 1519 nanoseconds
version2: done in 104981851 nanoseconds
(1.44692e-05 times faster)

version1: done in 1979 nanoseconds
version2: done in 110568901 nanoseconds
(1.78983e-05 times faster)

version1: done in 1814 nanoseconds
version2: done in 108555484 nanoseconds
(1.67103e-05 times faster)

version1: done in 1631 nanoseconds
version2: done in 109867919 nanoseconds
(1.48451e-05 times faster)

version1: done in 1269 nanoseconds
version2: done in 111639106 nanoseconds
(1.1367e-05 times faster)

Unless I'm doing something wrong, one call memcpy wins!
memcpy1.c attached.

best regards,
Ranier Vilela

--000000000000faaf25064cd72c92
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi.</div><br><div class=3D"gmail_quote gmail_quote_co=
ntainer"><div dir=3D"ltr" class=3D"gmail_attr">Em seg., 9 de mar. de 2026 =
=C3=A0s 14:02, Bryan Green &lt;<a href=3D"mailto:dbryan.green@gmail.com">db=
ryan.green@gmail.com</a>&gt; escreveu:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr">I performed a micro-benchmark on my=
 dual epyc (zen 2) server and version 1 wins for small values of n.<div><br=
></div><div>20 runs:=C2=A0</div><div><br><div>n =C2=A0 =C2=A0 =C2=A0 versio=
n =C2=A0 =C2=A0 =C2=A0 min =C2=A0median =C2=A0 =C2=A0mean =C2=A0 =C2=A0 max=
 =C2=A0stddev =C2=A0noise%<br>---------------------------------------------=
--------------------------<br>n=3D1 =C2=A0 =C2=A0 version1 =C2=A0 =C2=A0 2.=
440 =C2=A0 2.440 =C2=A0 2.450 =C2=A0 2.550 =C2=A0 0.024 =C2=A0 =C2=A04.5%<b=
r>n=3D1 =C2=A0 =C2=A0 version2 =C2=A0 =C2=A0 4.260 =C2=A0 4.280 =C2=A0 4.27=
7 =C2=A0 4.290 =C2=A0 0.007 =C2=A0 =C2=A00.7%<br><br>n=3D2 =C2=A0 =C2=A0 ve=
rsion1 =C2=A0 =C2=A0 2.740 =C2=A0 2.750 =C2=A0 2.757 =C2=A0 2.880 =C2=A0 0.=
029 =C2=A0 =C2=A05.1%<br>n=3D2 =C2=A0 =C2=A0 version2 =C2=A0 =C2=A0 3.970 =
=C2=A0 3.980 =C2=A0 3.980 =C2=A0 4.020 =C2=A0 0.010 =C2=A0 =C2=A01.3%<br><b=
r>n=3D4 =C2=A0 =C2=A0 version1 =C2=A0 =C2=A0 4.580 =C2=A0 4.595 =C2=A0 4.64=
9 =C2=A0 4.910 =C2=A0 0.094 =C2=A0 =C2=A07.2%<br>n=3D4 =C2=A0 =C2=A0 versio=
n2 =C2=A0 =C2=A0 5.780 =C2=A0 5.815 =C2=A0 5.809 =C2=A0 5.820 =C2=A0 0.013 =
=C2=A0 =C2=A00.7%</div><div><br></div><div>But, micro-benchmarks always mak=
e me nervous, so I looked at the actual instruction cost for my=C2=A0</div>=
<div>platform given the version 1 and version 2 code.</div><div><br></div><=
div>If we count cpu cycles using the AMD Zen 2 instruction latency/throughp=
ut tables:=C2=A0 version 1 (loop body)=C2=A0</div><div>has a critical path =
of ~5-6 cycles per iteration.=C2=A0 version 2 (loop body) has ~3-4 cycles p=
er iteration.=C2=A0</div><div><br></div><div>The problem for version 2 is t=
hat the call to memcpy is ~24-30 cycles due to the stub=C2=A0+ function cal=
l=C2=A0+ return</div><div>and branch predictor pressure on first call.=C2=
=A0 This probably results in ~2.5 ns per iteration cost for version 2.</div=
><div><br></div><div>So, no I wouldn&#39;t call it an optimization.=C2=A0 B=
ut, it will be interesting to hear other opinions on this.=C2=A0</div></div=
></div></blockquote><div>I made dirty and quick tests with two versions:</d=
iv><div>gcc 15.2.0</div><div>gcc -O2 memcpy1.c -o memcpy1</div><div><br></d=
iv><div>The first test was with keys=C2=A010000000 and=C2=A010000000 loops:=
</div><div>version1: on memcpy call</div><div>done in 1873 nanoseconds<br><=
br></div><div>version2: inlined memcpy</div><div>not finish</div><div><br><=
/div><div>The second test was with keys 4 and=C2=A010000000 loops:</div><di=
v>version1: one memcpy call</div><div>version2: inlined memcpy call</div><d=
iv><br></div><div>version1: done in 1519 nanoseconds<br>version2: done in 1=
04981851 nanoseconds<br>(1.44692e-05 times faster)</div><div><br>version1: =
done in 1979 nanoseconds<br>version2: done in 110568901 nanoseconds<br>(1.7=
8983e-05 times faster)<br><br></div><div>version1: done in 1814 nanoseconds=
<br>version2: done in 108555484 nanoseconds<br>(1.67103e-05 times faster)<b=
r><br></div><div>version1: done in 1631 nanoseconds<br>version2: done in 10=
9867919 nanoseconds<br>(1.48451e-05 times faster)<br><br>version1: done in =
1269 nanoseconds<br>version2: done in 111639106 nanoseconds<br>(1.1367e-05 =
times faster)<br><br></div><div>Unless I&#39;m doing something wrong, one c=
all memcpy wins!</div><div>memcpy1.c attached.</div><div><br></div><div>bes=
t regards,</div><div>Ranier Vilela</div></div></div>

--000000000000faaf25064cd72c92--

--000000000000faaf27064cd72c94
Content-Type: text/x-csrc; charset="US-ASCII"; name="memcpy1.c"
Content-Disposition: attachment; filename="memcpy1.c"
Content-Transfer-Encoding: base64
Content-ID: <f_mmnkjb540>
X-Attachment-Id: f_mmnkjb540

I2luY2x1ZGUgPHN0ZGxpYi5oPg0KI2luY2x1ZGUgPHN0cmluZy5oPg0KI2luY2x1ZGUgPHN0ZGlu
dC5oPg0KDQojaW5jbHVkZSA8c3RkYm9vbC5oPg0KI2luY2x1ZGUgPHN0ZGRlZi5oPg0KI2luY2x1
ZGUgPHN0ZGlvLmg+DQojaW5jbHVkZSA8dGltZS5oPg0KI2luY2x1ZGUgPGltbWludHJpbi5oPg0K
DQoNCi8qIENsb3NlciBhcHByb3hpbWF0aW9uIG9mIFNjYW5LZXlEYXRhIC0gaGFzIGZ1bmN0aW9u
IHBvaW50ZXIgYW5kIERhdHVtICovDQp0eXBlZGVmIHZvaWQgKCpSZWdQcm9jZWR1cmUpKHZvaWQp
Ow0KdHlwZWRlZiB1aW50cHRyX3QgRGF0dW07DQoNCnR5cGVkZWYgc3RydWN0IFNjYW5LZXlEYXRh
DQp7DQogICAgaW50ICAgICAgICAgc2tfZmxhZ3M7DQogICAgaW50ICAgICAgICAgc2tfYXR0bm87
DQogICAgUmVnUHJvY2VkdXJlIHNrX2Z1bmM7DQogICAgRGF0dW0gICAgICAgc2tfYXJndW1lbnQ7
DQp9IFNjYW5LZXlEYXRhOw0KDQovKiAgKi8NCmNvbnN0IFNjYW5LZXlEYXRhICogdmVyc2lvbjEo
aW50IG4sIGNvbnN0IFNjYW5LZXlEYXRhICAqIGtleSkNCnsNCiAgICBTY2FuS2V5RGF0YSAqaWR4
a2V5ID0gKFNjYW5LZXlEYXRhICopIG1hbGxvYyhuICogc2l6ZW9mKFNjYW5LZXlEYXRhKSk7DQoN
CiAgICBtZW1jcHkoJmlkeGtleSwgJmtleSwgbiAqIHNpemVvZihTY2FuS2V5RGF0YSkpOw0KICAg
IGZvciAoaW50IGkgPSAwOyBpIDwgbjsgaSsrKQ0KICAgIHsNCiAgICAgICAgaWR4a2V5W2ldLnNr
X2F0dG5vID0gaSArIDE7DQogICAgfQ0KDQogICAgcmV0dXJuIGlkeGtleTsNCn0NCg0KLyogKi8N
CmNvbnN0IFNjYW5LZXlEYXRhICogdmVyc2lvbjIoaW50IG4sIGNvbnN0IFNjYW5LZXlEYXRhICpr
ZXkpDQp7DQogICAgU2NhbktleURhdGEgKmlkeGtleSA9IChTY2FuS2V5RGF0YSAqKSBtYWxsb2Mo
biAqIHNpemVvZihTY2FuS2V5RGF0YSkpOw0KDQogICAgZm9yIChpbnQgaSA9IDA7IGkgPCBuOyBp
KyspDQogICAgew0KICAgICAgICBtZW1jcHkoJmlkeGtleVtpXSwgJmtleVtpXSwgc2l6ZW9mKFNj
YW5LZXlEYXRhKSk7DQogICAgICAgIGlkeGtleVtpXS5za19hdHRubyA9IGkgKyAxOw0KICAgIH0N
Cg0KICAgIHJldHVybiBpZHhrZXk7DQp9DQoNCg0KDQoNCiNkZWZpbmUgTkFOT1NFQ19QRVJfU0VD
IDEwMDAwMDAwMDANCg0KLy8gUmV0dXJucyBkaWZmZXJlbmNlIGluIG5hbm9zZWNvbmRzDQppbnQ2
NF90DQpnZXRfY2xvY2tfZGlmZihzdHJ1Y3QgdGltZXNwZWMgKnQxLCBzdHJ1Y3QgdGltZXNwZWMg
KnQyKQ0Kew0KCWludDY0X3QgbmFub3NlYyA9ICh0MS0+dHZfc2VjIC0gdDItPnR2X3NlYykgKiBO
QU5PU0VDX1BFUl9TRUM7DQoJbmFub3NlYyArPSAodDEtPnR2X25zZWMgLSB0Mi0+dHZfbnNlYyk7
DQoNCglyZXR1cm4gbmFub3NlYzsNCn0NCg0KDQoNCg0KLy8jZGVmaW5lIE5LRVlTIDEwMDAwMDAw
IHZlcnNpb24yIGRvZXMgbm90IGZpbmlzaA0KI2RlZmluZSBOS0VZUyA0DQojZGVmaW5lIExPT1BT
IDEwMDAwMDAwDQoNCnZvaWQgdGVzdDEoaW50IG4pDQp7DQoJU2NhbktleURhdGEgKmtleXM7DQoJ
U2NhbktleURhdGEgKmlkeDsNCg0KICAgICAgICBrZXlzID0gKFNjYW5LZXlEYXRhICopIG1hbGxv
YyhOS0VZUyAqIHNpemVvZihTY2FuS2V5RGF0YSkpOw0KCW1lbXNldChrZXlzLCAwLCBOS0VZUyAq
IHNpemVvZihTY2FuS2V5RGF0YSkpOw0KDQoJZm9yKGludCBpID0gMDsgaSA8IG47IGkrKykNCgl7
DQoJCWlkeCA9IHZlcnNpb24xKE5LRVlTLCBrZXlzKTsNCgkJZnJlZShpZHgpOw0KCX0NCglmcmVl
KGtleXMpOw0KfQ0KDQp2b2lkIHRlc3QyKGludCBuKQ0Kew0KCVNjYW5LZXlEYXRhICprZXlzOw0K
CVNjYW5LZXlEYXRhICppZHg7DQoNCiAgICAgICAga2V5cyA9IChTY2FuS2V5RGF0YSAqKSBtYWxs
b2MoTktFWVMgKiBzaXplb2YoU2NhbktleURhdGEpKTsNCgltZW1zZXQoa2V5cywgMCwgTktFWVMg
KiBzaXplb2YoU2NhbktleURhdGEpKTsNCg0KCWZvcihpbnQgaSA9IDA7IGkgPCBuOyBpKyspDQoJ
ew0KCQlpZHggPSB2ZXJzaW9uMihOS0VZUywga2V5cyk7DQoJCWZyZWUoaWR4KTsNCgl9DQoJZnJl
ZShrZXlzKTsNCn0NCg0KDQppbnQgbWFpbih2b2lkKQ0Kew0KCXN0cnVjdCB0aW1lc3BlYyBzdGFy
dCxlbmQ7DQoJaW50NjRfdCB2ZXJzaW9uMV90aW1lLCB2ZXJzaW9uMl90aW1lOw0KDQoJY2xvY2tf
Z2V0dGltZShDTE9DS19QUk9DRVNTX0NQVVRJTUVfSUQsICZzdGFydCk7DQoJdGVzdDEoTE9PUFMp
Ow0KCWNsb2NrX2dldHRpbWUoQ0xPQ0tfUFJPQ0VTU19DUFVUSU1FX0lELCAmZW5kKTsNCgl2ZXJz
aW9uMV90aW1lID0gZ2V0X2Nsb2NrX2RpZmYoJmVuZCwgJnN0YXJ0KTsNCglwcmludGYoInZlcnNp
b24xOiBkb25lIGluICVsbGQgbmFub3NlY29uZHNcbiIsIHZlcnNpb24xX3RpbWUpOwkNCg0KCWNs
b2NrX2dldHRpbWUoQ0xPQ0tfUFJPQ0VTU19DUFVUSU1FX0lELCAmc3RhcnQpOw0KCXRlc3QyKExP
T1BTKTsNCgljbG9ja19nZXR0aW1lKENMT0NLX1BST0NFU1NfQ1BVVElNRV9JRCwgJmVuZCk7DQoJ
dmVyc2lvbjJfdGltZSA9IGdldF9jbG9ja19kaWZmKCZlbmQsICZzdGFydCk7DQoJcHJpbnRmKCJ2
ZXJzaW9uMjogZG9uZSBpbiAlbGxkIG5hbm9zZWNvbmRzXG4iLCB2ZXJzaW9uMl90aW1lKTsJDQoN
CglwcmludGYoIiglZyB0aW1lcyBmYXN0ZXIpXG4iLCAoZG91YmxlKSB2ZXJzaW9uMV90aW1lIC8g
dmVyc2lvbjJfdGltZSk7DQoNCglyZXR1cm4gMDsNCn0NCg==
--000000000000faaf27064cd72c94--