Intel i7 and AMD X6 encoding comparision

[xlazom00]

Hello
I am going to make video encoder server and I can't decide for right processor.

Anybody can compare video x264 encoding on i7 and X6 processor.
I think first pass and second pass on both processors ( 1 thread )
pure power with same x264 settings
I would like to see which frequency get same fps on both processors.

:helpful:

[Atak_Snajpera]

i7 (4-cores) at the same clock is still slightly faster than x6.

[xlazom00]

i7 (4-cores) at the same clock is still slightly faster than x6.

Can you provide some results ?

[Dark Shikari]

http://i50.tinypic.com/2a64cow.png

[xlazom00]

I saw this picture.
But I would prefer some results from you guys (x264 team or some x264 devs).
I don't really think that that guys from anandtech.com know something about x264 and how many threads they used.
It's looks like 6 threads on X6 and 8 on i7. maybe cores+1.

I prefer pure power per one thread ( what AMD and Intel bake to processors).

[Atak_Snajpera]

It's looks like 6 threads on X6 and 8 on i7. maybe cores+1.
x264 by default uses cores * 1.5 formula.

[prOnorama]

This is the brand new Intel Core i7-875K (basically a i7 870 with unlocked multiplier) vs.the AMD Phenom II X6 1090T Black Edition.

http://www.hexus.net/content/item.php?item=24850&page=6

Apparently they overclocked it to 4,135 Mhz, as far as I can see they didn't test the Phenom X6 overclocked.

[Episodio1]

Would Core i7 be taking advantage with their 8 virtua cores (HyperThreading on) ?

[ajp_anton]

Would Core i7 be taking advantage with their 8 virtua cores (HyperThreading on) ?
*looks at picture above*
i7 920: 26.7fps
i5 750: 21fps

[xlazom00]

Would Core i7 be taking advantage with their 8 virtua cores (HyperThreading on) ?

Answer is yes and no

From my experience You don't get linear speed up with every core you have.
Let's say
1 thread 60fps
2 threads 120 fps
it's working only with some configuration of x264

But if you want good output quality(pic/size) you never get linear speed up of x264

That is problem with all the benchmarks we see here
In most cases some of cores in your CPU just do nothing.
That is reason why I want to see benchmark of x264 1 thread on AMD X6 and INTEL i7

[bnshrdr]

