[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