Skip to content
Merged
Changes from all commits
Commits
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
50 changes: 49 additions & 1 deletion papers/P2728.md
Original file line number Diff line number Diff line change
Expand Up @@ -1202,6 +1202,54 @@ There's precedent for this kind of approach in the `views::reverse` CPO, which s
gives back the original underlying view if it detects that it's reversing another
`reverse_view`.

## Why no SIMD support?

I created an experimental implementation with SIMD support for UTF-16 to UTF-8
transcoding, using a 64-byte readahead buffer, and benchmarked it against both
the scalar implementation and the highly optimized bulk `simdutf` library by
Daniel Lemire et al., obtaining the following numbers in 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.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 |

The inputs used were Daniel Lemire's
[unicode_lipsum](https://github.com/lemire/unicode_lipsum) corpora.

The reason the performance improvements are so limited is that a view delivers
its output one code unit at a time: every element costs an iterator increment,
a dereference, and a buffer-index check, no matter how cheaply the buffer was
filled. SIMD accelerates only the buffer refill; once that cost is amortized
away, throughput is bounded by the per-element delivery loop. That leads to the
relatively disappointing results seen above as compared to `simdutf`, which has
an eager, algorithm-style API instead of a view API.

In addition to the comparatively unimpressive performance numbers, some SG9
reviewers were also concerned that the SIMD implementation needed to eagerly
buffer more readahead than the UTF transcoding algorithm strictly requires in
order to fill a SIMD register, which some considered to violate the spirit of
laziness that the view library is designed around.

Furthermore, we have a potential mechanism for adding SIMD support later if we
change our minds, by adding a new enumerator to `to_utf_view_kind`.

Based on this information, SG9 voted against supporting SIMD:

**Poll: We want to leave implementations the freedom to eagerly buffer more code units to allow a SIMD transcoding technique.**

SF| F | N | A | SA
---|---|---|---|---
0| 0 | 3 | 3 | 1

Attendance: 8
Author: N
Strong consensus against.

## `.base_code_units()`

### Proposal
Expand Down Expand Up @@ -1588,7 +1636,7 @@ An experimental implementation of `.base_code_units()` is available on the

## Changes since R14

- Revert SIMD support
- Revert SIMD support and add design discussion of why it was rejected

## Changes since R13

Expand Down
Loading