x264 encoding speed with more CPU cores

[WasF]

Hello,

Do you know how x264 encoding speed grows with CPU cores' number?
I have a dual code processor. If my processor had 1000 cores, would the encoding be 500 times faster?

Thx.

[nurbs]

No.
It doesn't scale linearly. It scales well until up to a couple of dozen threads from what I read here.
There are parts that aren't threaded, like frametype decision, so if you use certain settings (--b-adapt 2 and lots of b-frames) your encoding speed will be limited by that.

[J_Darnley]

Try reading doc/threads.txt (http://git.videolan.org/?p=x264.git;a=blob;f=doc/threads.txt)

[LoRd_MuldeR]

Most important it does scale well enough to fully utilize a "hexacore" CPU, which is the maximum number of cores you can get in a single CPU currently.

(The test J_Darnley is referring to shows that even on a Dual-Socket system with a total amount of eight cores x264 was able to achieve a speed-up of ~7x, which is pretty near to the theoretical maximum)

[Groucho2004]

Most important it does scale well enough to fully utilize a "hexacore" CPU, which is the maximum number of cores you can get in a single CPU currently.


You're forgetting that the i980 has 6 cores with hyperthreading which means that 12 threads are utilised.

[LoRd_MuldeR]

You're forgetting that the i980 has 6 cores with hyperthreading which means that 12 threads are utilised.

Yes, but you can't expect the same performance gain from a 6 core CPU with hypertherading than from a "real" 12 core CPU.

Hyperthreading, i.e simulating two logical cores for each physical core, is only a "workaround" to improve the utilization of the CPU core's internal execution units.

Moreover x264 always needs more threads than cores for "optimal" performance. On the eight core machine up to 12 threads were needed until saturation...

[Groucho2004]

Yes, but you can't expect the same performance gain from a 6 core CPU with hypertherading than from a "real" 12 core CPU.

Forget what I wrote. I just re-read the first post and noticed the OP is asking about speed and not CPU utilisation.

[mariush]

Actually the highest number of cores you can get now in a CPU is 12 physical ones, in an AMD server processor: http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=100008494%20600048502&IsNodeId=1&bop=And&Order=PRICE&PageSize=20

Yes, it's a 800$ CPU but then there are those Intel 6cores + 6 HT for 1000$ so it's not really a high price when you think about it.

Motherboards are also relatively cheap, dual socket motherboards are 400$, so you could build a 24 (real) core system for about 2500$ and you can actually buy 4 x 12 core systems with less than 5000$.

To answer OP's post, the performance does increase with number of cores, but not linearly aka 1000 cores = 500x speed compared to dual core processor. There's also other factors involved like how fast input is read from disk and decoded to raw footage if input is mpeg or other format, what encoding settings you use, how well whatever filters you use work with multiple processors and so on.

[WasF]

Thanks for all the answers.
J_Darnley's pointer is an interesting read, it shows speed scales better with increased number of threads when using --slow rather than --fast (here complexity helps, for once)..
This also means that gazillion processing units in a GPU wouldn't help a lot. So much for GPU-assisted encoding..
And that Intel and AMD can put the race to biggest number of cores at rest (outside the server market anyway). x264 encoding is the only reason I would buy even a dual core CPU. Single cores are already too powerful for my other needs..

[jpsdr]

My own experience : Speed increase is linear, at least at low values.
I've upgraded from an i7@960 (or 965, don't remember) (4 cores + HT @3.2GHz) to an i7@980 (6 cores + HT @3.33GHz).
Theorical gain is (6x3.33)/(4x3.2) = 1.56. Measurement gave me gain of 1.6 (could be explained by L3 cache also up from 8MB to 12MB).
So, if you have a single core, and update to a multi core, you can expect direct a linear speed-up.

[Anakunda]

Hello,

which platform is faster x86 or x64?
This is taken from changelog:

commit 80174bfdd30da508576d318323af57b2cd821c5b r1784
Author: Oskar Arvidsson <oskar@irock.se>
Date: Sat Oct 30 20:16:33 2010 +0200

