[x264-devel] Re: multi-threaded effectiveness

[Loren Merritt]

On Sat, 15 Apr 2006, Firas Al-Tahan wrote:

> This question may be focused towards L. Merritt - how effective is the
> multi-threaded code in x264? Do you have benchmarks on how well the
> code is optimized through this technique?

At medium settings, I get about 1.7x speedup from 2 cpus.
The only thorough benchmark I've seen is rather old,
http://www.ee.oulu.fi/~tuukkat/mplayer/tests/x264test4/readme.html

> Another quick question, how much RAM does the codec require - I
> presume this relies on input resolutions etc - but how does it compare
> to other codecs - eg WMV HD or DivX 6?

x264 (cli) uses about 2.1MB + (9 + 6*(number of reference frames))*resolution
where reference frames can be selected from 1 to 16.
XviD (encraw) uses about 1.6MB + 24*resolution.
These numbers are measured on x64_64 (though only the inital constant 
number should vary between architectures), and are the real memory used, 
not including anything that can be swapped out.
I have no idea how this compares to WMV, DivX, or any other windows-based 
program.

> Where would one start to work on PPC64 ASM? Is it a case of looking at
> the Intel ASM and saying 'wonder if there's a PPC version of that
> line' or is it a GREAT deal more complicated than that?

It might be possible to translate the mmx to altivec, but the results 
will not be optimal. Most of the asm'ed functions are pretty trivial 
algorithmically, you're better off just looking at the C implementation.

The only exception to this might be the deblocking filter, where the 
algorithm was significantly munged to make it fit in 8-bit math with no 
branches. But deblocking is one of the less important functions to asm.

--Loren Merritt

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