[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D42705E6-94D3-4E3B-9BA8-AFFCE4B8E4E4@meta.com>
Date: Tue, 21 Nov 2023 19:59:29 +0000
From: Nick Terrell <terrelln@...a.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: Nick Terrell <terrelln@...a.com>,
Nick Terrell <nickrterrell@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Yann Collet <cyan@...a.com>,
Kernel Team <kernel-team@...a.com>,
Giovanni Cabiddu <giovanni.cabiddu@...el.com>,
Nick Terrell <terrelln@...a.com>
Subject: Re: [PATCH 2/2] zstd: Backport Huffman speed improvement from
upstream
> On Nov 21, 2023, at 12:23 PM, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
> !-------------------------------------------------------------------|
> This Message Is From an External Sender
>
> |-------------------------------------------------------------------!
>
> On Mon, 20 Nov 2023 at 16:52, Nick Terrell <nickrterrell@...il.com> wrote:
>>
>> +/* Calls X(N) for each stream 0, 1, 2, 3. */
>> +#define HUF_4X_FOR_EACH_STREAM(X) \
>> + { \
>> + X(0) \
>> + X(1) \
>> + X(2) \
>> + X(3) \
>> + }
>> +
>> +/* Calls X(N, var) for each stream 0, 1, 2, 3. */
>> +#define HUF_4X_FOR_EACH_STREAM_WITH_VAR(X, var) \
>> + { \
>> + X(0, (var)) \
>> + X(1, (var)) \
>> + X(2, (var)) \
>> + X(3, (var)) \
>> + }
>> +
>
> What shitty compilers do you need to be compatible with?
>
> Because at least for Linux, the above is one single #define:
>
> #define FOUR(X,y...) do { \
> X(0,##y); X(1,##y); X(2,##y); X(3,##y); \
> } while (0)
>
> and it does the right thing for any number of arguments, ie
>
> FOUR(fn)
> FOUR(fn1,a)
> FOUR(fn2,a,b)
>
> expands to
>
> do { fn(0); fn(1); fn(2); fn(3); } while (0)
> do { fn1(0,a); fn1(1,a); fn1(2,a); fn1(3,a); } while (0)
> do { fn2(0,a,b); fn2(1,a,b); fn2(2,a,b); fn2(3,a,b); } while (0)
>
> so unless you need to support some completely garbage compiler
> upstream, please just do the single #define.
Upstream zstd maintains strict C89 compatibility. We do use compiler
extensions when available, but only when we can detect the feature and
provide a correct fallback when it isn’t available. E.g. __builtin_ctz().
Empty variadic macros fails our C89 compatibility CI, as well as our
Visual Studios CI [0].
We’ve discussed dropping C89 support. The consensus was that
if we were starting the project today we’d stick to C11, but that it is
worth keeping C89 support for Zstd. We’ve seen people compile
zstd in some wacky environments.
W.r.t. do { } while (0), our older Visual Studios CI jobs failed on the
do { } while (0) macros, because it complained about constant false
branches. However, it looks like our current Visual Studios CI jobs
accept do { } while (0) [1]. So I’ve opened an upstream issue to
modernize all of macros [2].
Best,
Nick Terrell
[0] https://github.com/terrelln/zstd/pull/3
[1] https://github.com/terrelln/zstd/pull/4
[2] https://github.com/facebook/zstd/issues/3830
> Linus
Powered by blists - more mailing lists