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 1rNEpy-00AKaF-O4 for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Jan 2024 16:20:23 +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 1rNEpu-00E2co-VQ for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Jan 2024 16:20:18 +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 1rNEpu-00E2cg-Lq for pgsql-hackers@lists.postgresql.org; Tue, 09 Jan 2024 16:20:18 +0000 Received: from mail-io1-xd29.google.com ([2607:f8b0:4864:20::d29]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rNEpp-000gFP-0t for pgsql-hackers@postgresql.org; Tue, 09 Jan 2024 16:20:17 +0000 Received: by mail-io1-xd29.google.com with SMTP id ca18e2360f4ac-7bc332d3a8cso222884339f.2 for ; Tue, 09 Jan 2024 08:20:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704817212; x=1705422012; darn=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=tcvcQrYNJmNRfjrXRVNnHVgez31XTxG/ZuntLQ3s+Yc=; b=bX278c16wbzxf91c0PNQBHBskbu6tND0+KzgYzS6QQGgBG24244I+G7CdTtSArEFvp yeiDnaOGrjhbUnZBt3WOATjPuezZwOHqS5oSThQaddrByrDN1WYxePchwrmQYs5/7k0U nXBMVc56E4I7MGbmBeNLF8T54r98oNGFsLegKIDpmxCQa8rOvnhm47JpLPAOiWkAsWwP +QGao/upAeMAk9jWl5+kxYsINdmQCiZmfl28rIKPzKiB/iVGVgsjp9c/PILkPSHvfbtG g8ehSAE6rag6+M4/pSsPAOJ14L7pfMoo4a7bbtalXjzMw3g2U/vtuAJwdeKBNpSoNOiN ww+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704817212; x=1705422012; 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=tcvcQrYNJmNRfjrXRVNnHVgez31XTxG/ZuntLQ3s+Yc=; b=C8jksts0l6M3pwuNmlRj87JK8s5if/p1aqQk1GMPzhtCbzMUookkXFeQJedtxHGAD4 oYbYKpddbqTh4IYn+QZwkbZ9XclJnrv6ibh5kPMhz5WpXfYqEis5IMLrQU0Jd8r4BeL/ gZWItE/JGIuF6mfcIty/vHYFxFmxuudOcBZ4Lq5mDB3wGovDqf2XJtRStRBlCi7ySCx6 G+v8mR2bl1b5vYgm8ww47H1oqwlF8zG1kSdLTNH99UUP+9LbSsKlR0p5isky6ddKxDyH 60M8z7t//OMl61vpkITe+jr3jWxd6c49pyG7Rg18RvlkBk7ZfLUUxSB7enuvoxHSA4/y C6dw== X-Gm-Message-State: AOJu0YzMlcDWndOkMi5o2UTXeE0cnM7OsK4M7qOs7FJ0dR7laurl7w4e ksKJKGcvYiygAaY7fx33FBFnnAtB/cg= X-Google-Smtp-Source: AGHT+IH1C/fz4MUtYF/htbLpDvxdzReSxCVOgL9EF5qlfitl2893o+QIlUnpzRC1UdI/aGMIYnBigg== X-Received: by 2002:a5d:954e:0:b0:7ba:9123:6711 with SMTP id a14-20020a5d954e000000b007ba91236711mr6567910ios.15.1704817212267; Tue, 09 Jan 2024 08:20:12 -0800 (PST) Received: from nathanxps13 (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id gj2-20020a0566386a0200b0046e1f819979sm711000jab.90.2024.01.09.08.20.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jan 2024 08:20:11 -0800 (PST) Date: Tue, 9 Jan 2024 10:20:09 -0600 From: Nathan Bossart To: John Naylor Cc: Ants Aasma , pgsql-hackers@postgresql.org Subject: Re: add AVX2 support to simd.h Message-ID: <20240109162009.GA3033933@nathanxps13> References: <20231129171526.GA857928@nathanxps13> <20240108173715.GC2611898@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jan 09, 2024 at 09:20:09AM +0700, John Naylor wrote: > On Tue, Jan 9, 2024 at 12:37 AM Nathan Bossart wrote: >> >> > I suspect that there could be a regression lurking for some inputs >> > that the benchmark doesn't look at: pg_lfind32() currently needs to be >> > able to read 4 vector registers worth of elements before taking the >> > fast path. There is then a tail of up to 15 elements that are now >> > checked one-by-one, but AVX2 would increase that to 31. That's getting >> > big enough to be noticeable, I suspect. It would be good to understand >> > that case (n*32 + 31), because it may also be relevant now. It's also >> > easy to improve for SSE2/NEON for v17. >> >> Good idea. If it is indeed noticeable, we might be able to "fix" it by >> processing some of the tail with shorter vectors. But that probably means >> finding a way to support multiple vector sizes on the same build, which >> would require some work. > > What I had in mind was an overlapping pattern I've seen in various > places: do one iteration at the beginning, then subtract the > aligned-down length from the end and do all those iterations. And > one-by-one is only used if the total length is small. Sorry, I'm not sure I understood this. Do you mean processing the first several elements individually or with SSE2 until the number of remaining elements can be processed with just the AVX2 instructions (a bit like how pg_comp_crc32c_armv8() is structured for memory alignment)? -- Nathan Bossart Amazon Web Services: https://aws.amazon.com