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 1r0STL-005lPX-J4 for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Nov 2023 20:14:51 +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 1r0STJ-00BoEQ-Lr for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Nov 2023 20:14:49 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r0STJ-00BoD3-Bt for pgsql-hackers@lists.postgresql.org; Tue, 07 Nov 2023 20:14:49 +0000 Received: from mail-io1-xd30.google.com ([2607:f8b0:4864:20::d30]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1r0STG-005EKm-HK for pgsql-hackers@lists.postgresql.org; Tue, 07 Nov 2023 20:14:48 +0000 Received: by mail-io1-xd30.google.com with SMTP id ca18e2360f4ac-7a683bd610dso220958939f.1 for ; Tue, 07 Nov 2023 12:14:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699388083; x=1699992883; darn=lists.postgresql.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=4lMYee1hqabPWC+TsQBDOYOWD6sWGBI1vke/6jgM7bg=; b=YHfttPyjVVurzaxIJGrkNMFtivmGyFhE7kq9jybQhhaj/uj/V3/IJT+Zz3OyK1C87t KtIBdZi73AN00+RShMhBP6EpPlDZX3+Q2zJaEOV2DmvOO8FaHf4SPocvLnIHvdSlua1e IAFCWeEagBvJGS+RJkLMrTaMbEs+zP8rIjfvAo0vRClfywocnWyfT5HTfi2PYd8CBn1+ QqbOqB2SvqbISJiR0zJ14CYCwQ7euiOshLcCEwQ7rlHxBHgE78jV41/hqrMGU1u695w8 XM0QTudcZef9bSTwjY8f6cOe4duI4WSdFOmTcXpranWc17z9d9C1tg5LluAyFlRGi7k7 sSiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699388083; x=1699992883; h=in-reply-to:content-transfer-encoding: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=4lMYee1hqabPWC+TsQBDOYOWD6sWGBI1vke/6jgM7bg=; b=vVzuXfo52H8chtFvobz/ipY15x7Om2MIzMuZogDWgdvhC1sfyA3YiElRT6jfViAP54 9yCz06vGC3nk2dgwpMycY1UC3ZCVZdXs9wd/Ln7lthPVKkWzSLEOBa/UYyTzNUB4YjgR SiOna5hC5Y+eAgrlSC6uZBNeI6JP6UHKNaul2OkIZbtpLz2+a38d51qoDJpZ2R+VvQH8 Urt054MeQWtFGtW6wlksH5q5FddCcOftgfKxxiBGpgv9zqqRaiK9lIyzT7wsitEA8T82 uW9xLV2i6So2DsAFh77ojPCvk+MI9GK9EsGsDLoYxOtglq2anNL7gWoCgVROXDj1Divv 0eng== X-Gm-Message-State: AOJu0YyPb2wEargDrFJTouILTOaom66bw6QEKlhVLqtStTD4AMG8L2jY BAdFcr7/ERLAjZ52g6Ye1sA= X-Google-Smtp-Source: AGHT+IG1Tb8UQ4sOpbu9lWLiDNDQTRMwfxexZmHy5fq3uM7pZCRwDjf3cbqpmGGISdI4rEIhRfVhBQ== X-Received: by 2002:a05:6602:15c4:b0:7a6:b272:fd78 with SMTP id f4-20020a05660215c400b007a6b272fd78mr47460023iow.10.1699388083658; Tue, 07 Nov 2023 12:14:43 -0800 (PST) Received: from nathanxps13 (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id ep15-20020a0566384e0f00b0042aec33bc26sm2924113jab.18.2023.11.07.12.14.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Nov 2023 12:14:42 -0800 (PST) Date: Tue, 7 Nov 2023 14:14:41 -0600 From: Nathan Bossart To: Noah Misch Cc: Tom Lane , Matthias van de Meent , "Amonson, Paul D" , "pgsql-hackers@lists.postgresql.org" , "Shankaran, Akash" Subject: Re: Popcount optimization using AVX512 Message-ID: <20231107201441.GA898662@nathanxps13> References: <20231107022240.GA729644@nathanxps13> <36329.1699325578@sss.pgh.pa.us> <20231107031501.61@rfd.leadboat.com> <20231107035926.GD729644@nathanxps13> <20231107055315.8e@rfd.leadboat.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20231107055315.8e@rfd.leadboat.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Mon, Nov 06, 2023 at 09:53:15PM -0800, Noah Misch wrote: > On Mon, Nov 06, 2023 at 09:59:26PM -0600, Nathan Bossart wrote: >> On Mon, Nov 06, 2023 at 07:15:01PM -0800, Noah Misch wrote: >> > 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 >> >> Thanks, that seems promising for the function pointer cases. I'll plan on >> trying to convert one of the existing ones to use it. BTW it looks like >> LLVM has something similar [0]. >> >> IIUC this unfortunately wouldn't help for cases where we wanted to keep >> stuff inlined, such as is_valid_ascii() and the functions in pg_lfind.h, >> unless we applied it to the calling functions, but that doesn't ѕound >> particularly maintainable. > > Agreed, it doesn't solve inline cases. If the gains are big enough, we should > move toward packages containing N CPU-specialized copies of the postgres > binary, with bin/postgres just exec'ing the right one. I performed a quick test with ifunc on my x86 machine that ordinarily uses the runtime checks for the CRC32C code, and I actually see a consistent 3.5% regression for pg_waldump -z on 100M 65-byte records. I've attached the patch used for testing. The multiple-copies-of-the-postgres-binary idea seems interesting. That's probably not something that could be enabled by default, but perhaps we could add support for a build option. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com --TB36FDmn/VVEgNH/ Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ifunc_test.patch" diff --git a/src/include/port/pg_crc32c.h b/src/include/port/pg_crc32c.h index d085f1dc00..6db411ee29 100644 --- a/src/include/port/pg_crc32c.h +++ b/src/include/port/pg_crc32c.h @@ -78,7 +78,7 @@ extern pg_crc32c pg_comp_crc32c_loongarch(pg_crc32c crc, const void *data, size_ #define FIN_CRC32C(crc) ((crc) ^= 0xFFFFFFFF) extern pg_crc32c pg_comp_crc32c_sb8(pg_crc32c crc, const void *data, size_t len); -extern pg_crc32c (*pg_comp_crc32c) (pg_crc32c crc, const void *data, size_t len); +extern pg_crc32c pg_comp_crc32c(pg_crc32c crc, const void *data, size_t len); #ifdef USE_SSE42_CRC32C_WITH_RUNTIME_CHECK extern pg_crc32c pg_comp_crc32c_sse42(pg_crc32c crc, const void *data, size_t len); diff --git a/src/port/pg_crc32c_sse42_choose.c b/src/port/pg_crc32c_sse42_choose.c index 41ff4a35ad..62bb981ee8 100644 --- a/src/port/pg_crc32c_sse42_choose.c +++ b/src/port/pg_crc32c_sse42_choose.c @@ -51,14 +51,14 @@ pg_crc32c_sse42_available(void) * so that subsequent calls are routed directly to the chosen implementation. */ static pg_crc32c -pg_comp_crc32c_choose(pg_crc32c crc, const void *data, size_t len) +(*pg_comp_crc32c_choose (void))(pg_crc32c crc, const void *data, size_t len) { if (pg_crc32c_sse42_available()) - pg_comp_crc32c = pg_comp_crc32c_sse42; + return pg_comp_crc32c_sse42; else - pg_comp_crc32c = pg_comp_crc32c_sb8; - - return pg_comp_crc32c(crc, data, len); + return pg_comp_crc32c_sb8; } -pg_crc32c (*pg_comp_crc32c) (pg_crc32c crc, const void *data, size_t len) = pg_comp_crc32c_choose; +pg_crc32c +pg_comp_crc32c(pg_crc32c crc, const void *data, size_t len) + __attribute__ ((ifunc ("pg_comp_crc32c_choose"))); --TB36FDmn/VVEgNH/--