public inbox for [email protected]
help / color / mirror / Atom feedFrom: John Naylor <[email protected]>
To: Oleg Tselebrovskiy <[email protected]>
Cc: Andrew Kim <[email protected]>
Cc: [email protected]
Subject: Re: Proposal for enabling auto-vectorization for checksum calculations
Date: Thu, 15 Jan 2026 17:35:36 +0700
Message-ID: <CANWCAZZhyyieM9LSELXTuvh1qoAY0frmcEnSh9d4KzBbahQvRQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<CANWCAZYZQw-nzTXbx3Bk332VtY9_D7ksDsuMZ0A-iDZ53yG7Ng@mail.gmail.com>
<CAK64mnfeWLBRbMfnOsag0vGTDnT84KJzpuei40nG0OHyw4SESw@mail.gmail.com>
<CANWCAZa1b2rcvoK657SmcKwh2P2cgASQ1D-0JPj5d3LbfaAVgA@mail.gmail.com>
<CAK64mneN20+sW5WhV+r7hMVo4Rd0z11B6=3L039rWMt1wK3nPg@mail.gmail.com>
<CANWCAZZuS3sNgLRo8Z4AM=uY4zTmz=dH5D4Z9xV6K0CEuJ8Hdw@mail.gmail.com>
<CAK64mnejn9AZMYz03e7HX8Uui35PihUuOy=b+iBG=YtRKx0Log@mail.gmail.com>
<CANWCAZZ_0AQMk1HgHXHX+JaeBfy_4kzwHgTdqMptDA7zM+nm+Q@mail.gmail.com>
<CAK64mnc6jbehHv5AHc84tVFRJg4zeMiFuvPX9xZkRpq0210MFA@mail.gmail.com>
<CANWCAZY940P3wGOQAZWMLQL4MQGGyOu7WBjBEcn_gqcrr+NvAw@mail.gmail.com>
<CAK64mne_oWN9d4mf+0c_5-4Emb9kRXA-OC05OJ4F_1fVqpjzDA@mail.gmail.com>
<CANWCAZZcKYp+01u1QmkShfXVkUCCdxtJAgHT-61Vw0ALoWj47A@mail.gmail.com>
<CAK64mne=Q_4VSpJ8f4RQB-yAThd4+i-BRYMvfdGOhvwJQdYoKQ@mail.gmail.com>
<CANWCAZYg2MVbYTaczNYNC2kaPodtfB8toUfE2Mhp9kut=2wzEA@mail.gmail.com>
<CAK64mnd9NE+xE18shrf-SSx-iwMVof=2DJ2y9_fOkQ5E2Abc5g@mail.gmail.com>
<CANWCAZbjdFnBiUmrBQC5vFFy0Fnn4SJG4AkkzGpTFhovodJdYQ@mail.gmail.com>
<[email protected]>
On Thu, Jan 15, 2026 at 3:04 PM Oleg Tselebrovskiy
<[email protected]> wrote:
> > So in v10 I separated the body of checksum_block to
> > a semi-private header to provide hardware-specific definitions
> > for core code, while also maintaining the same one that
> > external code expects
>
> I like the usage of a semi-internal header, less code duplication
> is always good
Glad to hear it.
> If I understand correctly, with how code is currently,
> external programms can define PG_CHECKSUM_INTERNAL manually,
> but then they won't have access to static functions inside of
> checksum.c, so all you get is a pointer that leads nowhere, correct?
Sounds right, but I'm not sure why an external program would define
it, because it's named...drumroll.."internal".
> I'd like to think that speeding up checksum calculation is something
> that some external programms could appreciate.
External programs are probably doing some one-off task, so I don't see
a reason to work harder.
> Also, not moving all those checksum files to src/port saves us from
> thinking about problems with meson and current external programs,
> but, I think, that after hardware checks are refactored, we could
> revisit the question of moving checksum[_impl].h/.c to src/port.
Refactoring the hardware checks is not going to make those two
problems go away, and I don't understand why you want to move anything
to begin with.
--
John Naylor
Amazon Web Services
view thread (15+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Proposal for enabling auto-vectorization for checksum calculations
In-Reply-To: <CANWCAZZhyyieM9LSELXTuvh1qoAY0frmcEnSh9d4KzBbahQvRQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox