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 1rsMkK-006aY1-F7 for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Apr 2024 13:03:13 +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 1rsMkH-004s8j-Ve for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Apr 2024 13:03:09 +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 1rsMkH-004s8b-Hl for pgsql-hackers@lists.postgresql.org; Thu, 04 Apr 2024 13:03:09 +0000 Received: from mail-pl1-x633.google.com ([2607:f8b0:4864:20::633]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rsMkE-000bUS-N7 for pgsql-hackers@lists.postgresql.org; Thu, 04 Apr 2024 13:03:08 +0000 Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-1e0bec01232so7963635ad.3 for ; Thu, 04 Apr 2024 06:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20230601.gappssmtp.com; s=20230601; t=1712235785; x=1712840585; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=pmnEJSZtUCQChTa4xdxze5cX9KuG8P55vm9a3r670WE=; b=c8ZNwwht09GBbrcv/JZF0EQGqKE5goAi0w42aFIVColW7NgHpsNhL9S2ydUGuPSVtE un9tpPISrNFSGEAv88CPRwEsVtZ0bzxNDlbdhHWUuYXdY5wriKuFivYjSJ5NMrnm+i6m lXzfOAnwDiHIH9Lp2TEArDTTboS6PE8duT0O46qKExgqeIQNu5ecnIPixPxUe/IqLgvw sbHdAWZltfcWeEwXVpKIT4hxCE3/IZVyShBvxHrJnsuOvuOvOWdxJOqaYiNGkL5UBVsv LlIPS04UpxYHUWj3yJ1HaB92AjfcsP6/GutVVEb1T+nK092Q4zQQPyXa763R2cipZXiH JFXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712235785; x=1712840585; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pmnEJSZtUCQChTa4xdxze5cX9KuG8P55vm9a3r670WE=; b=AzHS6EjavF7/Gg+chIoy57tKfxQBKPHnwDL7rT9XfSsqx1Ta3ujgh2td3owYIb5RSg RNmHGkcQ88TTzNLbt6J2O6jUiXisoZMknvCRWSRnIMwePnyutHU9wgFtnG2qxxvL75UW 9GQpNeS34v3Hp/1+FocW1b7/42LpHgd6AUZdYuSMtm1pGJKER7xrOFqOP+AQnZfpxb3/ RjaQeGryWYDuRhN0tlEHeBo7N8T45vXQqSpN7grLsDalXfdnW2JjwrVCY1jNJAELTvAA SKEm4SoKVhiQa1yPFGS4+XLA1Dn3A7FjlJ6otNBOjx1FywOACla8Y2kHi5q35y7VVkFM kdcw== X-Forwarded-Encrypted: i=1; AJvYcCVDRbreFverRZ4cR+mGDKjN0BuNdT1KcuS8rofzFEZeS4edKKrJ+Bd8+El1w2qT4/Ks8dk5hKhHdVr8nrzOXDlIFdeR7gUCXm+CWKZ5ZIAOT6Gj X-Gm-Message-State: AOJu0YwGRYbmi8lUoTd25AMdASZV4WPhDMVLNps84rbhBkqkCnmTCO// SMI+9bD1Yk4HRTsN+LAjO8Q2LhSvIYp2SG8PDOzVpu3HU15ZO4sOAJR0AxBd06Oe9K6O1UL+goT T9hlFypb5oSa6FhfQ919wAPq6/HfVzhlpP0dITQ== X-Google-Smtp-Source: AGHT+IHBKMpbJFA70GO4+SYwg4uuT7h0ituxdNE4MhFcvlTYopUiaoaqx6DwSF5CQQeRlcchXae46QweCRRBOrHEt/4= X-Received: by 2002:a17:902:f7ca:b0:1e2:c198:7cc7 with SMTP id h10-20020a170902f7ca00b001e2c1987cc7mr107956plw.28.1712235784641; Thu, 04 Apr 2024 06:03:04 -0700 (PDT) MIME-Version: 1.0 References: <20240401011708.GA2128739@nathanxps13> <202404011106.y4fci35kzdqt@alvherre.pgsql> <20240401155338.GA2296072@nathanxps13> <20240401213140.GA2362108@nathanxps13> <20240403225029.GA3851411@nathanxps13> In-Reply-To: <20240403225029.GA3851411@nathanxps13> From: Ants Aasma Date: Thu, 4 Apr 2024 16:02:53 +0300 Message-ID: Subject: Re: Popcount optimization using AVX512 To: Nathan Bossart Cc: Alvaro Herrera , "Amonson, Paul D" , Tom Lane , David Rowley , Andres Freund , "Shankaran, Akash" , Noah Misch , Matthias van de Meent , "pgsql-hackers@lists.postgresql.org" Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, 4 Apr 2024 at 01:50, Nathan Bossart wrote: > If we can verify this approach won't cause segfaults and can stomach the > regression between 8 and 16 bytes, I'd happily pivot to this approach so > that we can avoid the function call dance that I have in v25. The approach I posted does not rely on masking performing page fault suppression. All loads are 64 byte aligned and always contain at least one byte of the buffer and therefore are guaranteed to be within a valid page. I personally don't mind it being slower for the very small cases, because when performance on those sizes really matters it makes much more sense to shoot for an inlined version instead. Speaking of which, what does bumping up the inlined version threshold to 16 do with and without AVX-512 available? Linearly extrapolating the 2 and 4 byte numbers it might just come ahead in both cases, making the choice easy. Regards, Ants Aasma