[FFmpeg-devel] [PATCH] h264 parallelized

[Michael Niedermayer]

Hi

On Fri, Jun 29, 2007 at 12:27:02PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Fri, Jun 29, 2007 at 10:57:50AM +0200, Andreas ?man wrote:
> > Hi
> > 
> > Michael Niedermayer wrote:
> > > Hi
> > > 
> > > ive rerun the benchmark and the values are below to make it more clear
> > > 
> > > svn  : 0m0.737s, 0m0.735s, 0m0.742s, 0m0.746s, 0m0.746s
> > > patch: 0m0.756s, 0m0.763s, 0m0.757s, 0m0.761s, 0m0.752s
> > > 
> > > testing done with:
> > > time ffmpeg/ffmpeg-threadslices -i test.h264 -f null /dev/null 2>/dev/null
> > > 
> > 
> > Uww..  bad figures indeed.
> > I am a bit confused why there is such a big difference since the patch
> > does not poke around at all in the speed critical paths of the code.
> > It must be some kind of cache issues or inlining changes..
> > 
> > On what CPU is this?
> 
> model name	: AMD Duron(tm) Processor
> stepping	: 1
> cpu MHz		: 807.391
> cache size	: 64 KB
> 
> ive tried another file (Aladin.mpg 995 frames 352x240, the other file
> was 538 frames 160x128)
> svn  : 0m10.828s, 0m10.777s, 0m10.848s, 0m10.799s, 0m10.742s avg:10.799
> patch: 0m10.770s, 0m10.777s, 0m10.831s, 0m10.918s, 0m10.778s avg:10.815
> 
> ill do more tests

ive tried the first file concatenated 5 times:
0m3.669s, 0m3.696s, 0m3.674s, 0m3.700s, 0m3.724s avg:3.693
0m3.781s, 0m3.782s, 0m3.770s, 0m3.797s, 0m3.776s avg:3.781

this should exclude any once run init code as a possible cause

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070629/a9167b1b/attachment.pgp>