Try using new_zeroed_slice to optimize f.mvs with zeroed allocations

[kkysen]

@ivanloz, could you see if this fixes/changes the performance issue you found in #1358?

This uses #![feature(new_zeroed_alloc)] (rust-lang/rust#129396) by the way, which will hopefully be stabilized soon after #![feature(new_uninit)] was just stabilized in 1.82

[ivanloz]

Thanks! I'll try this out and report back.

[ivanloz]

I've been investigating this and unfortunately I'm still seeing roughly the same number of page-faults -- maybe a marginal drop, but hard to tell if it's just noise. It's still an order of magnitude more page faults than seen in dav1d. Similarly, the number of context switches and overall performance seem to be largely unaffected.

I'm trying to isolate where these are now occurring. I haven't had luck narrowing it down yet, but wanted to at least provide an update here.

[kkysen]

Thanks for the update! Let me try one more small thing first (when I have some time).

[ivanloz]

The page-faults are now originating in <rav1d::src::refmvs::save_tmvs::Fn>::call -- unfortunately I haven't been able to get more precise than that at the moment. If it's helpful, the call stack is

 <rav1d::src::refmvs::save_tmvs::Fn>::call 
 rav1d::src::decode::rav1d_decode_frame_main 
 rav1d::src::decode::rav1d_decode_frame 
 rav1d::src::decode::rav1d_submit_frame 

Since I was already collecting performance numbers, I confirmed that the number of page-faults versus frames processed in rav1d grows much faster when compared to dav1d:

	100 frames	500 frames	1000 frames	2000 frames
rav1d-cli	15,731	37,831	60,071	105,349
dav1d	11,848	16,553	17,122	18,800

These numbers are noisy of course, but the trend seems consistent.

[kkysen]

Whoops, sorry I didn't see this reply/update for a while.

The page-faults are now originating in <rav1d::src::refmvs::save_tmvs::Fn>::call -- unfortunately I haven't been able to get more precise than that at the moment. If it's helpful, the call stack is

 <rav1d::src::refmvs::save_tmvs::Fn>::call 
 rav1d::src::decode::rav1d_decode_frame_main 
 rav1d::src::decode::rav1d_decode_frame 
 rav1d::src::decode::rav1d_submit_frame 

<rav1d::src::refmvs::save_tmvs::Fn>::call is one of the wrappers to an asm call, so that probably means the page faults are occurring in the asm.

Since I was already collecting performance numbers, I confirmed that the number of page-faults versus frames processed in rav1d grows much faster when compared to dav1d:

100 frames 500 frames 1000 frames 2000 frames
rav1d-cli 15,731 37,831 60,071 105,349
dav1d 11,848 16,553 17,122 18,800
These numbers are noisy of course, but the trend seems consistent.

Thanks, this is useful. We should really fix this.

[kkysen]

@ivanloz, does 04ea1ab help at all? If most of the cases are the frame size being exactly the same, this should help a lot I think. Still trying to reproduce your benchmarking, I just wasn't sure which files you were using.