gh-124951: Optimize base64 encode & decode for an easy 2-3x speedup [no SIMD] #143262
+134
−23
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add Tools/binasciibench/binasciibench.py benchmark for measuring base64
encoding/decoding throughput.
Optimize base64 encoding/decoding by eliminating loop-carried dependencies.
Key changes:
- Add base64_encode_trio() and base64_decode_quad() helper functions
that process complete groups independently
- Add base64_encode_fast() and base64_decode_fast() wrappers
- Update b2a_base64 and a2b_base64 to use fast path for complete groups
Performance gains (encode/decode speedup vs main, PGO builds):
64 bytes 64K 1M
Zen2: 1.1x/1.6x 1.6x/2.4x 1.4x/2.4x
Zen4: 1.2x/1.7x 1.6x/3.0x 1.5x/3.0x
M4: 1.3x/1.9x 2.3x/2.8x 2.4x/2.9x
RPi5-32: 1.4x/1.4x 2.4x/2.0x 2.0x/1.9x
Additional SIMD implementations (NEON, AVX-512 VBMI) can achieve
+50% to +1500% further gains and are planned for follow-on work.
Co-authored-by: Claude Opus 4.5 <[email protected]>
gpshead
force-pushed
the
opt-base64-cpu
branch
from
f15ad3e to
2d2be30
Compare
gpshead
changed the title
gpshead
changed the title
gpshead
changed the title
MSVC doesn't support forward declarations of arrays without explicit size. Move the table definition before the inline functions that use it, eliminating the need for a forward declaration. Co-authored-by: Claude Opus 4.5 <[email protected]>
picnixz
reviewed
Dec 29, 2025
Co-authored-by: Bénédikt Tran <[email protected]>
Add Py_ALIGNED(64) to both lookup tables to ensure each fits within a single L1 cache line, reducing potential cache misses during encoding/decoding loops. Co-authored-by: Claude Opus 4.5 <[email protected]>
Replace hardcoded '=' characters with the BASE64_PAD macro for consistency with the rest of the codebase. Co-authored-by: Claude Opus 4.5 <[email protected]>
Co-authored-by: Claude Opus 4.5 <[email protected]>
gpshead
force-pushed
the
opt-base64-cpu
branch
from
aad7a15 to
1f8ff74
Compare
gpshead
commented
Dec 29, 2025
Member
serhiy-storchaka
left a comment
serhiy-storchaka
left a comment
There was a problem hiding this comment.
Looks pretty simple with large benefit.
BTW, I'm going to add support for ignorechars in the decoder, so it could support a multiline input without ignoring all other errors. The decoder will return on the fast path for each line.
Address review feedback from serhiy-storchaka: the fast path was doing two checks per group - an explicit PAD comparison and the invalid char check in base64_decode_quad(). Change PAD's table entry from 0 to 64 so the existing (v0|v1|v2|v3)&0xc0 check catches it, eliminating 4 comparisons per group. The slow path is unaffected since it checks for PAD character before the table lookup. Decode is ~16% faster at 64K (1.62 GB/s → 1.88 GB/s). Co-authored-by: Claude Opus 4.5 <[email protected]>
Suggested by serhiy-storchaka: replace index math (in + i*3, out + i*4) with pointer increments. Encode is ~7% faster at 64K (2.11 → 2.25 GB/s). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
| Py_ssize_t i; | ||
|
|
||
| for (i = 0; i < n_quads; i++) { | ||
| if (!base64_decode_quad(in + i * 4, out + i * 3, table)) { |
Member
There was a problem hiding this comment.
Did incrementing in and out by 4 and 3 have any benefit?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Optimize base64 encoding/decoding by eliminating loop-carried dependencies. Key changes:
base64_encode_trio()andbase64_decode_quad()helper functions that process complete groups independentlybase64_encode_fast()andbase64_decode_fast()wrappersb2a_base64anda2b_base64to use fast path for complete groupsThe binasciibench I used measuring base64 encoding/decoding throughput is included in commit history, but i pulled it out of the PR in favor of adding to pyperformance.
Performance gains (encode/decode speedup vs main, PGO builds):
Additional SIMD implementations (NEON, AVX-512 VBMI) can achieve +50% (M4) to +1500% (!! Zen4) further gains and are planned for follow-on work if deemed simple to maintain.
Widely used third party libraries contain industry canonical SIMD accelerated variants such as simdutf (C++ based unfortunately) so the decision of how to link and use those and when is best kept separate.
This PR's simple pure better use of modern CPU functional unit pipelining wins make sense regardless.
Based on my exploratory work done in main...gpshead:cpython:claude/vectorize-base64-c-S7Hku
base64module: Link against SIMD library for 10x performance. #124951