Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: High-speed UTF-8 validation in Rust

github.com

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Show HN: High-speed UTF-8 validation in Rust

#31

Post by celeritascelery »

unwind wrote: post #29
celeritascelery wrote: post #28

> The implementation is similar to the one in simdjson except that it aligns reads to the block size of the SIMD extension, which leads to better peak performance compared to the implementation in simdjson. I didn't really understand this part. Aligned to what? to the cache line? SIMD always reads the block size. Unless I am missing something here.

I read it as "to the width of the SIMD registers" which I have seen in other quick scanners, but did not read the code here.

Aren’t all reads aligned to the width of the SIMD register? If I do an AVX512 command it will read 512 bits right?

Re: Show HN: High-speed UTF-8 validation in Rust

#32

Post by jsheard »

celeritascelery wrote: post #31
unwind wrote: post #29

Earlier quoted context omitted.

I read it as "to the width of the SIMD registers" which I have seen in other quick scanners, but did not read the code here.

Aren’t all reads aligned to the width of the SIMD register? If I do an AVX512 command it will read 512 bits right?

It's about where you read data from, not how much data gets read. For example an AVX read is aligned if the address being read from is a multiple of 32 bytes, otherwise it's unaligned and runs slightly slower, and slower still if it happens to straddle two cachelines. The same applies to write instructions as well.

It's less of an issue than it used to be, the penalty for unaligned access has steadily been reduced by newer CPU architectures, but it's still there.

Re: Show HN: High-speed UTF-8 validation in Rust

#33

Post by celeritascelery »

monocasa wrote: post #30
celeritascelery wrote: post #27

I find it interesting that with the state of rust SIMD many implementations just opted for reimplementing the code multiple times for each intrinsic (SSE, Neon, AVX, etc). One would think that one of the generic libraries (faster, simdeez, packed_simd) would start to see widespread use, but they all seem to have issues that have prevented adoption.

The various SIMD ISAs are different enough from eachother that you really want a custom implementation per ISA for perf reasons. Particularly if you're doing something off the beaten path like this rather than cranking through some vector math.

I don't know. Looking in their code, they have one for SSE and another for AVX2. The algorithm is identical expect for one is 128 and the other is 256 bits. It seems like something that would be easy to abstract over so you only had a single implementation (at least for x86 SIMD). But it is obviously a hard problem or it would be solved already.

Re: Show HN: High-speed UTF-8 validation in Rust

#34

Post by celeritascelery »

jsheard wrote: post #32
celeritascelery wrote: post #31

Earlier quoted context omitted.

Aren’t all reads aligned to the width of the SIMD register? If I do an AVX512 command it will read 512 bits right?

It's about where you read data from, not how much data gets read. For example an AVX read is aligned if the address being read from is a multiple of 32 bytes, otherwise it's unaligned and runs slightly slower, and slower still if it happens to straddle two cachelines. The same applies to write instructions as well. It's less of an issue than it used to be, the penalty for unaligned access has steadily been reduced by…

ahh, so it does come back to cache line alignment. Reading aligned data doesn't give any benefit in and of itself[1]. At least not on modern hardware. I guess the performance improvement would make sense since SIMD instructions are sized to be a multiple of the cache line size.

[1] https://lemire.me/blog/2012/05/31/data-alignment-for-speed-m...

Re: Show HN: High-speed UTF-8 validation in Rust

#35

Post by BelenusMordred »

celeritascelery wrote: post #27

I find it interesting that with the state of rust SIMD many implementations just opted for reimplementing the code multiple times for each intrinsic (SSE, Neon, AVX, etc). One would think that one of the generic libraries (faster, simdeez, packed_simd) would start to see widespread use, but they all seem to have issues that have prevented adoption.

packed_simd is now packed_simd2, the original author is MIA and no one else has crate or repo permissions

I really think the general push right now is towards stdsimd being the future for portability.

Re: Show HN: High-speed UTF-8 validation in Rust

#36

Post by Fronzie »

monocasa wrote: post #30
celeritascelery wrote: post #27

I find it interesting that with the state of rust SIMD many implementations just opted for reimplementing the code multiple times for each intrinsic (SSE, Neon, AVX, etc). One would think that one of the generic libraries (faster, simdeez, packed_simd) would start to see widespread use, but they all seem to have issues that have prevented adoption.

The various SIMD ISAs are different enough from eachother that you really want a custom implementation per ISA for perf reasons. Particularly if you're doing something off the beaten path like this rather than cranking through some vector math.

Even for vector math, there are subtle differences, such as the numerical precision of the hardware reciprocal, leading to different implementations for x/y.

The Eigen library did recently combine most SSE and AVX code paths, however: https://eigen.tuxfamily.org/index.php?title=3.4

Re: Show HN: High-speed UTF-8 validation in Rust

#38

Post by cryptonector »

chrismorgan wrote: post #20
tialaramex wrote: post #6

One flavour I would expect to be valuable that isn't present here is this: Process the input (as quickly as possible) and never fail, but replace each invalid sequence of bytes with U+FFFD (bytes 0xEF 0xBF 0xBD).

One major problem with this: you can’t do it in place. Invalid byte sequences could be 1–4 bytes long, but U+FFFD is exactly three bytes long.

Use an ASCII character like `?` or, even better, ASCII SUB (0x1A, substitute), which is specifically intended for this sort of thing. Failing that, there are a number of other unused ASCII control characters like VT (vertical tab), FS (file separator), GS (group separator), US (unit separator), CAN (cancel), etc.

Re: Show HN: High-speed UTF-8 validation in Rust

#39

Post by cryptonector »

jfk13 wrote: post #14

I'd be curious how this compares with the encoding_rs crate ( https://github.com/hsivonen/encoding_rs ), which also offers UTF-8 validation (among many other things).

This is SIMD based. If the encoding_rs crate isn't SIMD based, then this thing will beat its pants off.

Re: Show HN: High-speed UTF-8 validation in Rust

#40

Post by mooman219 »

celeritascelery wrote: post #27

I find it interesting that with the state of rust SIMD many implementations just opted for reimplementing the code multiple times for each intrinsic (SSE, Neon, AVX, etc). One would think that one of the generic libraries (faster, simdeez, packed_simd) would start to see widespread use, but they all seem to have issues that have prevented adoption.

I work on a SIMD optimized font library [0] and have stumbled into the same situation of hand writing SIMD intrinsics. Some things are just kinda hard to make sure they get optimized correctly, and there is enough difference between the platforms where that matters when fiddling with bits. I also kinda have fun writing SIMD code like this too.

[0]: https://github.com/mooman219/fontdue/blob/master/src/platfor...

Post reply on HN