In my opinion unless you are going with super super high end processors (like the Intel Extreme one's), most of the ones listed in the benchmarks are fairly close in comparison. From those tests, most of the decent processors vary in speed from about 5-10%, and each has their own strength.

I recently got the AMD Phenom X6 1055T and have not looked back since. With no overclock (2.8 GHz) at full load and stock fan it only heats up to around 40 degrees (Celsius). So I will no doubt overclock it at least some soon enough.

To me, it wouldn't have been worth it to buy those Intel processors plus a motherboard. I found a bundle (cpu/mobo) for $200, where the comparable Intel equivalent was either double or more. To me buying those slightly better Intel processors would have only produced diminishing returns.

[CpT]

I want to see benchmark of x264 1 thread on AMD X6 and INTEL i7

That's actually a really good idea. But I've yet to find any sites that actually do it.
If you find a site or someone that's done single threaded tests plz post a link.

To me buying those slightly better Intel processors would have only produced diminishing returns.

The kicker is most of the I7 1366 socket chips hit 3.8ghz + very very easily, even on a stock cooler. Once you hit those speeds everything changes.

[woah!]

ok heres a 1055T thuban at 3.9ghz 1 threaded and then with 6 cores:

i used a newer x264.exe as it uses all my cpu power at 100% on the first pass, whereas the one in the pack seems to cap at 50% which is bs...

Results for x264.exe r1342
--------------------------

1 thread
encoded 1442 frames, 35.84 fps, 3902.49 kb/s

x6 threads
encoded 1442 frames, 128.72 fps, 3906.74 kb/s
encoded 1442 frames, 133.95 fps, 3906.74 kb/s
encoded 1442 frames, 133.56 fps, 3906.74 kb/s

1 thread
encoded 1442 frames, 6.42 fps, 3967.80 kb/s

x6 threads
encoded 1442 frames, 36.90 fps, 3959.99 kb/s
encoded 1442 frames, 37.09 fps, 3959.18 kb/s
encoded 1442 frames, 37.17 fps, 3959.98 kb/s

[7ekno]

The kicker is most of the I7 1366 socket chips hit 3.8ghz + very very easily, even on a stock cooler. Once you hit those speeds everything changes.

The kicker is the x6's hit 4GHz on a stock cooler (confirmed also with 3 builds now) ...

So the overclock isn't a feature solely in Intels favor ...

Tek

[CpT]

Which version of x264 did you use?

I'll run the benchmark as well on a 980x using the same x264 version.
Currently the chip is at 4.2Ghz, I'll drop the clocks to 3.9 and run a single thread bench.

The kicker is the x6's hit 4GHz on a stock cooler (confirmed also with 3 builds now) ...
So the overclock isn't a feature solely in Intels favor ...
Tek

That's good to know.

[woah!]

i used this one, but the x86 version as i am on xp still

http://forum.doom9.org/showthread.php?p=1405128#post1405128

[CpT]

1 thread first pass:
56.21

1 thread 2nd pass:
10.08

Frankly I was expecting a lot more fps out of this chip... Especially considering the price...

That's on an intel 980x @ 3.9 with hyperthreading disabled using the 32bit version you linked.

When I have the time tomorrow I'll let it run and finish all 4 tests. Pretty tired and semi depressed atm...

[woah!]

i wouldnt be that depressed, thats still 50% faster than my x6. with 6 cores you will push 50+ fps.

i will say tho that i could run 3 rigs with 1055T's in them for the same price as that monster you have heh...

[xlazom00]

I want to add my results
What video do you have and settings do you use ?

[Episodio1]

There's an interesting x264 benchmarks where everybody can post their results: http://forums.techarp.com/reviews-articles/25637-x264-hd-benchmark-3-0-a.html

They use rev. 1342

Current results: http://www.techarp.com/showarticle.aspx?artno=520&pgno=7 (there's no AMD X6)

[LoRd_MuldeR]

OT
(Though I wonder a little about Tech ARP's testing methodology for "stock settings": "Please remember to turn off Intel Turbo Tech mode in the BIOS for accurate results with Intel i7 and i5". - In other words: "Make all TurboTech-equipped processors ~5% worse than what they could do at their intended stock settings." If a processor's intended multiplier for all-cores-fully-loaded is multi=(X), they reduce it to multi=(X-1). Don't see why that is "accurate". It would seem more fair to operate a CPU with those spec's which it is designed for to work with.)
/OT

With "Turbo Boost" enabled all benchmark results are less stable, because it's impossible to predict when the CPU enabled the "boost" and when not.

This depends a lot on background process activity. I read the processor rarely uses the maximum boost, because it almost never happens that only one single core is used.

Furthermore it depends on the temperature of the CPU. If the temperature of the CPU fluctuates (which always happens, more or less), then you'll get different benchmarking results.

After all, with Turbo Boost enabled it will be necessary more than ever to take the average from a lot of encoding passes, in order to smooth out outliers.

And x264 shouldn't benefit from Turbo Boost anyway, because Turbo Boost will only become "active" when some of the cores are unused, which won't happen with x264 ;)

[STaRGaZeR]

Turbo boost activates when all 4 cores are active too, but the CPU is running below its nominal TDP ;)

[LoRd_MuldeR]

Turbo boost activates when all 4 cores are active too, but the CPU is running below its nominal TDP ;)

Huh? From what I read, Turbo Boost won't be "activated" until some of the cores fall into the "deep" sleep state (C3).

I also read that Turbo Boost even won't work at all, if those sleeps states are disabled in the BIOS - which obviously is the case with many "all in one" PC's that are sold :rolleyes:

