Add a log struct for CDFContext rollback

[barrbrain]

Detailed performance analysis to be added shortly. The essence is that large memmove is replaced by smaller copies:

     5.69%     -3.32%  libc-2.32.so        [.] __memmove_avx_unaligned_erms
     3.16%     +1.63%  rav1e               [.] <rav1e::ec::WriterBase<S> as rav1e::ec::Writer>::symbol_with_update

[lu-zero]

x86_64

[lu-zero]

Looks good to me, the tests show a solid 20% gain on speed 0 on x86_64 and aarch64 (benchmark still going on for the other speed levels)

[coveralls]

Coverage increased (+0.01%) to 83.013% when pulling 351f7c8 on barrbrain:cdf-log into 61133e3 on xiph:master.

[barrbrain]

An abridged transcript of review comments on IRC:

[02:45] <derf> barrbrain: let offset = (cdf.as_ptr() as usize - self.base) as u16;
[02:46] <derf> Maybe a good idea to add a debug_assert!() that value fits before truncation?
[02:46] <barrbrain> ah yeah, quite a few possibilities for debug_assert
[02:46] <derf> I do not think the automatic overflow-checking in debug builds checks that case.
[02:50] <derf> base: usize,
[02:51] <derf> ^ That field never gets used anywhere?
[02:51] <derf> Oh, no, it gets used in the line I already pasted.
[02:51] <derf> I guess it is a little weird that it is not used in rollback() though?
[02:52] <barrbrain> Yeah, it primary exists because of complexities of the borrow checker.
[02:59] <derf> Do we need to do something like force CDFContext to use a C-compatible representation to keep Rust from doing something like moving the padding somewhere other than the end?
[03:01] <lu_zero> derf: we can use #[repr(C)]
[03:06] <smarter> https://doc.rust-lang.org/reference/type-layout.html says "There are no guarantees of data layout made by [the default] representation."
[03:07] <derf> Yeah, that was why I brought it up.
...
[03:17] <derf> barrbrain: So, looking at the fixed-length push(), it looks like you are unconditionally assuming there is room for a new CDF at the start, and then reserving space for the next one at the end.
[03:18] <derf> Is that correct?
[03:26] <lu_zero> derf: I'm checking the vec documentation, it has a capacity such as you can fit lots of them, doublechecking that a zero-lenght Vec behavior is the one we think it is
[03:26] <lu_zero> https://doc.rust-lang.org/std/vec/struct.Vec.html#capacity-and-reallocation
[03:27] <lu_zero> If a Vec has allocated memory, then the memory it points to is on the heap (as defined by the allocator Rust is configured to use by default), and its pointer points to len initialized, contiguous elements in order (what you would see if you coerced it to a slice), followed by capacity-len logically uninitialized, contiguous elements.
[03:27] <lu_zero> seems that it is fine
[03:27] <derf> Yes, I'm not disputing its correctness.
...
[03:29] <derf> I assume the reason is because it benchmarks faster this way.
[03:32] <derf> But it's a little weird (i.e., it's a specialization of the contract that Vec provides that has to be maintained outside the function), so maybe it deserves a comment that says, "We do it this way because we tested and it benchmarks faster."
[03:33] <lu_zero> I can run the benchmarks on different variants and confirm
[03:33] <barrbrain> derf: yeah, it would be good to add a comment
[03:33] <barrbrain> lu_zero: thank you
[03:33] <derf> Okay, I think that is all the comments I have.
[03:33] <derf> Everything else looks good.

[lu-zero]

testing on honeycomb shows promising results