Aarch64 optimized UTF-8 validator

[kozross]

This addresses #417, specifically regarding a NEON SIMD implementation. I haven't benchmarked this (there aren't any for UTF-8 encoding and decoding specifically), but this implementation is based on the same principles as the ones used for the x86 ones, and should be fairly fast.

I also had to bump the Cabal version requirements to 2.2, so that I could use elif without it erroring.

On a related note: should there be some benchmarks for validator speed? If so, which data should we test against?

[Bodigrim]

@ethercrow @0xd34df00d @vdukhovni could you possibly take a look at C code?

[vdukhovni]

I'm afraid i am not familiar with arm intrinsics and don't have the cycles to come up to speed. So won't be able to do a thorough review of the C code in question. It would need to be a literate program that explained all the registers and instructions involved with a hefty prose to code ratio to make it possible for casual newbies like me to come to grips with it. :-(

[Bodigrim]

@kozross while we are trying to source reviews, let's create a small benchmark set. I suggest to form a data set by downloading wiki pages in various languages, both raw HTML and content text only. According to https://en.wikipedia.org/wiki/Wikipedia:Copyrights such files should contain a link to the source somewhere.

[kozross]

@Bodigrim Should I add these benchmarks to this PR, or make a separate one? I assume a separate one would be better.

[Bodigrim]

Separate PR, please.

[0xd34df00d]

Neither am I familiar with Neon, unfortunately. C in general looks good to me (modulo a couple of very minor, rather stylistic nitpicks), and I've asked a couple of folks that know Neon to take a look if they have time.

[ethercrow]

Hello together,

I also have no experience with Neon, so can't meaningfully review from that angle.

The chunk size here is 64 bytes and validating strings shorter than that is handled by the scalar version is_valid_utf8_fallback.

Naively I would think that bytestring_is_valid_utf8 should delegate to is_valid_utf8_fallback as quickly as possible when len < 64 so avoid the overhead of loading the LUTs and initializing state for the SIMD algorithm. I don't know how much of it matters in the presence of an optimizing compiler and CPU smartness, but let's have a benchmark about short strings. E.g. take a typical JSON response from Twitter or GitHub API or something like that and measure how much it takes to validate all the strings there.

[kozross]

@ethercrow In my experience, the overhead in the situation you describe is basically zero. Furthermore, for bytestrings that short, even if the overhead was meaningful, I don't think we're that worried. I haven't benchmarked this difference in particular though, since all my previous work (for text) dealt only with its benches, all of which had much larger inputs than 64 bytes.

Also, I'm fairly sure a typical response from Twitter or GitHub API would be considerably larger than this; tweets exceed 100 characters just in their text fairly regularly nowadays, for example.

[Bodigrim]

Approving on the basis that it passes tests on ARM CI.

[sjakobi]

What's the reason for the increased Cabal-Version constraint?

[kozross]

Originally I raised it to 2.* because I needed elif. I guess I changed it back to too high a number.

[sjakobi]

In this case, please revert to the original setting.

[Bodigrim]

@kozross could you please revert to Cabal-Version: >= 1.10? I'd like to merge the branch.

[Bodigrim]

Thanks @kozross for your heroic efforts!

Would you be possibly able to finish up with shortcut for ASCII validation? This is important for non-accelerated architectures, e. g., 32-bit machines. Now we have big-endian CI in place, so it should be less painful.