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 1r0CYY-0048DD-FM for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Nov 2023 03:15:10 +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 1r0CYW-003wwD-SG for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Nov 2023 03:15:08 +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 1r0CYW-003ww4-Ic for pgsql-hackers@lists.postgresql.org; Tue, 07 Nov 2023 03:15:08 +0000 Received: from mail-yw1-x1133.google.com ([2607:f8b0:4864:20::1133]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1r0CYT-004Kmv-Do for pgsql-hackers@lists.postgresql.org; Tue, 07 Nov 2023 03:15:07 +0000 Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-5b499b18b28so62811697b3.0 for ; Mon, 06 Nov 2023 19:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; t=1699326904; x=1699931704; darn=lists.postgresql.org; h=user-agent: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=c7tp+CB24naKUqjMbX2n8/91JACoecsAO9crMHxUHJY=; b=B4gyFHq6RQWEjiFV4vrcQyJelXeo31kZ9vOhmSdVGz4QjHKDgEP2MWpoQxuu7dD/Hc ICQG8paqbqhAYvrQoCyotG8R8WVeXhhZV3H1VRxl/On0JMvjVWRgtKTYiGoHLjLv0zGo /X8371tdyU3u2/vI4GNlLALiDjWZAxKnICkCU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699326904; x=1699931704; h=user-agent: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=c7tp+CB24naKUqjMbX2n8/91JACoecsAO9crMHxUHJY=; b=AgJGPl0vTCaZOd60BUQtiZVHuYmzQgNl88kdqdzTlkcgsHNsa5tRqDQO64LBIV51u2 kxzy9jeYeaAqI9UwT5rGLt/GVi+pr1QoIx8+nDhNTr53b+S5qoUZr4ohG7HNTKA76AOO 4hnTleVWGSAliAYuCzW72JB9ZTIPbhRbdWVM9sJHx0UphE1uiTQiwAu+KH4YmFBLEEeD 7Y2CXLqvju7GJXSiw9WfLF6Jbnr2bRJljHZnmFg3jFfaX/iCgMtZ7XgObiW+xDRzNdqT 7bjrrjzV1m5vXtkT/wYD6TDvw8BRKSDlktK53zAakvwp3j9ECWpCKKOFr0XP1PXuLZB+ g3eA== X-Gm-Message-State: AOJu0YzW+tKfcFpfUOc2SbP0TZznjJ3tBSbMFLNJSmJe6nMrLOPGgAhh M5yak9zzCCe8Hew+hCaMqXGjTg== X-Google-Smtp-Source: AGHT+IH8+0QtcGZqvm4ov0okWE144U5veX1kX4yrzfkV0NHE6EP8JHg70Yk2cpcmKJJGePcq7Nt1EA== X-Received: by 2002:a81:9911:0:b0:5a8:f9fa:aba4 with SMTP id q17-20020a819911000000b005a8f9faaba4mr11060197ywg.2.1699326904700; Mon, 06 Nov 2023 19:15:04 -0800 (PST) Received: from rfd.leadboat.com ([2600:1702:a20:5750::48]) by smtp.gmail.com with ESMTPSA id s38-20020a814526000000b005a7bf2aff15sm5127434ywa.95.2023.11.06.19.15.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Nov 2023 19:15:04 -0800 (PST) Date: Mon, 6 Nov 2023 19:15:01 -0800 From: Noah Misch To: Tom Lane Cc: Nathan Bossart , Matthias van de Meent , "Amonson, Paul D" , "pgsql-hackers@lists.postgresql.org" , "Shankaran, Akash" Subject: Re: Popcount optimization using AVX512 Message-ID: <20231107031501.61@rfd.leadboat.com> References: <20231107022240.GA729644@nathanxps13> <36329.1699325578@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36329.1699325578@sss.pgh.pa.us> User-Agent: Mutt/2.2.12 (2023-09-09) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Nov 06, 2023 at 09:52:58PM -0500, Tom Lane wrote: > Nathan Bossart writes: > > Like I said, I don't have any proposals yet, but assuming we do want to > > support newer intrinsics, either open-coded or via auto-vectorization, I > > suspect we'll need to gather consensus for a new policy/strategy. > > Yeah. The function-pointer solution kind of sucks, because for the > sort of operation we're considering here, adding a call and return > is probably order-of-100% overhead. Worse, it adds similar overhead > for everyone who doesn't get the benefit of the optimization. The glibc/gcc "ifunc" mechanism was designed to solve this problem of choosing a function implementation based on the runtime CPU, without incurring function pointer overhead. I would not attempt to use AVX512 on non-glibc systems, and I would use ifunc to select the desired popcount implementation on glibc: https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/Function-Attributes.html