i5 2500k Video Encoding Issues

[nanaki333]

I gave a friend an i5 2500k, which he used to have an i7 930 I gave him before. It's a side grade, yeah, but whatever. At stock speeds on both, the i7 930 gets significantly higher marks. Everything I've read puts the 2500 above even a stock i7 950. Anybody have any idea as to what's going on with it?

I don't remember the exact motherboard I gave him, but it's an Asus z68 with an 80GB vertex2 set for cache.

This is his current encoding speed for xvid.
[10/24/2011 1:32:56 PM] Speed was: 173.06 fps.
[10/24/2011 1:32:56 PM] Job finished. Total time: 26 minutes 14 seconds

The i7 930 was seeing 200fps and completed in about 18 minutes.

 

[classy]

Same amount of ram in each system?

 

[nanaki333]

actually the new system has 16GB (4x4GB) and the old one had 12GB (6x2GB)

 

[pauldun170]

Does it have the correct virtu driver for installed?

 

[Rvenger]

Wouldn't it be because the i7-930 has Hyperthreading and the 2500k does not?

 

[Diogenes2]

Anand comparison has 2500k beating i7 940 ( 930 not listed ) in most situations..

http://www.anandtech.com/bench/Product/46?vs=288

 

[sm625]

Are you saying you have found evidence to suggest that Anand buttered up the newest intel chip results to help intel sell a few more chips? Make the new look good, and the old look bad. Oldest trick in the book. Gotta move those parts somehow.

 

[nanaki333]

Does it have the correct virtu driver for installed?

i'll have him check it tonight. fairly certain it's correct.

 

[AkumaX]

Does it have the correct virtu driver for installed?

does virtu have anything to do w/ xvid encoding?

 

[alyarb]

It sounds like you aren't using quicksync. So the higher clocked 2500k is barely mitigating the lower clocked hyperthreaded i7.

Use a quicksync encoder.

 

[exar333]

Are you saying you have found evidence to suggest that Anand buttered up the newest intel chip results to help intel sell a few more chips? Make the new look good, and the old look bad. Oldest trick in the book. Gotta move those parts somehow.

We get it. 'AMD good' 'Intel bad'

Could you maybe contribue more than this to the forum? Thread after thread of this stuff....

 

[Jovec]

Yeah, not sure what the issue is. 4c/8t > 4c/4t CPU even with the latter having higher IPC. Those 2500 encoding benchmarks are almost all Quicksync based, which AFAIK trades quality/options for increased speed.

 

[alyarb]

no that is false. the CPU benchmarks use x86 codepaths as not all SNB CPUs have QuickSync and it is the goal of the CPU benchmark app to compare CPUs, not sideshow IGP hardware. It is also false to assume QuickSync is a lower quality encoder. It can very easily achieve transparency like any other good encoder, maybe at a slightly higher bitrate than x264 but at tremendously greater speed.

The behavior you are seeing is a result of SNB's higher clocks and IPC coming close to an 8-threaded chip in well-threaded work. If you need this job to run faster, you either need to do it in QuickSync or on an i7. No one promised that today's i5 would be faster than yesterday's i7 in any case.

 

[Jovec]

no that is false. the CPU benchmarks use x86 codepaths.

At stock the extra clockspeed, IPC, and better turbo modes on the 2500 are impressive and make it very competitive to the 950, but any bench at stock clocks that shows a 2500 beating a 950 encoding video is either using Quicksync, using an encoder that doesn't scale well (or not at all) past 4 threads, or is something like x264 first pass or Itunes which is single-threaded.

If you look at AT Bench, you'll see the 2500 beating the 950 at the DivX encoder, x264 first pass, and Windows Media Encoder 9 while losing at x264 second pass and most of the rendering tests. I don't have much experience with DivX, but WME9 has terrible scaling and x264 first pass is single threaded.

There are also some basics to check also.

Same encoder version and options?
Same video source?
Confirmed that both are stock speeds?
Comparable cooling so both CPUs can hit their turbo modes?

 

[alyarb]

I think we are arguing the same thing. The generic CPU benchmarks do not use quicksync.

Based on the info we are given though I think we should assume his (and Anand's) encoder uses at least 4 treads. Therefore any influence from turbo should be negligible, as turbo frequencies are only held for extended lengths of time for less than 4 loaded threads. I'll go a step farther and assume that, because the 8-threaded machine turned out to be faster, the encoder we are talking about is different from the AT Bench encoder and perhaps we should ignore it.

While I admit it is peculiar that the 2500k outperforms the 950 in the generic divx test, I think that is merely a discrepancy between the configurations of the old system, new system, and Anand's test suite. I assume what the guy truly wants is a high speed, high quality, high compression output, and the best way to achieve that is to try QuickSync, just once, rather than blunder through potentially fruitless configuration mysteries.