From: David Laight <david.laight.linux@gmail.com>
To: Guan-Chun Wu <409411716@gms.tku.edu.tw>
Cc: akpm@linux-foundation.org, axboe@kernel.dk,
ceph-devel@vger.kernel.org, ebiggers@kernel.org, hch@lst.de,
home7438072@gmail.com, idryomov@gmail.com, jaegeuk@kernel.org,
kbusch@kernel.org, linux-fscrypt@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
sagi@grimberg.me, tytso@mit.edu, visitorckw@gmail.com,
xiubli@redhat.com
Subject: Re: [PATCH v2 1/5] lib/base64: Replace strchr() for better performance
Date: Fri, 12 Sep 2025 23:54:56 +0100 [thread overview]
Message-ID: <20250912235456.6ba2c789@pumpkin> (raw)
In-Reply-To: <20250911073204.574742-1-409411716@gms.tku.edu.tw>
On Thu, 11 Sep 2025 15:32:04 +0800
Guan-Chun Wu <409411716@gms.tku.edu.tw> wrote:
> From: Kuan-Wei Chiu <visitorckw@gmail.com>
>
> The base64 decoder previously relied on strchr() to locate each
> character in the base64 table. In the worst case, this requires
> scanning all 64 entries, and even with bitwise tricks or word-sized
> comparisons, still needs up to 8 checks.
>
> Introduce a small helper function that maps input characters directly
> to their position in the base64 table. This reduces the maximum number
> of comparisons to 5, improving decoding efficiency while keeping the
> logic straightforward.
>
> Benchmarks on x86_64 (Intel Core i7-10700 @ 2.90GHz, averaged
> over 1000 runs, tested with KUnit):
>
> Decode:
> - 64B input: avg ~1530ns -> ~126ns (~12x faster)
> - 1KB input: avg ~27726ns -> ~2003ns (~14x faster)
>
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> Co-developed-by: Guan-Chun Wu <409411716@gms.tku.edu.tw>
> Signed-off-by: Guan-Chun Wu <409411716@gms.tku.edu.tw>
> ---
> lib/base64.c | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/lib/base64.c b/lib/base64.c
> index b736a7a43..9416bded2 100644
> --- a/lib/base64.c
> +++ b/lib/base64.c
> @@ -18,6 +18,21 @@
> static const char base64_table[65] =
> "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
>
> +static inline const char *find_chr(const char *base64_table, char ch)
> +{
> + if ('A' <= ch && ch <= 'Z')
> + return base64_table + ch - 'A';
> + if ('a' <= ch && ch <= 'z')
> + return base64_table + 26 + ch - 'a';
> + if ('0' <= ch && ch <= '9')
> + return base64_table + 26 * 2 + ch - '0';
> + if (ch == base64_table[26 * 2 + 10])
> + return base64_table + 26 * 2 + 10;
> + if (ch == base64_table[26 * 2 + 10 + 1])
> + return base64_table + 26 * 2 + 10 + 1;
> + return NULL;
> +}
That's still going to be really horrible with random data.
You'll get a lot of mispredicted branch penalties.
I think they are about 20 clocks each on my Zen-5.
A 256 byte lookup table might be better.
However if you assume ascii then 'ch' can be split 3:5 bits and
the top three used to determine the valid values for the low bits
(probably using shifts of constants rather than actual arrays).
So apart from the outlying '+' and '/' (and IIRC there is a variant
that uses different characters) which can be picked up in the error
path; it ought to be possible to code with no conditionals at all.
To late at night to write (and test) an implementation.
David
> +
> /**
> * base64_encode() - base64-encode some binary data
> * @src: the binary data to encode
> @@ -78,7 +93,7 @@ int base64_decode(const char *src, int srclen, u8 *dst)
> u8 *bp = dst;
>
> for (i = 0; i < srclen; i++) {
> - const char *p = strchr(base64_table, src[i]);
> + const char *p = find_chr(base64_table, src[i]);
>
> if (src[i] == '=') {
> ac = (ac << 6);
next prev parent reply other threads:[~2025-09-12 22:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-11 7:29 [PATCH v2 0/5] lib/base64: add generic encoder/decoder, migrate users Guan-Chun Wu
2025-09-11 7:32 ` [PATCH v2 1/5] lib/base64: Replace strchr() for better performance Guan-Chun Wu
2025-09-11 15:50 ` Caleb Sander Mateos
2025-09-11 16:02 ` Caleb Sander Mateos
2025-09-11 16:25 ` Kuan-Wei Chiu
2025-09-11 16:38 ` Kuan-Wei Chiu
2025-09-14 20:12 ` David Laight
2025-09-15 7:50 ` Kuan-Wei Chiu
2025-09-15 11:02 ` David Laight
2025-09-16 7:22 ` Kuan-Wei Chiu
2025-09-11 18:14 ` Eric Biggers
2025-09-11 18:44 ` Kuan-Wei Chiu
2025-09-11 18:49 ` Eric Biggers
2025-09-11 19:00 ` Kuan-Wei Chiu
2025-09-13 21:27 ` David Laight
2025-09-12 22:54 ` David Laight [this message]
2025-09-11 7:41 ` [PATCH v2 2/5] lib/base64: rework encoder/decoder with customizable support and update nvme-auth Guan-Chun Wu
2025-09-11 15:59 ` Caleb Sander Mateos
2025-09-12 7:21 ` Guan-Chun Wu
2025-09-11 18:27 ` Eric Biggers
2025-09-12 6:37 ` FIRST_NAME LAST_NAME
2025-09-12 6:52 ` Guan-Chun Wu
2025-09-12 7:15 ` Guan-Chun Wu
2025-09-11 7:45 ` [PATCH v2 3/5] lib: add KUnit tests for base64 encoding/decoding Guan-Chun Wu
2025-09-11 7:45 ` [PATCH v2 4/5] fscrypt: replace local base64url helpers with generic lib/base64 helpers Guan-Chun Wu
2025-09-11 18:47 ` Eric Biggers
2025-09-12 7:51 ` Guan-Chun Wu
2025-09-11 7:46 ` [PATCH v2 5/5] ceph: replace local base64 encode/decode " Guan-Chun Wu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250912235456.6ba2c789@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=409411716@gms.tku.edu.tw \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=ceph-devel@vger.kernel.org \
--cc=ebiggers@kernel.org \
--cc=hch@lst.de \
--cc=home7438072@gmail.com \
--cc=idryomov@gmail.com \
--cc=jaegeuk@kernel.org \
--cc=kbusch@kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=tytso@mit.edu \
--cc=visitorckw@gmail.com \
--cc=xiubli@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.