struct LossLess: Make Rav1dFrameHeader_segmentation::lossless a bit array

[kkysen]

• Part of fn decode_coefs is slow #1180.

I'm working on trying to fix #1180; this is one of a bunch of steps.

[randomPoison]

If I'm understanding this correctly, it seems like the main optimization here is using a bitmask operations (LossLess::get) over an array index operation. It's not clear to me that this would necessarily be more efficient though. Have you profiled this and observed a clear performance improvement?

[kkysen]

If I'm understanding this correctly, it seems like the main optimization here is using a bitmask operations (LossLess::get) over an array index operation. It's not clear to me that this would necessarily be more efficient though. Have you profiled this and observed a clear performance improvement?

No, I didn't profile this one individually yet. It does remove the bounds checks, though I guess that's also solved by SegmentId and InRange later on. It does also use less memory, which I think is useful as well.

[randomPoison]

It does remove the bounds checks, though I guess that's also solved by SegmentId and InRange later on. It does also use less memory, which I think is useful as well.

Given that you have other changes that target bounds checks for the lossless array, the only real advantage here is the memory reduction. That may still be a nice optimization to have, depending on how many of these are expected to be in memory at once, i.e. how many frame headers there are at a given time. I'm assuming not many, so this doesn't really seem like a worthwhile change to me, but I could be wrong about that. @fbossen might be the best person to weigh in on if this is a reasonable optimization.

[kkysen]

Given that you have other changes that target bounds checks for the lossless array, the only real advantage here is the memory reduction. That may still be a nice optimization to have, depending on how many of these are expected to be in memory at once, i.e. how many frame headers there are at a given time. I'm assuming not many, so this doesn't really seem like a worthwhile change to me, but I could be wrong about that. @fbossen might be the best person to weigh in on if this is a reasonable optimization.

It's not just about less overall memory, for which memory reductions would be quite small, but about what could be cached.

@fbossen, what do you think?

[fbossen]

I've run a bunch of tests and it seems this PR leads to a small performance regression. The potential memory saving here is too small to have a positive impact.