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 1oNhYJ-0004Gn-14 for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Aug 2022 21:23:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oNhYH-000762-3z for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Aug 2022 21:23:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oNhYG-00075t-P0 for pgsql-hackers@lists.postgresql.org; Mon, 15 Aug 2022 21:23:12 +0000 Received: from mail-pf1-x436.google.com ([2607:f8b0:4864:20::436]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oNhYD-00019T-5u for pgsql-hackers@postgresql.org; Mon, 15 Aug 2022 21:23:12 +0000 Received: by mail-pf1-x436.google.com with SMTP id 130so7377610pfy.6 for ; Mon, 15 Aug 2022 14:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc; bh=k9JZX3BCkEpkDJ53mql9hkH/6z/dChqj53+5RFZGNzM=; b=imrl+/ecwVYHfpGMjFih3tJxfkbcMjktdLQ1ncyXgd1pSQXMfkqckGP9131kGA1+9t reh/qAzba9S2/6zJfDkit1h9X3GwDYzmTEywZuh75WdugcgTUtexGbBO+6OL2KTqrwvX D2kPSRg9WUV9QTO2mYQeLYmH5Pc1bMNc0xn8CAgLe3aD2o3ZO/jlaiHJeLofDcn9c4+r RaoQ23rBCEmlntv8PgFE5dVInG+9P5ArlWHwaG4BbzZiHDfA9+EQI42Oam1xGwkvUSr7 DGT+lBlzdeEqshQkspOyHokZ7O7tO3KQcgHMZxe0spu1LZ9phzF5oOGFrluG1yeQ9AwL h/DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=k9JZX3BCkEpkDJ53mql9hkH/6z/dChqj53+5RFZGNzM=; b=orIy+KA+1WVm6DzEz/6IkRVKtzj87t7dnfEpmCnhivV32S5Seg0SNaKfVPtBjEuQO6 tArp85l63Z9Fhy+N9tHtwRd+Xx6MCd+zzusEmVhMm3JwtnOxASfTaA8AFTtBuBu9bc06 6fiEZMXxxJtU/Civdwv9N2OlSPuF14QuHUApEu6hpkd8JIFre8vO32e5ZQfUjm5K8dcH XBqYYlnmxAPE9Ppd5ItlFQWmkikwWIhnrVJbAhJxiy1tvqIO5J5/KASFjeIP3a0i98Bb RkFz5LUV+RrJ1rglzwTKhLT/NtgLL2QvHAF6pIbmlm/pntshFIFDGywgeI3J5ViaE7T1 GGNw== X-Gm-Message-State: ACgBeo2uY9D/VxT0I7BhXYJRNhdm5s60unghnuG4dQk52RKnZQhpcbcO kKEvX6JYt4S+wjrGM1RqK/M= X-Google-Smtp-Source: AA6agR4o3DEGM9KQK+GKkor4Hc98rLVyzNP+J88E9pF3i8Ew760RHftHOkFTdhjO8PNytIrsM0KCIw== X-Received: by 2002:a05:6a00:1644:b0:52e:d72c:aadc with SMTP id m4-20020a056a00164400b0052ed72caadcmr18192562pfc.5.1660598587154; Mon, 15 Aug 2022 14:23:07 -0700 (PDT) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id a70-20020a621a49000000b0052e6c073a3csm7195884pfa.142.2022.08.15.14.23.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Aug 2022 14:23:06 -0700 (PDT) Date: Mon, 15 Aug 2022 14:23:04 -0700 From: Nathan Bossart To: John Naylor Cc: Andres Freund , Tom Lane , Jelte Fennema , "pgsql-hackers@postgresql.org" , Merlin Moncure , Andrew Dunstan , Stephen Frost Subject: Re: [PATCH] Optimize json_lex_string by batching character copying Message-ID: <20220815212304.GA251709@nathanxps13> References: <20220625001810.q4giojmraweoyl5e@alap3.anarazel.de> <20220625010551.r5qrk5n2euuwqos3@alap3.anarazel.de> <20220706051801.gfbzjxgflbsglyt6@awork3.anarazel.de> <20220711154150.hwzw7qw2k6iahofy@awork3.anarazel.de> <1119852.1657554806@sss.pgh.pa.us> <20220711160728.tljbnowfgxefdbli@awork3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Aug 15, 2022 at 08:33:21PM +0700, John Naylor wrote: > The attached implements the above, more or less, using new pg_lfind8() > and pg_lfind8_le(), which in turn are based on helper functions that > act on a single vector. The pg_lfind* functions have regression tests, > but I haven't done the same for json yet. I went the extra step to use > bit-twiddling for non-SSE builds using uint64 as a "vector", which > still gives a pretty good boost (test below, min of 3): Looks pretty reasonable to me. > +#ifdef USE_SSE2 > + chunk = _mm_loadu_si128((const __m128i *) &base[i]); > +#else > + memcpy(&chunk, &base[i], sizeof(chunk)); > +#endif /* USE_SSE2 */ > +#ifdef USE_SSE2 > + chunk = _mm_loadu_si128((const __m128i *) &base[i]); > +#else > + memcpy(&chunk, &base[i], sizeof(chunk)); > +#endif /* USE_SSE2 */ Perhaps there should be a macro or inline function for loading a vector so that these USE_SSE2 checks can be abstracted away, too. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com