EDIT: Okay, it seems that even when all four cores are still active, Turbo Boost can work. But then it will be limited to a "boost" of 266 MHz.

Also it still is uncertain when the CPU stays below its TDP (and thus can increase the clock speed) and when not. This can be different for each encoding process.

Turbo Boost adds a kind of performance fluctuation that wasn't there before. Therefore it will be harder to accurately measure performance with a benchmark...

[STaRGaZeR]

EDIT: Okay, it seems that even when all four cores are still active, Turbo Boost can work. But then it will be limited to one single step of 133 MHz.

True. And unless you run it inside a furnace, it'll permanently run with that extra multiplier, at least here ;)

[LoRd_MuldeR]

True. And unless you run it inside a furnace, it'll permanently run with that extra multiplier, at least here ;)

Well, this may depend on the cooler that is used, on how good the case is ventilated and even on the ambient air temperature.

If you read the magazines (like German c't magazine), they clearly say that with Turbo Boost enabled there are much greater performance fluctuations than before, which makes obtaining accurate benchmarking results "difficult", if possible at all. So temporarily turning off Turbo Boost for the purpose of benchmarking may make sense indeed.

(Of course with an application like x264, where all four cores are kept at full load and Turbo Boost can only slightly increase the clock speed, the performance fluctuations will be smaller than with a single-threaded application, where Turbo Boost will make a much bigger difference)

[Episodio1]

TurboBoost increases CPU multiplier when one or more cores are at full load.

Depending on application running, if it is single-threaded that particular core frequency will be multiplied by x25 (for example). And when it uses all cores that number would be x22 (when nominal multiplier is x21, for example).

Important issue when benchmarking would be: should we disable turbo boost to do a fair comparison with other CPUs?

[STaRGaZeR]

Well, this may depend on the cooler that is used, on how good the case is ventilated and even on the ambient air temperature.

If you read the magazines (like German c't magazine), they clearly say that with Turbo Boost enabled there are much greater performance fluctuations than before, which makes obtaining accurate benchmarking results "difficult", if possible at all. So temporarily turning off Turbo Boost for the purpose of benchmarking may make sense indeed.

(Of course with an application like x264, where all four cores are kept at full load and Turbo Boost can only slightly increase the clock speed, the performance fluctuations will be smaller than with a single-threaded application, where Turbo Boost will make a much bigger difference)

The best magazine you can read is testing the CPU yourself. Always. Web sites (and magazines even more) are biased and ignorant. Of course temps are crucial, but when you bench you do it in a controlled environment, and if you want consistent results, you get them. You can turn off TB if you want, you'll get accurate results across different tests, but they won't show the true perfomance of the processor. That completely misses the point of benchmarking.

[Atak_Snajpera]

TurboBoost should be disabled during testing because this is nothing but dynamic overclocking.

[CpT]

TurboBoost should be disabled during testing because this is nothing but dynamic overclocking.
Exactly...
And tbh 266mhz isn't enough to see any real difference.

[MasterNobody]

TurboBoost should be disabled during testing because this is nothing but dynamic overclocking.
But from other hand this official overclocking which is enabled by default (so most users will use it).

[CpT]

So show 2 sets of benchmarks.

One stock clocked, then hard clock to its rated turbo boost speed.

[LoRd_MuldeR]

The best magazine you can read is testing the CPU yourself. Always. Web sites (and magazines even more) are biased and ignorant. Of course temps are crucial, but when you bench you do it in a controlled environment, and if you want consistent results, you get them. You can turn off TB if you want, you'll get accurate results across different tests, but they won't show the true perfomance of the processor. That completely misses the point of benchmarking.

IMO the proper way would be to first measure the performance without Turbo Boost to get an accurate estimate of the "base" performance, which can be easily compared to other CPU's. Then, on top of that, you can measure the performance on the same processor with Turbo Boost enabled, which gives a (rough) idea of the additional performance gain that Turbo Boost (dynamic overclocking) can reach.

[InsulinJunkie]

TurboBoost should be disabled during testing because this is nothing but dynamic overclocking.

Also, don't forget that AMD added their version, "TurboCore", beginning with the X6s, so really it's something we're going to be dealing with from all new CPUs from here on out.

[STaRGaZeR]

IMO the proper way would be to first measure the performance without Turbo Boost to get an accurate estimate of the "base" performance, which can be easily compared to other CPU's. Then, on top of that, you can measure the performance on the same processor with Turbo Boost enabled, which gives a (rough) idea of the additional performance gain that Turbo Boost (dynamic overclocking) can reach.

The problem here is that there's no "proper way", there's just the way you want to do it.

[Didée]

(Ooop's ... after 30 seconds I decided to delete the post because of OT'ness ... but too late, Lord_Mulder was fast and caught me.)

Minor fact: yes, the Nehalems *always* use turbotech when there's sufficient load. The minimum boost is multiplier+1 (i7-750, i7-860) or even +2 (i7-870/875k). The usage of additional turbostates during partial load depends on whether C-State usage is activated in the BIOS, i.e. the higher multipliers are used only while other cores are in sleep state.

But, that "minimum" turbo is used practically *always* when there is sufficient load.

Of course the whole thing can be rated as "overclocking", but after all, it is the way that the processor is meant to work, this is what it has been designed for. My point of view is that it makes sense to operate a CPU in the way it is meant to operate.
In numbers, an i7-750/860 will work at least at multi=21/22 with true stock settings. Disabling turbo, they'll work at 20/21. Now, 21/20 is 1.05, 22/21 is 1.0476. Hence, 750/860 get a penalty of almost 5%. Worse for 870/875k, for which it's 24/22 ~> 9% penalty.

I can't help, but in a competence where some minor differences separate the good from the better from the best, it is not trivial to introduce a penalty of 5% or 9%. That's not peanuts, but some serious performance.


Also, the argument about "repeatabiliy"/"reliability"/" you never know if it kicks in or not" etc.etc. is mostly BS. I've done my tests too, and under same conditions, the repeatability of results is quite good, absolutely in range of normal measuring differences. When you're doing a performance measurement, surely you'll make sure that there are no "big" tasks running in the background. (Nobody measures x264 performance while prim'ing, linx'ing or folding in the background.) And when Windows happens to start a full system backup in the background, then your numbers are screwed anyway, no matter turbo or not-turbo.

Lastly, I (partly) doubt TechARP's numbers for stock settings in yet another aspect. i7-750 almost same performance as i7-860 - On stock settings? Seems that Hyperthreading also has been disabled, for an "even fairer" result?


Next step would be to disable all CPU caches. It is unfair that different CPUs have different cache sizes. :)

[xlazom00]

can we go back to comparison of x264 fps on i7 and X6 on one thread

We can overclock processors to compare on different frequency.

But we still don't get results to compare.

[Groucho2004]

can we go back to comparison of x264 fps on i7 and X6 on one thread

Could you explain why this is useful for you?

[Didée]

can we go back to comparison of x264 fps on i7 and X6 on one thread

We can overclock processors to compare on different frequency.

But we still don't get results to compare.
For real-world usage, look at the graph that Dark Shikari put in post#4. Seems like some serious numbers.

For performance with exclusively-one-thread ... well, it's both possible and valid to compare if a Mercedes or a BMW is faster when only using the 1st gear. But that's not what matters in practice.

Moreover, even when you have the "raw performance" on "only one thread", that doesn't mean that you could just multiply that performance {times cores} or {times threads}. Hence, the significance of single-threaded performance is somewhat limited. When you want to know what a CPU can deliver at max, then you need to load it to max.

[xlazom00]

As I said on first page

I want to compare real speed of i7 and X6 (single core) on x264
single core thread speed get real information about processor speed.

From my experience x264 can't get 100% of full 6 cores on X6 and i7.
At least I can't get it on 1th pass

[Groucho2004]

Here are more recent results from Techarp (2nd pass):
http://www.techarp.com/showarticle.aspx?artno=669&pgno=2

[Groucho2004]

As I said on first page

I want to compare real speed of i7 and X6 (single core) on x264
single core thread speed get real information about processor speed.

From my experience x264 can't get 100% of full 6 cores on X6 and i7.
At least I can't get it on 1th pass

This doesn't make sense.

Running the first pass, you will almost always be limited by the decoder/AVIsynth script so the you won't get an accurate result for the raw encoding speed, regardless of the number of threads.

Running the 2nd pass (or CRF), x264 will utilize all cores very efficiently anyway.

So, what's the point?

[xlazom00]

I want to encode multiple files.
In that case you are limited only with CPU power.
It's little more linear in that case.

1. file get 100% of 1. core
2. file get 100% of 2. core
3. file get 100% of 3. core
4. file get 100% of 4. core
5. file get 100% of 5. core
6. file get 100% of 6. core
I can do it in same time


And it's much faster than if you are encoding one file with 6 threads ( 6 files one after another )

[Didée]

And it's much faster than if you are encoding one file with 6 threads ( 6 files one after another )
I doubt that it's "much" faster. When doing 2-pass encodes, there is some speed increase to expect on the 1st pass (since framedecision is singlethreaded still). There's only very minor speed increase to expect on 2nd pass, and same for CRF encodes.

Quick tryout on a dualcore:

1 x 720p CRF encoding, multithreaded: 6.48 fps

2 x 720p CRF encoding, simultaneously, singlethreaded: 3.30 fps / 3.31 fps

For this random example, that's 2% faster. Is that what you'd call "much faster"?
(The quite little advantage that can be seen is, most probably, the overhead of thread synchronization. Apart from that, 99% CPU usage is 99% CPU usage, no matter how you turn the coin.)

However, one thing is sure: when you mass-convert always 6 videos in parallel, you surely will get more file fragmentation on the resulting files. ;)

