Skip to content

P2728: use buffer capacity 64 for the SIMD performance table #238

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ednolan merged 1 commit into from
Jun 10, 2026
Merged

P2728: use buffer capacity 64 for the SIMD performance table #238

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 13 additions & 12 deletions papers/P2728.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1777,28 +1777,29 @@ the chunk gets filled up, only for the rest of the chunk to get discarded.
The reference implementation's benchmark transcodes the
[unicode_lipsum](https://github.com/lemire/unicode_lipsum) corpora from UTF-16 to
UTF-8. The SIMD implementation uses a prototype kernel written against C++26 `std::simd`
and a buffer capacity of 128 code units. For comparison, the last column is a single bulk
and a buffer capacity of 64 code units. For comparison, the last column is a single bulk
`simdutf` call over the whole corpus, with no view involved. Numbers are GiB/s of input
consumed (GCC 16.1, `-O3 -march=native`, x86-64 AVX2, AMD Ryzen 9 5950X).

| Corpus | Scalar view | Prototype SIMD view | Bulk `simdutf` |
|---|---:|---:|---:|
| Latin | 1.82 | 4.01 | 60.4 |
| Arabic | 0.83 | 1.05 | 10.9 |
| Chinese | 0.73 | 0.99 | 8.9 |
| Japanese | 0.70 | 0.76 | 8.7 |
| Korean | 0.72 | 0.76 | 8.0 |
| Latin | 1.86 | 4.20 | 60.4 |
| Arabic | 0.81 | 0.96 | 10.9 |
| Chinese | 0.82 | 1.00 | 8.9 |
| Japanese | 0.77 | 0.85 | 8.7 |
| Korean | 0.89 | 0.86 | 8.0 |

In the current prototype, we see >2x speedup on the most favorable case, which is ASCII
input, and moderate to small speedups on other corpuses. (Note that the prototype is
input, and either parity or small speedups on other corpuses. (Note that the prototype is
currently in an incomplete state, and only implements the UTF16-UTF8 direction, so results
with other directions may differ). `simdutf` smokes us, mainly due to benefiting from the
bulk API, and we can't approach its speed with a view; we would need to do an algorithm to
achieve comparable performance.\*
with other directions may differ). 64 is the minimum buffer size at which we get favorable
results, for this particular transcoding direction, in my prototype. `simdutf` smokes us,
mainly due to benefiting from the bulk API, and we can't approach its speed with a view;
we would need to do an algorithm to achieve comparable performance.\*

To put these numbers into perspective, the article text of English Wikipedia is roughly
40 GiB in UTF-8, or about 80 GiB in UTF-16, and so would take approximately 44 seconds
to transcode on a single core with the scalar implementation and 20 seconds to
40 GiB in UTF-8, or about 80 GiB in UTF-16, and so would take approximately 43 seconds
to transcode on a single core with the scalar implementation and 19 seconds to
transcode with SIMD, assuming its properties are roughly similar to the Latin corpus
above.

Expand Down
Loading