[FFmpeg-devel] [PATCH] Optimization of original IFF codec

[Sebastian Vater]

Sebastian Vater a ?crit :
> Hi Mans!
>
> M?ns Rullg?rd a ?crit :
>   
>> Sebastian Vater <cdgs.basty at googlemail.com> writes:  
>>   
>>     
>>> Btw, you brought me to a nice idea with your complaints...I could
>>> precalculate all these values for each plane in decode_init and then
>>> just memcpy it in decodeplane8/24 to local stack, what do you think of this?
>>>     
>>>       
>> Skip the memcpy and make the table static const.
>>
>>   
>>     
>>> This will yield in 8 (planes)*4 (uint32_t's)*16 (sizeof (struct lut)) =
>>> 512 bytes of tables for decodeplane8
>>>     
>>>       
>> 512 bytes is nothing to worry about.
>>
>>   
>>     
>>> and 24 (planes)*4 (uint32_t's)*16 (sizeof (struct lut))*4
>>> (lut[0123]) = 6144 bytes.
>>>     
>>>       
>> 6k isn't a lot either.  Just store it statically.
>>
>>   
>>     
> Bad news here...
> Tried almost everything, the new code is not faster than the old one I
> had before. :-(
>
> It just wastes memory for gain of nothing.
>
> I tried:
>     const uint32_t lut[16];
>     memcpy (lut, &decodeplane8_tab[plane], 16 * sizeof(uint32_t));
>
> In best case as fast as the original. Usually slower.
>
> Then I tried:
>     const uint32_t *lut = &decodeplane8_tab[plane];
>
> Results are same as above.
>
> Finally I tried without local stack copy as above:
>         const uint32_t v = decodeplane8_tab[plane][get_bits(&gb, 4)];
>         AV_WN32A(dst+i, AV_RN32A(dst+i) | v);
>
> This is the slowest of them all...
>
> Please don't ask why, but it's not worth the hassle. I think discarding
> the table and keep it the way as I submitted it in the patch is the
> best. :-(
>   
Here's decodeplane8 patch with your ideas.

-- 

Best regards,
                   :-) Basty/CDGS (-:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: iff-opt-dp8-static.patch
Type: text/x-patch
Size: 3043 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100426/58822a3c/attachment.bin>