←back to thread

Improving performance of rav1d video decoder

(ohadravid.github.io)
305 points todsacerdoti | 2 comments | 22 May 25 11:59 UTC | HN request time: 0s | source
Show context
mmastrac ◴[22 May 25 13:05 UTC] No.44061671[source]▶
The associated issue for comparing two u16s is interesting.

https://github.com/rust-lang/rust/issues/140167

replies(3): >>44061906 #>>44065911 #>>44066028 #
ack_complete ◴[22 May 25 19:46 UTC] No.44066028[source]▶
I'm surprised there's no mention of store forwarding in that discussion. The -O3 codegen is bonkers, but the -O2 output is reasonable. In the case where one of the structs has just been computed, attempting to load it as a single 32-bit load can result in a store forwarding failure that would negate the benefit of merging the loads. In a non-inlined, non-PGO scenario the compiler doesn't have enough information to tell whether the optimization is suitable.
replies(2): >>44069905 #>>44070022 #
1. Dylan16807 ◴[23 May 25 04:42 UTC] No.44069905[source]▶
> In the case where one of the structs has just been computed, attempting to load it as a single 32-bit load can result in a store forwarding failure that would negate the benefit of merging the loads

Would that failure be significantly worse than separate loading?

Just negating the optimization wouldn't be much reason against doing it. A single load is simpler and in the general case faster.

replies(2): >>44078234 #>>44084378 #
2. ack_complete ◴[24 May 25 23:24 UTC] No.44084378[source]▶
Usually, yeah, it's noticeably worse than using individual loads and stores as it adds around a dozen cycles of latency. This is usually enough for the load to light up hot in a sampling profile. It's possible for that extra latency to be hidden, but then in that case the extra loads/stores wouldn't be an issue either.