[FFmpeg-devel] [PATCH] two small h264 optimizations

[Michael Niedermayer]

Hi

On Mon, Aug 13, 2007 at 11:36:40PM -0400, Alexander Strange wrote:
> #1 ffmpeg-cabacres-switches -
> This changes the if (cat == ) .... statements to switch tables.
> Adding a default case to case 5: removed most of the speed gain, so I  
> took out the assert,
> but it doesn't affect anything. I can put it back somewhere else if  
> needed.

id say open code optimization or whatever its called bugs on gccs tracker

first cat is a constant passed to the function, like foobar(5)
the function is static and the cat parameter is never written to nor its
addres taken so gcc knows which values it can reach and thus can optimize
the assert() away in both the if() and switch cases

second there is no reason why the if() else if() code should be less
efficient than the switch, they are just 2 different ways of doing the
same thing

which means i dont like this optimization, its faster on one cpu and one
gcc version, what about another gcc version, another cpu or intels cc
theres no reason why a switch() would be faster then a if() else if()
both can be implementey by branches or a table of pointers, later is
slow on many cpus due to branch target prediction being unable to handle
it

also what happens if you reorder the if() statements?

the type of optimizations which i do like are ones which speed up code
assuming an ideal compiler, that is reducing the number of operations
number of function calls, code size, reducing the number of cache misses
changing the data organiztaion to turn random in sequential accesses
changing the algorithm to a faster one, ...

just changing if(a)else to switch() or more extreemly changing int foo to
int bar
are optimizations i dont like as they dont improve the code assuming
an ideal compiler or to say it differently its like changing the
seed of a random number generator to improve its output in some way

removing the assert() is ok though if that helps speed
also reordering the if() so the more common cases come first is ok if it
helps


> 
> #2 ffmpeg-fillrectangle-microopt.diff -
> Statements like a = b = c = d = e; store from right-to-left, so if  
> you write them in the right order it comes out backwards.
> This removes them from fill_rectangle().

hmm, well, as it has to be evaluated right to left iam ok with it

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070814/de9238b7/attachment.pgp>