x86 asm for high-bit-depth pixel metrics
Overall speed change from these 6 asm patches: ~4.4x.
But there's still tons more asm to do -- patches welcome!

Breakdown from this patch:
~13x faster SAD than C.
~11.5x faster SATD than C (only MMX done).
~18.5x faster SA8D than C.
~19.2x faster hadamard_ac than C.
~8.3x faster SSD than C.
~12.4x faster VAR than C.
~3-4.2x faster intra SAD than C.
~7.9x faster intra SATD than C.

commit 3b818190c22f7ba6d3b2f228954b1368f58f75dc r1783
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Sat Oct 30 19:13:05 2010 -0700

x86 asm for some high-bit-depth coefficient functions
~7.9x faster denoise than C.
~2.3x faster coeff_level_run than C.
~6.6x faster coeff_last than C.
~4.3x faster decimate_score than C.

Also improve checkasm's decimate_score test.

commit faed8d5a8ca66d0904a43b545376832bc4a038c9 r1782
Author: Oskar Arvidsson <oskar@irock.se>
Date: Sun Nov 14 03:33:30 2010 +0100

x86 asm for high-bit-depth motion compensation
~8x faster qpel MC than C.
~10x faster hpel than C.

commit 38861b90aa958e16743920271f5a4f509d12c6ff r1781
Author: Oskar Arvidsson <oskar@irock.se>
Date: Thu Nov 4 02:13:43 2010 +0100

x86 asm for high-bit-depth quant
~3.1-4.2x faster than C.

commit 82a3dc116318d5594ac3474112cfe3472ca1b31e r1780
Author: Oskar Arvidsson <oskar@irock.se>
Date: Sat Oct 30 16:55:48 2010 +0200

x86 asm for high-bit-depth DCT
Only MMX and DCT done so far; iDCT still needs asm as well.
~4.4x faster than C.

commit 2584843007df862ecf99e1d357f7ef617c582184 r1779
Author: Oskar Arvidsson <oskar@irock.se>
Date: Sat Oct 30 11:42:52 2010 +0200

x86 asm for high-bit-depth deblocking
~3.3x faster than C.


does it mean that the optimizations don't apply to x64 code?

[nurbs]

The x64 version (8bit) is a little faster, IIRC around 10%. These optimizations only are for high-bit-depth which probably isn't that interesting to you as no consumer hardware and almost no software can currently decode it. The 8bit version already has optimizations like that.

[tph]

does it mean that the optimizations don't apply to x64 code?
x86-64 (which is the correct term, not x64) is just an extension of x86 and therefore x86 optimizations still apply.

[me7]

To be a bit more precise, x86 contains all end-user processors currently available by Intel and AMD. Only "exotic stuff" like ARM processors for mobile devices or PowerPC processors don't benefit from such optimizations.

[LoRd_MuldeR]

x86-64 (which is the correct term, not x64) is just an extension of x86 and therefore x86 optimizations still apply.

Not exactly ;)

There are various subtle differences, including different calling conventions (at lest on Windows), that can break x86 assembly on x64, if not taken care of.

Moreover, x64 offers more and wider registers than x86, so assembly written for x86 will not be optimal for x64. In order to take advantage of x64 you need to re-optimize your code.

(BTW: x86-64, AMD64, Intel64 (not be confused with IA64) and x64 are just four different names for the very same architecture)

[Manao]

Just to clarify : There are various subtle differences, including different calling conventions (at lest on Windows), that can break x86 assembly on x64, if not taken care of.Correct, but x264 takes care of those. For x264, any function that is optimized for x86 will have at least the same level of optimization for x64. When Jason says x86, he really means both x86-32 and x86-64.

[lchiu7]

Well I was pleasantly surprised by the speed increase with additional cores.

Up till now I had been doing my encoding on a very modest Athlon 64 X2 3500. A typical 2 hour movie from a BD rip with CQ one pass would take about 8 hours.

I then built an Athlon II X3 2.8GHz system and was able to unlock the fourth core. Using the same scripts the encode took 90 minutes! While I was expecting it to be at least twice as fast, I was very pleasantly surprised to see the time reduce to about 20% of the original encode time. One wonders what the time would be with 6 or 8 cores.