Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oKOIp-0007fM-Rl for pgsql-hackers@arkaria.postgresql.org; Sat, 06 Aug 2022 18:13:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oKOIn-0000be-Aj for pgsql-hackers@arkaria.postgresql.org; Sat, 06 Aug 2022 18:13:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oKOIm-0000XG-Pr for pgsql-hackers@lists.postgresql.org; Sat, 06 Aug 2022 18:13:32 +0000 Received: from mail-pl1-x62b.google.com ([2607:f8b0:4864:20::62b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oKOIk-00066F-6d for pgsql-hackers@postgresql.org; Sat, 06 Aug 2022 18:13:31 +0000 Received: by mail-pl1-x62b.google.com with SMTP id x10so5259134plb.3 for ; Sat, 06 Aug 2022 11:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc; bh=hpa35KJaMMlmPpbYlMs/LmQGyzTH+M/Tj7dSqhc4M1A=; b=LiUq1TDl4OhWf2QBD20QggHV2p2RU60cN+TZJGW51j4Rkyj+ELiNSj4AsL4b+wQZgb LAQmy0zVT0BWqHJuAoqEOPZqMMOXpKZW6c5+33c7ukuXymq0EkhY4UwS7/thNdJL0qJN aCzIzNI10MZFjM/sErrwpliZwltGu2h2/k86en/6qRRroEmXfhBdQ/lQlarqX1/XnxLW pEwLy92Z39NlxTh9VJmjzegAEXsxyZp45cGNr+wKfEKZ0tk26IZhDDAAbXtN4nop5pws qX2cINuzUqs1uQwQiMEhegwf1uoWekTRgc4fvM6zEZdF4bv498gbAoY3vD3+BmgJ1wUV fXog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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; bh=hpa35KJaMMlmPpbYlMs/LmQGyzTH+M/Tj7dSqhc4M1A=; b=rbrLaXleN8ly0ZdwazxxBN4jvySZR5ISXTsxSGPlVHB4HdYrCLi+h8hUexAfV8ZTOv YteKzKlfQCmJ/+jWuxsVtBBQO5HZTHy+LnUnCqo3nAgI9Gb/VWFw+4nVA/VIjUNz/zWU hb+suNl3Y1DiZO0nk51Exw5rLmp9IOOfP6lnpvX450a8ohkzJGejB449zAQi/gf4NhGf 4A+gH4wIO5IuADxX5xzkD7qR1QW4jn9hPNDl7u6JDkKKK8IvZWdDnCrzuUY+HvMQY4KA 4YQlfrSfo3MwLEzXs9jivgUNro1+BMeKmjODfD/lYn5r2caC7WNmOIswu97U53kLVXTi 2w0Q== X-Gm-Message-State: ACgBeo20LBynVjSCigtV0Dhw405ctvJQhOKMINfDc14+uKs0SPRifM2A VQjgrRHkSed9ptUFzKmG1hI= X-Google-Smtp-Source: AA6agR6IMqBpczDi107s56+cAJAp9WgRal0Pac9OofrkO2lNxkHXjqiO3p9A2n418kCQ7WeFIKLL+g== X-Received: by 2002:a17:902:b612:b0:16c:d98d:638 with SMTP id b18-20020a170902b61200b0016cd98d0638mr11397145pls.38.1659809608701; Sat, 06 Aug 2022 11:13:28 -0700 (PDT) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id d14-20020a170902654e00b0016ed715d244sm5245464pln.300.2022.08.06.11.13.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Aug 2022 11:13:27 -0700 (PDT) Date: Sat, 6 Aug 2022 11:13:26 -0700 From: Nathan Bossart To: Andres Freund Cc: John Naylor , John Naylor , pgsql-hackers Subject: Re: optimize lookups in snapshot [sub]xip arrays Message-ID: <20220806181326.GA1216305@nathanxps13> References: <20220802221301.GA742739@nathanxps13> <20220802225539.nm7bgkwvkpzgib5x@awork3.anarazel.de> <20220802234357.GA802740@nathanxps13> <20220803180658.3ofq6v34wxchg4wc@awork3.anarazel.de> <20220803202540.GA1088968@nathanxps13> <20220804221551.GA1090071@nathanxps13> <20220805202510.GA1208450@nathanxps13> <20220805220434.6h2aa7eww5rxird6@awork3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220805220434.6h2aa7eww5rxird6@awork3.anarazel.de> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Aug 05, 2022 at 03:04:34PM -0700, Andres Freund wrote: > But mainly I'd expect to find a difference if the SIMD code were optimized a > further on the basis of not needing to return the offset. E.g. by > replacing _mm_packs_epi32 with _mm_or_si128, that's cheaper. I haven't been able to find a significant difference between the two. If anything, the _mm_packs_epi* approach actually seems to be slightly faster in some cases. For something marginally more concrete, I compared the two in perf-top and saw the following for the relevant instructions: _mm_packs_epi*: 0.19 │ packssdw %xmm1,%xmm0 0.62 │ packssdw %xmm1,%xmm0 7.14 │ packsswb %xmm1,%xmm0 _mm_or_si128: 1.52 │ por %xmm1,%xmm0 2.05 │ por %xmm1,%xmm0 5.66 │ por %xmm1,%xmm0 I also tried a combined approach where I replaced _mm_packs_epi16 with _mm_or_si128: 1.16 │ packssdw %xmm1,%xmm0 1.47 │ packssdw %xmm1,%xmm0 8.17 │ por %xmm1,%xmm0 Of course, this simplistic analysis leaves out the impact of the surrounding instructions, but it seems to support the idea that the _mm_packs_epi* approach might have a slight edge. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com