Date: Thu, 19 Nov 2020 00:25:33 +0100 From: Stefan Esser <se@freebsd.org> To: Jessica Clarke <jrtc27@freebsd.org> Cc: Mateusz Guzik <mjguzik@gmail.com>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r367813 - head/lib/libutil Message-ID: <81fd2ce6-b5b1-7f05-c575-6b233e78b739@freebsd.org> In-Reply-To: <E1B6A5BE-DF00-42D7-B31D-1F4C5D9CBB7D@freebsd.org> References: <202011181944.0AIJiUU3003699@repo.freebsd.org> <CAGudoHEYEZaBTDi_wPdsAc4BkDA6cBfYgxtVw4qEATt62UUPrA@mail.gmail.com> <ba78fdf4-3b64-8b8e-73a1-4198109db1ef@freebsd.org> <E1B6A5BE-DF00-42D7-B31D-1F4C5D9CBB7D@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Hluk95MNiLLfA4Hay0ZfEgF1ONiy0Z68x
Content-Type: multipart/mixed; boundary="Z9ii1UL5laaUE7Rl1xeqBhfUJAMDSx3PN";
protected-headers="v1"
From: Stefan Esser <se@freebsd.org>
To: Jessica Clarke <jrtc27@freebsd.org>
Cc: Mateusz Guzik <mjguzik@gmail.com>, src-committers@freebsd.org,
svn-src-all@freebsd.org, svn-src-head@freebsd.org
Message-ID: <81fd2ce6-b5b1-7f05-c575-6b233e78b739@freebsd.org>
Subject: Re: svn commit: r367813 - head/lib/libutil
References: <202011181944.0AIJiUU3003699@repo.freebsd.org>
<CAGudoHEYEZaBTDi_wPdsAc4BkDA6cBfYgxtVw4qEATt62UUPrA@mail.gmail.com>
<ba78fdf4-3b64-8b8e-73a1-4198109db1ef@freebsd.org>
<E1B6A5BE-DF00-42D7-B31D-1F4C5D9CBB7D@freebsd.org>
In-Reply-To: <E1B6A5BE-DF00-42D7-B31D-1F4C5D9CBB7D@freebsd.org>
--Z9ii1UL5laaUE7Rl1xeqBhfUJAMDSx3PN
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Am 18.11.20 um 23:39 schrieb Jessica Clarke:
> On 18 Nov 2020, at 22:32, Stefan Esser <se@freebsd.org> wrote:
>>
>> Am 18.11.20 um 22:40 schrieb Mateusz Guzik:
>>>> +{
>>>> + static const int localbase_oid[2] =3D {CTL_USER, USER_LOCALBASE};
>>> There is no use for this to be static.
>>
>> Why not? This makes it part of the constant initialized data of
>> the library, which is more efficient under run-time and memory
>> space aspects than initializing them on the stack.
>>
>> What do I miss?
>=20
> What is more efficient is not so clear-cut, it depends on things like
> the architecture, microarchitecture and ABI. Allocating a small buffer
> on the stack is extremely cheap (the memory will almost certainly be in=
> the L1 cache), whereas globally-allocated storage is less likely to be
> in the cache due to being spread out, and on some architecture/ABI
> combinations will incur additional indirection through the GOT. Also, 8=
> bytes of additional stack use is lost in the noise.
The memory latency of the extra access to the constant will be hidden in =
the noise. The data will probably be in a page that has already been
accessed (so no TLB load penalty) and modern CPUs will be able to deal
with the cache miss (if any, because the cache line may already be
loaded depending on other data near-by).
Yes, I do agree that a stack local variable could have been used and
it could have been created with little effort by a modern multi-issue
CPU. The code size would have been larger, though, by some 10 to 20
bytes, I'd assume - but I doubt a single path through this code is
measurable, much less observable in practice.
We are talking about nano-seconds here (even if the cache line did
not contain the constant data, it would probably be accessed just a
few instructions further down and incur the same latency then).
I have followed CPU development over more than 45 years and know many
architectures and their specifics, but the time were I have programmed
drivers in assembly and counted instruction cycles is long gone.
This is nitpicking at a level that I do not want to continue. I'm not
opposed to achieving efficiency where it is relevant. This function is
providing useful functionality and I do not mind a wasted microsecond,
it is not relevant here. (This was different if it was wasted within
a tight loop - but it is not, it is typically called once if at all).
Feel free to replace my code with your implementation, if you think it
is not acceptable as written by me.
I just wanted to provide an implementation of this functionality to
be used in a number of programs where other developers had expressed
interest in such a feature (and one of these programs has been worked
on by me in recent weeks, so I'm now able to make use of it myself).
Regards, STefan
--Z9ii1UL5laaUE7Rl1xeqBhfUJAMDSx3PN--
--Hluk95MNiLLfA4Hay0ZfEgF1ONiy0Z68x
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"
-----BEGIN PGP SIGNATURE-----
wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAl+1rW0FAwAAAAAACgkQR+u171r99UTD
YwgArC2xVFaz75Gki89FtOWYeDRJnYYxrRkuiDbj8IvErAafuELHv7vKhF9EsbndPYvUXBCvB3hW
bp9pq4lcQ7OtpIthCmZAy+KPABD4zBysbyEM/7/FVjOOLvXj9NKOe94gTDj5VxrD7ZgxC3+pVmBb
IkvE3sYwjuOfOU6BLIWqatNIEbqk+xqSjm6RYX3vlXeGcOwkH2YN19JZOvTG/SuP2K5EhAA8Qdfr
3Z7csXZ/dz9AZkSkvWEexPcAvWQv+Pir2UpLdhto6EXF5QPs8E81F/E+Xd2LGf2F9Vxzvj2ZbdiE
wVhVn+vD1IjlUJPLPYuilr7NHkvd80oxM0sYxRdLkA==
=W8FB
-----END PGP SIGNATURE-----
--Hluk95MNiLLfA4Hay0ZfEgF1ONiy0Z68x--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?81fd2ce6-b5b1-7f05-c575-6b233e78b739>