[FFmpeg-devel] [PATCH] move ff_emulated_edge_mc() to dsputil

[Michael Niedermayer]

On Wed, Mar 05, 2008 at 08:44:24AM +0100, Diego Biurrun wrote:
> On Wed, Mar 05, 2008 at 08:25:51AM +0200, Uoti Urpala wrote:
> > On Wed, 2008-03-05 at 01:04 -0500, Rich Felker wrote:
> > > On Wed, Mar 05, 2008 at 07:32:07AM +0200, Uoti Urpala wrote:
> > > > On Tue, 2008-03-04 at 23:51 -0500, Rich Felker wrote:
> > > > > Splitting dsputil.c and motion_est.c would be a major improvement in
> > > > > compilability. These files are waaaaaay too big and gcc stupidity
> > > > > results in very slow and memory-intensive compiling, probably due to
> > > > > useless searches for global optimizations or something.
> > > > 
> > > > In the case of motion_est.c I'd blame programmer stupidity more than
> > > > compiler stupidity. It has big av_always_inline functions and macros
> > > > using them which are then used lots of times. The code could be written
> > > > more efficiently. (That's the same issue I mentioned earlier when
> > > > discussing object sizes.)
> > > 
> > > Patch welcome.</michaelni>
> > 
> > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-January/041456.html
> > 
> > Btw changing "av_always_inline int cmp" to "av_noinline int cmp" and
> > comparing object sizes before and after should give you some idea of the
> > amount of repeating code in that file.
> 
> Michael, did you miss that patch during your review runs?

no, there were 2 suggestions from uoti

1.---
It would be possible to trim the code size by hundreds of kB too.
Currently gcc 4.3 generates a 576268 bytes for motion_est.o alone on
x86. I think it would be possible to shrink that by at least half
without much speed loss (yes the cmp function can be optimized
^^^^^^^^^^^^^^^^^^^^^^^
differently depending on parameters, but I very much doubt it's
justified to have 136 different versions of it).
-----

2.---
On Thu, 2008-01-31 at 17:09 +0100, Michael Niedermayer wrote:
> A patch which makes it smaller at the same or better speed
> or one which makes it faster at the same size, is welcome.

I don't currently use FFmpeg for encoding and do not have problems with
binary size so I have little motivation to work on this. However those
who are interested could test the attached example patch and see whether
it has any benchmark effect (I don't have a ready setup for
benchmarking). It reduces binary size by about 10kB on x86/gcc-4.3.
-----

-----(by rich)
> A patch which makes it smaller at the same or better speed
> or one which makes it faster at the same size, is welcome.

Indeed, I agree totally. What's not welcome is the attitude that a few
percent speed loss does not matter. If Uoti really claims he can
improve speed due to better cache utilization, a patch (with
benchmarks) would be welcome!
------

No benchmarks were provided, even though it has been requested multiple
times, and uoti indicated that the main suggestion caused a slowdown.
So i droped all related patches in the sense that i would not
bother any further until someone did provide benchmarks. Noone provided
any so far ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- 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/20080305/9a05b4c8/attachment.pgp>