On 07/18/2012 05:15 AM, Loren Merritt wrote:
> On Tue, 17 Jul 2012, Loren Merritt wrote:
>
>> 25% faster on penryn (even though I didn't predict that by counting uops).
>> 25% faster on sandybridge.
>> No change on bulldozer.
>>
>> But even though I successfully predicted that this is an improvement, I
>> don't understand its performance.
>> 6x load, 12x punpckldq, 6x store, 4x scalar:
>> Should take 12 cycles on penryn, 7 on sandybridge, 12 on bulldozer.
>> Instead, I measure 25 cycles per iteration on penryn, 19 on sandybridge, 96
>> on bulldozer.
>
> Aha, a large part of the discrepancy is due to cache aliasing, when the
> offsets between the 6 output streams are divisible by some large power of
> 2. This would have to be fixed in whatever piece of code allocates audio
> buffers, not in the asm.
>
> Incidentally, video codecs have the same problem with strides. Do we
> address that anywhere?
I have to admit that I don't really know much about cache aliasing. If
avoiding power of 2 offset between plane pointers would fix it, that
could easily be done in the utility functions for allocating audio
buffers. Currently we pad plane size to a multiple of 32 samples in
whatever the sample format is. So, after adding the padding, we could do
something like:
while (av_popcount(plane_size) == 1 && plane_size >= LARGE_POWER_OF_2)
plane_size += size_of_32_samples;
-Justin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
