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 1pbpuE-0000xA-9e for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Mar 2023 21:40:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pbpuD-0003Tm-5U for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Mar 2023 21:40: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 1pbpuC-0003Td-SN for pgsql-hackers@lists.postgresql.org; Mon, 13 Mar 2023 21:40:32 +0000 Received: from mail-pg1-x535.google.com ([2607:f8b0:4864:20::535]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pbpuA-0000r2-DC for pgsql-hackers@lists.postgresql.org; Mon, 13 Mar 2023 21:40:31 +0000 Received: by mail-pg1-x535.google.com with SMTP id z10so7778005pgr.8 for ; Mon, 13 Mar 2023 14:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678743629; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=kkDIPs2Ry+Cb8Lhf62vaH5ViDdB+qsXk9nEmMNDipsk=; b=n7xYttDuvrq91RBbb1kCgyFd06R53EZq22kB4S+n6ogqN4z3UOcrQsD5Uvg0usEg1q Td7MCQzjuvIEHd8XJ3frzWXpGp+oJtBdctRdpNtQO1t4NizlnTxdG+WJVhY+F9uKwhhJ DhgA6SwJM9DiFs1UxkYidBLFe+mhUSkYv7Oug49gniFVe0V6y7HVtFgaWA+jvcw9XIf2 GLHidfJN1e/7ShmS/T1AriMhjpKMlMxbxHO7tVcFjY4cYfp70++IiOeJyZQsbS9FQ6KX WemvLSaTeRJzxB2oAJGiVaXMnO5+7Hh9xvRlaQERKX8QzFlGkCMytIVUJyfy3aEEKxEv 9B6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678743629; h=in-reply-to: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=kkDIPs2Ry+Cb8Lhf62vaH5ViDdB+qsXk9nEmMNDipsk=; b=M8unpkRfMz2bwv4ELy3n1wnKn5vB2mu87rJLMYYMxJHzukd4gwA6t6a7ZEvY4gSHiZ oTRzUwi2PUsQTnkDuYyQ3VtWeOB0DYWyE5VedcyEHJ272MgGwo6gOjvXYcN+SJsL+u60 Nca/LpZIJGLK876hNzvqqeyoLYWB8m/EaNf143/6gvFdpI2eXG00wgADZNZBAnVk3wrE 7V6BzBKtfzIgkjs8oB/Ip1iPxzRIN43q3jdCzvrUHkNz3rN9udUoUNFIZhYE1F7fSYhK PRF7wi4t3R+84WEusUVla6RhuToflXFifZMsS2ALR/dtlW2lJxww3J0MDGhkg22vvurk UcUA== X-Gm-Message-State: AO0yUKWm51opkWHMzrUQ56L7ZwjBGddUsTMsvOcqMq79GuCqtTUqEXsf oYd0MN5QI3502Arq1dY5Hzk= X-Google-Smtp-Source: AK7set+MHjkD4zTtFLUp5yFYoV3prNnMHZnv3X72OQQsuEQeJvRrbTeFO8iMVKbe3mGnPu6UgVoapw== X-Received: by 2002:aa7:94ae:0:b0:623:2bba:dd9 with SMTP id a14-20020aa794ae000000b006232bba0dd9mr5470179pfl.14.1678743629382; Mon, 13 Mar 2023 14:40:29 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id q9-20020a63cc49000000b00502fd70b0bdsm185576pgi.52.2023.03.13.14.40.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Mar 2023 14:40:28 -0700 (PDT) Date: Mon, 13 Mar 2023 14:40:27 -0700 From: Nathan Bossart To: Ankit Kumar Pandey Cc: pgsql-hackers@lists.postgresql.org Subject: Re: optimize several list functions with SIMD intrinsics Message-ID: <20230313214027.GB423713@nathanxps13> References: <20230308002502.GA3378449@nathanxps13> <20230308185809.GA3552675@nathanxps13> <167852767890.628976.10354523915450248589.pgcf@coridan.postgresql.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <167852767890.628976.10354523915450248589.pgcf@coridan.postgresql.org> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thanks for taking a look. On Sat, Mar 11, 2023 at 09:41:18AM +0000, Ankit Kumar Pandey wrote: > 1. In list_member_ptr, will it be okay to bring `const ListCell *cell` from > #ifdef USE_NO_SIMD > const ListCell *cell; > #endif > to #else like as mentioned below? This will make visual separation between #if cases more cleaner I would expect to see -Wdeclaration-after-statement warnings if we did this. > 2. Lots of duplicated > if (list == NIL) checks before calling list_member_inline_internal(list, datum) > Can we not add this check in list_member_inline_internal itself? We probably could. I only extracted the NIL checks to simplify the code in list_member_inline_internal() a bit. > 3. if (cell) > return list_delete_cell(list, cell) in list_delete_int/oid > can we change if (cell) to if (cell != NULL) as used elsewhere? Sure. > 4. list_member_inline_interal_idx , there is typo in name. Will fix. > 5. list_member_inline_interal_idx and list_member_inline_internal are practically same with almost 90+ % duplication. > can we not refactor both into one and allow cell or true/false as return? Although I see usage of const ListCell so this might be problematic. The idea was to skip finding the exact match if all we care about is whether the element exists. This micro-optimization might be negligible, in which case we could use list_member_inline_internal_idx() for both cases. > 6. Loop for (i = 0; i < tail_idx; i += nelem_per_iteration) for Vector32 in list.c looks duplicated from pg_lfind32 (in pg_lfind.h), can we not reuse that? The list.c version is slightly different because we need to disregard any matches that we find in between the data. For example, in an integer List, the integer will take up 4 bytes of the 8-byte ListCell (for 64-bit platforms). typedef union ListCell { void *ptr_value; int int_value; Oid oid_value; TransactionId xid_value; } ListCell; -- Nathan Bossart Amazon Web Services: https://aws.amazon.com