Re:Making the rav1d Video Decoder 1% Faster
by rhdjsjebshjffn on Thursday May 22, 2025 @03:36PM
(#44065911)
This just seems to illustrate the complexity of compiler authorship. I am very sure c compilers are wble to address this issue any better in the general case.
[ Parent
| on HN ]
Re:Making the rav1d Video Decoder 1% Faster
by runevault on Thursday May 22, 2025 @03:56PM
(#44066162)
Keep in mind Rust is using the same backend as one of the main C compilers, LLVM. So if it is handling it any better that means the Clang developers handle it before it even reaches the shared LLVM backend. Well, or there is something about the way Clang structures the code that catches a pattern in the backend the Rust developers do not know about.
Re:Making the rav1d Video Decoder 1% Faster
by rhdjsjebshjffn on Thursday May 22, 2025 @09:27PM
(#44068937)
I mean yea, i just view rust as the quality-oriented spear of western development.
Rust is absolutely an improvement over C in every way.
Re:Making the rav1d Video Decoder 1% Faster
by vlovich123 on Thursday May 22, 2025 @03:59PM
(#44066204)
The rust issue has people trying this with c code and the compiler generates the same issue. This will get fixed and it’ll help c and Rust code
Re:Making the rav1d Video Decoder 1% Faster
by runevault on Thursday May 22, 2025 @09:34PM
(#44068993)
Out of curiosity just clang or gcc as well?
I just tried it, and the problem is even worse in gcc.
Given this C code:
typedef struct { uint16_t a, b; } pair;
int eq_copy(pair a, pair b) {
return a.a == b.a && a.b == b.b;
}
int eq_ref(pair *a, pair *b) {
return a->a == b->a && a->b == b->b;
}
Clang generates clean code for the eq_copy variant, but complex code for the eq_ref variant. Gcc emits pretty complex code in both variants.For example, here's eq_ref from gcc -O2:
eq_ref:
movzx edx, WORD PTR [rsi]
xor eax, eax
cmp WORD PTR [rdi], dx
je .L9
ret
.L9:
movzx eax, WORD PTR [rsi+2]
cmp WORD PTR [rdi+2], ax
sete al
movzx eax, al
ret
Have a play around: https://c.godbolt.org/z/79Eaa3jYf