Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rZdKc-005aXd-8I for pgsql-hackers@arkaria.postgresql.org; Mon, 12 Feb 2024 20:55:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rZdKb-00DMwO-8o for pgsql-hackers@arkaria.postgresql.org; Mon, 12 Feb 2024 20:55:13 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rZdKa-00DMwE-Ve for pgsql-hackers@lists.postgresql.org; Mon, 12 Feb 2024 20:55:12 +0000 Received: from mail-io1-xd2c.google.com ([2607:f8b0:4864:20::d2c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rZdKY-006QS6-Fj for pgsql-hackers@lists.postgresql.org; Mon, 12 Feb 2024 20:55:11 +0000 Received: by mail-io1-xd2c.google.com with SMTP id ca18e2360f4ac-7c00128de31so7308139f.3 for ; Mon, 12 Feb 2024 12:55:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707771310; x=1708376110; darn=lists.postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=rJ8p3MPmIgC+MGy8YvHCPKLNtERzL82mutoheW4QWQU=; b=KE8VL992SpKZ5U+z+7Gq2V1L/XKGWsXKPNkGuPlW7IKA7PVdYo/vKD40JiGsLSJeFD 5TzFfXfxMuTS1+0sSJ+I4YQiAXWAJa50ONAaE2ZzkHjFaMJUNnJ0lqe5o7lgPoq27Lnf 6dnarBiSP8qFEuaXucLx0jGEmWdNVK96CJGOVimXnNVI2AWb2vXvmvDL8fVQVr/pz7Zp 0g+Ji8Orw4n88hxMvBc8/090xhGgnftaSX0NX7vx8NBG09ddbirhsK0lgaDZAoj2NO7E Wf0r0KdmYU+YSEzxW0gGYC6VqagVLQVNq1/jvkfHwipLuocbHDGm//nNWFva7Sh3YX/M iJHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707771310; x=1708376110; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=rJ8p3MPmIgC+MGy8YvHCPKLNtERzL82mutoheW4QWQU=; b=NXWYRtWI/3v9XFBZ3zxoY1w6E3l113zAxE7oPIDUulCwYB4Mv1LQG7EXla7xoOO+yY AsUiYZfkCB8oRkke77TOsc4mc1PcbdV90553WzbIIPE1Acdr/CWeRcmxRdLecQhycnqZ vo3Lf21BJLR+QO4Ity2CB374153Xjtext1aIChoNbc4CIjb2ez3UIkILjx1VQsK0gnB6 nPi4m72fNmOfUI3EwGbjI0gq7eETXXTj7XnUlighLQBowXCyZ64QwH6LukfDtmp+VIs6 JopXo4a2sbpD+3Lb3gtcOLTt51IHYQBqHrOMlXjWpXD1tM4gJ6ivQ3uWY0kfODzh0IHj q+UA== X-Forwarded-Encrypted: i=1; AJvYcCUk22yABUE2uoKTrp5aHR/Fx8B/JN6UGzWMyFyJs4vVLRNsH3pVq8PYi6j95HSpAPToobblGxZp6oNeGFSP+TulqkdMAebvNJOqyD5bqKcGxTO0 X-Gm-Message-State: AOJu0YznosDXmRlERsIgtpd3CCgdZT6fVWUj4ITYtRCFT+R68i/8686V +8aWTgnS72s6BZUoUvRctOcse0ictjtH8XkGO6F+IXM1L1Aqb96B X-Google-Smtp-Source: AGHT+IFaS4+CU83f865rhWuu/M5zHK1KNTT9LlnWEAIzkJz1jNtpnYPDLwqmkEMUTfIcnsFfgju6aw== X-Received: by 2002:a05:6602:340c:b0:7c4:6efa:49dc with SMTP id n12-20020a056602340c00b007c46efa49dcmr1697873ioz.11.1707771309740; Mon, 12 Feb 2024 12:55:09 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCWfUOGbrHTUQcfOG3H4QpPYakeQh6pYMU3oQJU0Edm7sJ6aLEw+Z07xZlNIx9SKp/HWQf+gjFHmYVXKpbsVrVs1zhQDP7+OHlfmpFinximvMRo3XdioBTyZPY3gX8OtTDzIL4nggljlHqNM4ncuV21HyXVQef1ByQio6YkfqXoWUfsuGD8EsifFIlCYTjf+kGBzmpByB6urwcRQcLRw8v8IZU9PXJ+zP1lA2GZxTyMHg6nNEDYXuSCBQADH5nXO1Ns04UlO65q90HciwAiaXS8bEw== Received: from nathanxps13 (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id k21-20020a023355000000b004712c18c13asm1572345jak.125.2024.02.12.12.55.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Feb 2024 12:55:09 -0800 (PST) Date: Mon, 12 Feb 2024 14:55:07 -0600 From: Nathan Bossart To: Noah Misch Cc: Andres Freund , Alvaro Herrera , "Shankaran, Akash" , "Amonson, Paul D" , Tom Lane , Matthias van de Meent , "pgsql-hackers@lists.postgresql.org" Subject: Re: Popcount optimization using AVX512 Message-ID: <20240212205507.GB1815383@nathanxps13> References: <202401250949.xrwkd46bgbpl@alvherre.pgsql> <202401260642.3rxzgb2xrhkl@alvherre.pgsql> <20240209182432.7c2peq5cgbdl43um@awork3.anarazel.de> <20240209232757.5d@rfd.leadboat.com> <20240210043323.uofbl6h7twao2mqg@awork3.anarazel.de> <20240210235238.eb@rfd.leadboat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240210235238.eb@rfd.leadboat.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Feb 10, 2024 at 03:52:38PM -0800, Noah Misch wrote: > On Fri, Feb 09, 2024 at 08:33:23PM -0800, Andres Freund wrote: >> My understanding is that the ifunc mechanism just avoid the need for repeated >> indirect calls/jumps to implement a single function call, not the use of >> indirect function calls at all. Calls into shared libraries, like libc, are >> indirected via the GOT / PLT, i.e. an indirect function call/jump. Without >> ifuncs, the target of the function call would then have to dispatch to the >> resolved function. Ifuncs allow to avoid this repeated dispatch by moving the >> dispatch to the dynamic linker stage, modifying the contents of the GOT/PLT to >> point to the right function. Thus ifuncs are an optimization when calling a >> function in a shared library that's then dispatched depending on the cpu >> capabilities. >> >> However, in our case, where the code is in the same binary, function calls >> implemented in the main binary directly (possibly via a static library) don't >> go through GOT/PLT. In such a case, use of ifuncs turns a normal direct >> function call into one going through the GOT/PLT, i.e. makes it indirect. The >> same is true for calls within a shared library if either explicit symbol >> visibility is used, or -symbolic, -Wl,-Bsymbolic or such is used. Therefore >> there's no efficiency gain of ifuncs over a call via function pointer. >> >> >> This isn't because ifunc is implemented badly or something - the reason for >> this is that dynamic relocations aren't typically implemented by patching all >> callsites (".text relocations"), which is what you would need to avoid the >> need for an indirect call to something that fundamentally cannot be a constant >> address at link time. The reason text relocations are disfavored is that >> they can make program startup quite slow, that they require allowing >> modifications to executable pages which are disliked due to the security >> implications, and that they make the code non-shareable, as the in-memory >> executable code has to differ from the on-disk code. >> >> >> I actually think ifuncs within the same binary are a tad *slower* than plain >> function pointer calls, unless -fno-plt is used. Without -fno-plt, an ifunc is >> called by 1) a direct call into the PLT, 2) loading the target address from >> the GOT, 3) making an an indirect jump to that address. Whereas a "plain >> indirect function call" is just 1) load target address from variable 2) making >> an indirect jump to that address. With -fno-plt the callsites themselves load >> the address from the GOT. > > That sounds more accurate than what I wrote. Thanks. +1, thanks for the detailed explanation, Andres. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com