[FFmpeg-cvslog] random thoughts about refactoring (was: Re: r20938 - trunk/libavcodec/h263.c)

[Michael Niedermayer]

On Thu, Jan 07, 2010 at 05:03:43PM -0500, Jason Garrett-Glaser wrote:
> > That seems to depend on CPU and situation, gcc making poor inlining choices
> > and overflowing the available caches is not exactly the codes fault ...
> 
> Inlining effects are hardly a significant reason that the H.264 decoder is slow.

And how do you know that?


> 
> CoreAVC doesn't do anything particularly smart with inlining--

well, i dont care actually what CoreAVC does. Unless we can use it
to improve our decoder.
If i can make our decoder faster, thats great i dont limit myself to
what CoreAVC does.


> if
> anything, it makes far worse decisions than ffmpeg does--and yet it's
> a lot faster, even when compiled with GCC, which it was never
> optimized for.

carl said something else. I never benchmarked CoreAVC as i plain dont
care about it ...
If i have the time id rather look at our code and improve it ...


> 
> > did i?
> > i think i tend to insist on well split patches and on benchmarks on
> > the individual parts. That is to weed out changes that worsen things
> 
> The problem that this creates IMO is that it forces a gradient-descent
> search process in terms of optimizing code.

>  Sometimes one has to make
> things slower before they can get faster, much like one has to "jump"
> a hill in order to find the global minimum of a function.

Of course but thats quite different from the patches that where submitted
I dont remember a single case with a comment like
"This slows things down but future speedups depend on it and will (likely)
 make things overall faster"
it rather was the kind of
"heres a bunch of unrelated changes that together are faster than before
 and iam not going to check if some part of them actually make the speed
 worse and we could overall improve it by leaving that one out. Take it
 or leave it i wont make them commitable"


>  One could
> argue that the developer should continue optimizing until he can get
> over the hill in his local tree, and then commit it as one big patch,
> but people are often unwilling to work on large changes when they
> aren't sure that they will even be accepted when they're done.
> 

> This is exacerbated by the fact that optimizing h264.c significantly
> will require a *rearchitecture*: something that involves jumping a
> very, very large hill.

Iam not aware of any problem in h264.c's architecture. You arent
planning to explain that architectural problem you see that would
need massive slowdowns to at some point allow speedups?
Or any architectural problem ... ?


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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
-------------- 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-cvslog/attachments/20100108/3921be9f/attachment.pgp>