View Full Version : x264 encoding - Xeon vs Opteron
Penecho
3rd June 2012, 15:35
I was wondering how the CPU's perform in x264 encoding, which one is faster?
2x 16-core Opteron 6272, 16x 2,1GHz (~500 each)
or
2x 6-core lets say E5-2630, 6x 2,3GHz (~550 each)
I read this post back from 2010: http://forum.doom9.org/archive/index.php/t-155533.html
and it seemed a 12 core opteron is about as fast as a 6 core Xeon. So is a current 16 core opteron faster as a current 6-core Xeon? and how does the amount of RAM affect the encoding speeds?
ramicio
5th June 2012, 17:55
You don't need much RAM for encoding. AMD is all about value, not all-out performance. I'd spend the money on the Xeon, but then again, I'm an Intel fan-boy.
Atak_Snajpera
5th June 2012, 18:32
it is always better to have less cores but faster. i would also choose intel.
it is also very likely that x264 won't be able to use all 32 amd cores at 100 percent for typical 1920x1080 sources.
mandarinka
5th June 2012, 23:14
Unless he is going to do more streams at once, or massive resolution.
In this case, the difference in core count is rather big. And don't forget that the Xeon is using HT, so it will employ 12 threads, not 6, per cpu.
AFAIK for the desktop variants, Bulldozer 8core is only a bit slower per thread, compared to quadcore Sandy Bridge with HT ( = 8 threads). I think it's like 3.7GHz Bulldozer 8core = 3.4GHz Sandy Bridge quadcore.
Here you have 16 cores against 6. I think in this scenario Opterons will give you more cpu performance. x264 is actually one of the tasks that Bulldozer does better than average in, even if overally it isn't exactly great of a cpu.
Blue_MiSfit
7th June 2012, 03:59
You'll need to run a lot of encodes in parallel to saturate a 32 core system! If you're not planning on doing lots of encodes in parallel, and instead need to burn through encodes in series, you should use fewer, faster cores.
Atak_Snajpera
7th June 2012, 12:11
You'll need to run a lot of encodes in parallel to saturate a 32 core system!
2-3 encodes should be sufficient for 1920x1080.
35.5 fps - 2 x Intel Xeon X5670 @ 2.93GHz ( 6C / 6T ) MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 <- HT disabled
27.7 fps - 2 x Intel Xeon X5670 @ 2.93GHz ( 6C / 12T ) MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
more logical cores only slow downs encoding speed. (results from x264 FHD Benchmark (http://www.x264fhdbenchmark.republika.pl/Results.txt))
Dark Shikari
7th June 2012, 16:11
Are you sure about that? It could be possible that the encoding speed was bottlenecked by input or lookahead, so turning on HT just hurt because it couldn't use the extra threads.
In my experience HT gives +~25% encoding speed.
ramicio
7th June 2012, 16:18
On a 6-core system with hyper-threading, I do 4 encodes in parallel with 4 threads specified for each encode. But then again, I also use a slow preset. I don't know why anyone would let x264 decide the number of threads on a system with many logical cores. If you have a system with 32 logical cores, that's going to be a terribly-inefficient encode.
Atak_Snajpera
7th June 2012, 16:50
Are you sure about that? It could be possible that the encoding speed was bottlenecked by input or lookahead, so turning on HT just hurt because it couldn't use the extra threads.
Discussion was here -> http://forum.doom9.org/showthread.php?t=162936
Who knows maybe with latest x264 would be better...
Adub
11th June 2012, 23:04
Indeed, in a heavily multicore system, there are several encoding bottlenecks that can happen, including the lookahead thread that DS referrenced above. I believe that there is now a multithreaded version of lookahead, so this helps to alleviate some of the issue.
http://git.videolan.org/?p=x264.git;a=commit;h=999b753ff0f4dc872077f4fa90d465e948cbe656
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.