On Wed, Apr 16, 2014 at 9:11 AM, Niels Möller <[email protected]> wrote: > Hi, I've had a closer look at the get_bits and friends now. To me, that > code looks both pretty complex and not very efficient.
+1 on pretty complex. > > This should give compact inlined code with a comparison, a > well-predicted branch, a shift and a mask which often will be by a > constant. gb->bit_buffer acts as a kind of "cache". Everything hairy > should be done by non-inlined functions which are not as performance > critical. Sketch: > > > Some bonus points over the current implementation: all handling of end > of buffer is in an unlikely block of get_bits_slow, so there's no reason > to separate between safe and unsafe versions. And get_bits supports > sizes up to the size of an unsigned long (with no overhead besides > having to call get_bits_slow more often), so there's also no need for > special "long" variants. > > skip_bits should be similarly split into a compact and fast inline > skip_bits, and a hairier non-inline skip_bits_slow. > > When unsigned long is 64 bits, there will be a function call to > get_bits_slow only once per 64 bits parsed, and then, except when at the > end of the buffer, that's well predicted branch (in addition to the > prediction miss in get_bits), a single *aligned* read, possibly > byteswapping, and then the unavoidable shifting needed to put the pieces > from the two words together. > > To do get_bits_count, one would need an additional context variable. > Since I'd expect get_bits_count to not be performance critical, and to > avoid extra book-keeping in the critical get_bits, it seems reasonable > to simply keep a pointer to the start of the buffer. I quite like this idea, especially splitting the optimized and non optimized case. I was tweaking get_bits too in order to disentangle lavf and lavc and I have a very rough replacement for lavf here https://github.com/kodabb/libav/blob/lavfclean/libavutil/bitstream.h This is completely non optimized unfinished and suitable for lavf only, but if you have a better implementation that could work for lavc too I'd be willing to switch immediately. Vittorio _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
