[x264-devel] Re: Scalability

Alex Izvorski aizvorski at gmail.com
Tue Feb 27 20:19:29 CET 2007


On Tue, 2007-02-27 at 13:14 -0500, Christian Bienia wrote:
> Hi Alex,
> 
> > Since the removal of slices has caused so much apparent upset, let me
> > just say a word as to the benefits - yes, really ;)   The old threading
> > maxed out at roughly 2x the speed of a single-threaded version with
> > *any* number of processors and threads (i.e. running with 32 threads on
> > 4 processors gave a speedup of 2x; 8 threads on 2 processors was about
> > 1.6x).  The new version scales perfectly with number of processors up to
> > very large numbers (I don't know the upper limit yet, but certainly >8
> > processors).  In fact, it scales sightly better than linearly: the speed
> > with 4 processors is ~4.15-4.2x.  Old threading caused substantially
> > more bitrate to be used for the same quality; new threading doesn't
> > (depending on your settings).  So for most people who really care about
> > speed and not so much about the error resilience that slices provide,
> > this is a big win.
> 
> I just ran x264 on a 128-way ccNUMA, and I think some people here would
> also be interested in the results:
> 
> #Threads	1	2	4	8	16	32	64
> Time/[s]   2280.48 1265.37  661.75  344.77    200.25   201.85  200.97
> Speedup            1       1.8     3.45    6.61     11.39     11.3   
> 11.35
> 
> The new threading code is indeed better than the old one, but x264 still
> has problems scaling beyond 8 CPUs. Are there any known reasons for
> that?
> 
> - Chris

Christian,

This is fascinating.  What box did you run this on?  What x264
commandline did you use?  Threading performance is very sensitive on a
few options (mvrange-thread, scenecut, no-b-adapt).  It may yet be
possible to do much better here.

Regards,
--Alex

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html



More information about the x264-devel mailing list