3 ms·

Reading this it sounds like you are discouraging using it due to the implementation being big and hard to maintain. Did you mean it this way?

jbk 5y ago
I really can't see how you read anything else that "it's very optimized" in my message, tbh.
- eikenberry 5y ago
  "[..] code has now around 186 kLoC of hand-written assembly in .S and .asm files…" This reads to me as it being a PITA to maintain. Cross platform code is usually a pain, cross platform with assembly optimizations is more of a pain. Optimization nearly always makes things harder to maintain, and this sounds like it was optimized to hell and back...
  - jbk 5y ago
    > This reads to me as it being a PITA to maintain. Not more than any other language: when it's well done, it's manageable. When it's spaghetti code, it's not manageable.
  - coldpie 5y ago
    I have a suspicion that the president of VideoLAN has a better idea of the complexity & maintainability of this code than you do.
sethigh 5y ago
No. Most encoders/decoders need assembly to get last drop of performance. Most of the times it comes down to when you give up. The team here was quite relentless to build a usable AV1 decoder. A few years ago this was a pipe dream and jbk and team have done a tremendous job.
zbobet2012 5y ago
In addition to other noting that decoders and encoders almost all have an enormous amount of hand optimized code because they are literally the most demanding applications most people run (which is why most codecs today are hardware accelerated and they are used in almost all CPU benchmarks) 186k LOC (given that it's assembler which is nearly always "vertical code") is also relatively small for decoders. People don't really get how complex video codecs are.
lta 5y ago
It's not they're writing a library full of assembly for the sake of it. Reading the readme, one can discover they have dedicated optimised implementations for a large range of processors, which in turns means there's a lot of assembly involved

jbk 5y ago

I really can't see how you read anything else that "it's very optimized" in my message, tbh.

eikenberry 5y ago
"[..] code has now around 186 kLoC of hand-written assembly in .S and .asm files…" This reads to me as it being a PITA to maintain. Cross platform code is usually a pain, cross platform with assembly optimizations is more of a pain. Optimization nearly always makes things harder to maintain, and this sounds like it was optimized to hell and back...
- jbk 5y ago
  > This reads to me as it being a PITA to maintain. Not more than any other language: when it's well done, it's manageable. When it's spaghetti code, it's not manageable.
- coldpie 5y ago
  I have a suspicion that the president of VideoLAN has a better idea of the complexity & maintainability of this code than you do.

sethigh 5y ago

No. Most encoders/decoders need assembly to get last drop of performance. Most of the times it comes down to when you give up. The team here was quite relentless to build a usable AV1 decoder. A few years ago this was a pipe dream and jbk and team have done a tremendous job.

zbobet2012 5y ago

In addition to other noting that decoders and encoders almost all have an enormous amount of hand optimized code because they are literally the most demanding applications most people run (which is why most codecs today are hardware accelerated and they are used in almost all CPU benchmarks) 186k LOC (given that it's assembler which is nearly always "vertical code") is also relatively small for decoders. People don't really get how complex video codecs are.

lta 5y ago

It's not they're writing a library full of assembly for the sake of it. Reading the readme, one can discover they have dedicated optimised implementations for a large range of processors, which in turns means there's a lot of assembly involved