[Ffmpeg-devel] [PATCH] minor H.264 asm optimization
Thu Feb 22 14:04:02 CET 2007
On Thu, Feb 22, 2007 at 12:54:05PM +0100, Reimar D?ffinger wrote:
> On Thu, Feb 22, 2007 at 11:16:27AM -0000, M?ns Rullg?rd wrote:
> > Reimar D?ffinger said:
> > > attached patch reduces code size quite a lot for me, since my gcc (4.1.2)
> > > stupidly does loop unrolling.
> > > Not that this was tested only quickly, only on AMD64 and not properly
> > > benchmarked.
> > Loop unrolling sometimes makes code faster, sometimes not. You really should
> > benchmark this.
> No question, though benchmarking only on my PC is not sufficient anyway.
> Problem with benchmarking is, I am too stupid to get
> START_TIMER/STOP_TIMER to print anything, at least when used within that
> code (and yes, the code is executed).
-debug 0 or -v 2 with ffmpeg or so should make the TIMER stuff vissible
with mplayer -lavdopts debug=something should do
> Only values I have are for mplayer -nosound -benchmark -vo null:
> 3 runs with old code:
> BENCHMARKs: VC: 9.101s VO: 0.003s A: 0.000s Sys: 0.420s = 9.525s
> BENCHMARKs: VC: 9.258s VO: 0.004s A: 0.000s Sys: 0.438s = 9.699s
> BENCHMARKs: VC: 9.089s VO: 0.003s A: 0.000s Sys: 0.420s = 9.513s
> 3 runs with new code:
> BENCHMARKs: VC: 9.184s VO: 0.004s A: 0.000s Sys: 0.419s = 9.607s
> BENCHMARKs: VC: 9.066s VO: 0.003s A: 0.000s Sys: 0.420s = 9.489s
> BENCHMARKs: VC: 9.118s VO: 0.004s A: 0.000s Sys: 0.414s = 9.536s
> Hardly anything you could call significant...
but it looks a little faster from the values ...
STRAT/STOP_TIMER will tell for certain
and yes ill benchmark it too on my system later
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel