Improve performance of ncodeunits(::Char)

[Seelengrab]

This improves performance of ncodeunits(::Char) by simply counting the number of non-zero bytes (except for \0, which is encoded as all zero bytes). For a performance comparison, see this gist; there's an up to 10x improvement here for collections of Char, with a minor improvement for single Char (with much smaller spread). The version in this PR is called nbytesencoded in the benchmarks.

Correctness has been verified with Supposition.jl, using the existing implementation as an oracle:

julia> using Supposition

julia> const chars = Data.Characters()

julia> @check max_examples=1_000_000 function bytesenc(i=Data.Integers{UInt32}())
           c = reinterpret(Char, i)
           ncodeunits(c) == nbytesdiv(c)
       end;
Test Summary: | Pass  Total  Time
bytesenc      |    1      1  1.0s

julia> ncodeunits('\0') == nbytesencoded('\0')
true

Let's see if CI agrees!

Notably, neither the existing nor the new implementation check whether the given Char is valid or not, since the only thing that matters is how many bytes are written out.

[jakobnissen]

Are you sure it's faster? On my x86 computer, your code is not faster than the old implementation, even when looping over a text with a varying number of codeunits per character (to defeat the branch predictor). It's possible that it's faster in your benchmark because your benchmark has an unrealistically unpredictable distribution of codeunits per char.

Also, some typos

[jakobnissen]

Also this implementation is incorrect - it fails for some malformed chars like reinterpret(Char, 0xff0000ff).

Perhaps this implementation is correct?

function ncodeunits(c::Char)
    u = reinterpret(UInt32, c)
    4 - div(trailing_zeros(u), 8) + iszero(u)
end

[Seelengrab]

Are you sure it's faster? On my x86 computer, your code is not faster than the old implementation, even when looping over a text with a varying number of codeunits per character (to defeat the branch predictor).

Could you share that benchmark? As far as I know, rand(Char) should produce a good sampling of inputs here.

Also this implementation is incorrect - it fails for some malformed chars like reinterpret(Char, 0xff0000ff).

Good catch! I'll look into that.

[jakobnissen]

I took some Greek text (which has a mix of 1- and 2-byte chars), looped over the chars and then summed the codeunits. The idea was that randomly generated chars have an unrealistic distribution of codepoint lengths, and therefore unfairly punishes branchful code since the branch predictor will be much better on real strings with a more predictable number of codeunits per char.
However, thinking more about it, it's probably not a big deal. Performance is on par and your code relies on less magical compiler optimisation so it's better. By proposed one using trailing_zeros is even faster.

[Seelengrab]

Perhaps this implementation is correct?

Indeed it is, and it's faster than all of the masking I've done because of the heavy lifting in trailing_zeros being done by the CPU. This ends up as a tzcnt, which is unlikely to be beat. The division afterwards is also efficient, since it ends up as a shr ecx, 3, i.e. x >> 0x3; everything here is in integers after all.

If it's alright with you, I'll use your implementation in the PR? The fault in my original implementation was assuming that the leading bytes must all be nonzero, which is of course not true for malformed Char. The original @check didn't catch this because Data.Characters only produces well-formed Char, and no malformed ones. Seems like a missing feature switch on my end.

Results on my machine:

julia> @code_native debuginfo=:none nbytesdiv('a')
	.text
	.file	"nbytesdiv"
	.globl	julia_nbytesdiv_15365           # -- Begin function julia_nbytesdiv_15365
	.p2align	4, 0x90
	.type	julia_nbytesdiv_15365,@function
julia_nbytesdiv_15365:                  # @julia_nbytesdiv_15365
; Function Signature: nbytesdiv(Char)
# %bb.0:                                # %top
	#DEBUG_VALUE: nbytesdiv:c <- $edi
	push	rbp
	tzcnt	ecx, edi
	xor	eax, eax
	mov	rbp, rsp
	shr	ecx, 3
	cmp	edi, 1
	adc	rax, 4
	sub	rax, rcx
	pop	rbp
	ret
.Lfunc_end0:
	.size	julia_nbytesdiv_15365, .Lfunc_end0-julia_nbytesdiv_15365
                                        # -- End function
	.section	".note.GNU-stack","",@progbits

julia> @benchmark nbytesdiv(c) setup=(c=rand(Char))
BenchmarkTools.Trial: 10000 samples with 1000 evaluations.
 Range (min … max):  1.689 ns … 12.760 ns  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     1.720 ns              ┊ GC (median):    0.00%
 Time  (mean ± σ):   1.729 ns ±  0.169 ns  ┊ GC (mean ± σ):  0.00% ± 0.00%

                           █       ▁                          
  ▃▁▁▁▁▁▁▁▃▁▁▁▁▁▁▁▂▇▁▁▁▁▁▁▂█▁▁▁▁▁▁▂█▁▁▁▁▁▁▂▅▁▁▁▁▁▁▁▃▁▁▁▁▁▁▁▃ ▂
  1.69 ns        Histogram: frequency by time        1.76 ns <

 Memory estimate: 0 bytes, allocs estimate: 0.

julia> @benchmark sum(nbytesdiv, c) setup=(c=rand(Char, 10_000))
BenchmarkTools.Trial: 10000 samples with 10 evaluations.
 Range (min … max):  1.115 μs …  2.093 μs  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     1.152 μs              ┊ GC (median):    0.00%
 Time  (mean ± σ):   1.156 μs ± 38.131 ns  ┊ GC (mean ± σ):  0.00% ± 0.00%

               ▁▃▄▅▅▆▇██▆▆▅▃▁▁  ▁ ▂▂▂                        ▂
  ▄▅▇▇▆▅▄▁▃▁▄▅███████████████████████▇██▇▃▁▄▄▄▃▅▅▆▅▃▃▃▃▁▃▅▅▇ █
  1.12 μs      Histogram: log(frequency) by time     1.22 μs <

 Memory estimate: 0 bytes, allocs estimate: 0.

julia> @check max_examples=1_000_000 function bytesenc(i=Data.Integers{UInt32}())
           c = reinterpret(Char, i)
           ncodeunits(c) == nbytesdiv(c)
       end;
Test Summary: | Pass  Total  Time
bytesenc      |    1      1  1.0s

[jakobnissen]

Yep, you can use that implementation 👍

[tecosaur]

Style nit: I'm not sure the blank lines do anything for readability, how about just:

function ncodeunits(c::Char)
    u = reinterpret(UInt32, c)
    # We care about how many trailing bytes are all zero
    n_nonzero_bytes = sizeof(UInt32) - div(trailing_zeros(u), 0x8)
    # Take care of '\0', which has an all-zero bitpattern
    n_nonzero_bytes + iszero(u)
end

[Seelengrab]

Failures seem to be due to Github/CI hiccups, unrelated to this PR.

Style nit: I'm not sure the blank lines do anything for readability, how about just:

Sure, that's reasonable. I've also added a clarification that the line doesn't just compute the number of trailing nonzero bytes.

[Seelengrab]

Failure seems to be the Profile thing again - see #53984. Otherwise IMO good to merge.