[shakey]

If you're encoding 1 file multithreaded, does each core re-use some of the same data in the cpu shared cache (reducing manin memory reads, increasing encoding speed)? If you're doing many single threaded encodes, this won't happen? Also you'll be storing x copys of the x264 executable, x avisynth scripts etc in cache instead of just 1?

Finally, if you're doing many simultaneous encodes, will each encode 'fight' over disk access, since it's very possible that each source is at competely different disk position, so HD seek times will have an effect?

edit: another thought, x264 is quite RAM intensive (with a decent look-ahead buffer). With 6 simultaneous encodes, you'll be limiting this buffer, so you may end up reducing the quality of your encodes if you use single pass mode.

[saint-francis]

If you're encoding 1 file multithreaded, does each core re-use some of the same data in the cpu shared cache (reducing manin memory reads, increasing encoding speed)? If you're doing many single threaded encodes, this won't happen? Also you'll be storing x copys of the x264 executable, x avisynth scripts etc in cache instead of just 1?

Finally, if you're doing many simultaneous encodes, will each encode 'fight' over disk access, since it's very possible that each source is at competely different disk position, so HD seek times will have an effect?

edit: another thought, x264 is quite RAM intensive (with a decent look-ahead buffer). With 6 simultaneous encodes, you'll be limiting this buffer, so you may end up reducing the quality of your encodes if you use single pass mode.

I'm not qualified to comment on most of you points but I do know that disk access will not be an issue. Any HDD that can physically interface with a motherboard capable of using X264 will be no where near it's random/sequential read/write limits. And I'm imagining that the I/O will be little more than it is for single process. The only difference, as you noted, would the that there would not be a single, presumably, contiguous file. Still it's peanuts compared to what drives can accomplish.

[Didée]

Another point is: what kind of source material you're encoding. With SD material, the point probably isn't all too serious. But assume it's some Full-HD material, perhaps a BR source, or - who knows - some kind of raw data? Decoding one H.264 1080p stream is one story - decoding six such streams at the same time is another story. After all, you mainly want to encode, not just decode. OTOH, in case of RAW data, the mere bitrate surely starts to matter when dealing with six streams at the same time.