From owner-svn-src-all@freebsd.org Wed Nov 18 23:25:35 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 85977474E12; Wed, 18 Nov 2020 23:25:35 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CbzSb3Brzz4nmv; Wed, 18 Nov 2020 23:25:35 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-WLAN.fritz.box (p200300cd5f3b88002402e588537088de.dip0.t-ipconnect.de [IPv6:2003:cd:5f3b:8800:2402:e588:5370:88de]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id A81442D6BE; Wed, 18 Nov 2020 23:25:34 +0000 (UTC) (envelope-from se@freebsd.org) To: Jessica Clarke Cc: Mateusz Guzik , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <202011181944.0AIJiUU3003699@repo.freebsd.org> From: Stefan Esser Subject: Re: svn commit: r367813 - head/lib/libutil Message-ID: <81fd2ce6-b5b1-7f05-c575-6b233e78b739@freebsd.org> Date: Thu, 19 Nov 2020 00:25:33 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Hluk95MNiLLfA4Hay0ZfEgF1ONiy0Z68x" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 23:25:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Hluk95MNiLLfA4Hay0ZfEgF1ONiy0Z68x Content-Type: multipart/mixed; boundary="Z9ii1UL5laaUE7Rl1xeqBhfUJAMDSx3PN"; protected-headers="v1" From: Stefan Esser To: Jessica Clarke Cc: Mateusz Guzik , 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> In-Reply-To: --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 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--