Core i7 and x264

[bartnovsky]

Is there anybody who tried the new Core i7 for encoding video using x264?

They promise 8 threads for this CPU - does that really work on x264 (which effectively should work with 8*1.5=12 threads)?

Also a thing i know nothing about - how does the capacity of L3 cache influence the performance of x264? (and does it influence at all after some threshold?!) Core i7 has 8mb and Core 2 Quad I am using at the moment for encoding video has 12mb L3 cache.

I wish i could theoretically predict the advantage of using this new CPU as much as possible...

[nurbs]

This has been discussed several times here. :search:

Basically the core i7 is about 40% faster (2nd pass) than the core 2 at the same clock speed.

[burfadel]

Although it has been discussed before, the information is now outdated and the question is a fair one to ask! Especially considering there are now socket 1156 Core i7's also available.

The current Core i7's are socket 1366 and have the 9xx designations. The socket 1156 Core i7's has the 8xx designation. They are similar cpu's, except the core i7 has dual channel RAM not triple channel, and a few other architectural changes and a new stepping. In real terms, the socket 1156 should be more cost effective (at least after the initial overpriced release), is the mainstream version, and has more options for changing CPU's such as changing back to the mid ranged Core i5 or low end Core i3.

Currently I would suggest not upgrading your CPU, motherboard, and RAM until these new CPU's are more readily available, since it has been suggested the socket 1156 Core i7's will be faster per clock than the socket 1366 and at a lower cost, a lot to do with the architectural changes and new steppings. Games would probably be faster on a socket 1156 Core i7... Haven't seen too many reviews on this though.

A Core i7-920 (2.66ghz) and a x58 motherboard alone is over $600AUS, whereas a Core i7 860 (2.8ghz) socket 1156 and P55 motherboard can be had for as low as $600AUS. The Core i7 860 should outperform the Core i7 920 :) - and have much better upgrade paths.

[Theliel]

Actual Corei7, Bloomfield, family 9xx and socket 1366 its the high end. The next Core i7, family 8xx and socket 1156 will have a less performance vs Actual Core i7 per clock. Actual Core i7 have triple channel and QPI vs, double channel and DMI in future 8xx, but of course, will be more cheaper ;).

[LoRd_MuldeR]

It should be mentioned that the Core i7 does only have four physical cores. It has eight logical cores, because it uses Hyperthrading and thus runs two threads on the same core.

The two threads assigned to the same core can not execute concurrently, as it would be the case with threads running on different cores.

Instead only one of the two threads will be "active" at a time, but the CPU switches between the two threads very fast in order to "hide" memory access latency and stuff.

For this reasons you shouldn't expect a linear 8x speed-up from the eight logical cores, compared to one single core. The same way a Pentium4 HT couldn't beat a "real" Dualcore CPU.

Anyway, a single core on the Core i7 already is significant faster than a single core on the Core 2!

(BTW: Interesting would be some Core i5 benchmarks, because these will be much more affordable than Core i7 and probably conquer the consumer market)

[Groucho2004]

(BTW: Interesting would be some Core i5 benchmarks, because these will be much more affordable than Core i7 and probably conquer the consumer market)

Here (http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3570&p=7) is a little preview.

[LoRd_MuldeR]

Here (http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3570&p=7) is a little preview.

"Graysky's x264 HD test uses the publicly available x264 codec (open source alternative to H.264)" :rolleyes:

Also they don't mention what revision of x264 they used nor what settings they used. This renders the test completely unreliable.

And I can't see Core i5 in that test. Did I miss something ???

[Dark Shikari]

It should be mentioned that the Core i7 does only have four physical cores. It has eight logical cores, because it uses Hyperthrading and thus runs two threads on the same core.

The two threads assigned to the same core can not execute concurrently, as it would be the case with threads running on different cores.

Instead only one of the two threads will be "active" at a time, but the CPU switches between the two threads very fast in order to "hide" memory access latency and stuff.Incorrect. They do execute concurrently, for the explicit purpose of attempting to maximize execution unit usage.

[LoRd_MuldeR]

Incorrect. They do execute concurrently, for the explicit purpose of attempting to maximize execution unit usage.

I think I was correct! Unless I'm mistaken, Hyperthreading doesn't duplicate all the execution units. So in fact they can't execute concurrently ;)

Execution unit usage is maximized by switching between the threads very fast. If one thread has to wait (e.g. for memory access) the other thread continues in the meantime.

Still they execute interleaved. Each execution unit can only be used by one thread at a time -> No "real" concurrency.

(Well, maybe in this case "correct" or "incorrect" depends on how you want to define "concurrency". For sure it's a different kind of concurrency than between separate cores)

[Groucho2004]

And I can't see Core i5 in that test. Did I miss something ???

Lynnfield = i5

[LoRd_MuldeR]

Lynnfield = i5

Ah, thanks :)

[Dark Shikari]

I think I was correct! Unless I'm mistaken, Hyperthreading doesn't duplicate all the execution units. So in fact they can't execute concurrently ;)

Execution unit usage is maximized by switching between the threads very fast. If one thread has to wait (e.g. for memory access) the other thread continues in the meantime.There's more than one execution unit. Data dependency and latency will generally prevent all 6 execution units from being used concurrently by a single thread, so another thread can use the extra ones at the exact same time.

There is no "fast switching"; you're thinking about multiple threads being managed by an operating system, not multiple threads sharing a pool of execution units in hardware.

[Groucho2004]

Also they don't mention what revision of x264 they used nor what settings they used. This renders the test completely unreliable.

I think it's rev 981 or something close.

[burfadel]

Actual Corei7, Bloomfield, family 9xx and socket 1366 its the high end. The next Core i7, family 8xx and socket 1156 will have a less performance vs Actual Core i7 per clock. Actual Core i7 have triple channel and QPI vs, double channel and DMI in future 8xx, but of course, will be more cheaper ;).

Quite true :) but I wouldn't count on that for the current Core i7 9xx's. The Core i5 on the current benchmarks do have for the most part slightly lower performance than the Core i7 socket 1366. but keep in mind:
- Comparing an established CPU with a yet to be released CPU
- Motherboard bioses for the socket 1156 (core i5) wouldn't be as highly tuned
- Comparing Core i5 to Core i7 socket 1366 is a little unfair on the Core i5, comparing the Core i7 8xx (socket 1156) to current Core i7 9xx would be a much better comparison
- Performance per dollar would be significantly higher for Core i5 than Core i7 socket 1366. If this weren't true the Core i7 socket 1366 would have to be twice as fast.
- Triple channel RAM only provides a small benefit over dual channel RAM.
- Not sure hour DDR/TDR works, but it obviously isn't split 50/50 for data since you can't correctly divide 8 by 3 :)
- Isn't the PCI Express chip onboard whereas its on the MB for the socket 1366?
- Above statement suggests Core i5/Core i7 8xx (socket 1156) = Gaming & multipurpose
- And Core i7 (socket 1366) = more workstation oriented tasks?
...

[LoRd_MuldeR]

There's more than one execution unit. Data dependency and latency will generally prevent all 6 execution units from being used concurrently by a single thread, so another thread can use the extra ones at the exact same time.

Well, there is still piplining in the CPU, even without Hyperthreading. So several consecutive instructions from the same thread are executed concurrently. And they are using different execution units at different stages of the pipeline at the same time. Therefor even a single thread should be able to keep most (all?) executions units busy most of the time, thanks to pipelining. Only if one threads fails keep all executions busy and some of them would become "idle", the second one can "jump in" (however you want to call it, I know it's not identical to scheduling on OS level).

[Dark Shikari]

Well, there is still piplining in the CPU, even without Hyperthreading. So several consecutive instructions from the same thread are executed concurrently. And they are using different execution units at different stages of the pipeline at the same time. Therefor even a single thread should be able to keep most (all?) executions units busy most of the time, thanks to pipelining.Pipelining is nowhere near powerful enough to keep them all busy, nevermind the fact that there are actually more execution units than one can decode instructions per cycle. You're thinking of out-of-order execution, which still is not powerful enough to keep most of the execution units busy during normal operation. If it was, Intel would be adding more execution units, and they haven't done so in half a decade.

Furthermore, there's no "switching" going on; both of the threads simultaneously send instructions to be executed and have equal priority when accessing the execution pool, AFAIK.

[Conquerist]

"Graysky's x264 HD test uses the publicly available x264 codec (open source alternative to H.264)" :rolleyes:

Also they don't mention what revision of x264 they used nor what settings they used. This renders the test completely unreliable.

And I can't see Core i5 in that test. Did I miss something ???This seems to be the x264 benchmark that they used: http://www.techarp.com/showarticle.aspx?artno=520. The details are on the second page. They write that --aud --nal-hrd is necesarry for iPod/PSP compatability. Couldn't they do some research before posting that? Anyways, the command line options used are from the MeGUI SA-Blu-Ray profile.

On-topic, they're using build 747, and the "new" version uses build 819. The first Nehalem-specific optimizations came in November 2008, build 1019. So that benchmark definately doesn't show the full potential of the Core i3/5/7/9.

[LoRd_MuldeR]

On-topic, they're using build 747, and the "new" version uses build 819. The first Nehalem-specific optimizations came in November 2008, build 1019. So that benchmark definately doesn't show the full potential of the Core i3/5/7/9.

Is it really that hard to download a reasonably up-to-date binary of x264 before running benchmark and posting posting results? :rolleyes:

[Blue_MiSfit]

Most folks have no idea :P

I've begged folks at techreport and hardocp for a long time to update their benchmarks.

~MiSfit

[LoRd_MuldeR]

Most folks have no idea :P

But we are not talking about some end users here, who don't know and don't care about the technical details, but "professionals" whose job is to analyze and report about exactly those details.

I know that not all the technical details cannot be discussed in an article like the one that was linked. But whoever wrote that article can't simply ignore those details or the entire article will be questionable.

And it's not like this is some "secret" stuff. By browsing Doom9 for 5-10 minutes one should be able to obtain a link the latest x264 build plus the required info about the latest improvements...

[benwaggoner]

Pipelining is nowhere near powerful enough to keep them all busy, nevermind the fact that there are actually more execution units than one can decode instructions per cycle. You're thinking of out-of-order execution, which still is not powerful enough to keep most of the execution units busy during normal operation. If it was, Intel would be adding more execution units, and they haven't done so in half a decade.
Do you have any estimates for the real-world speedup of running with HT on/off on Nehalem?

[Dark Shikari]

Do you have any estimates for the real-world speedup of running with HT on/off on Nehalem?I recall that in singlethreaded mode, the Nehalem was only 15-20% faster than the Penryn, so the rest of the 40% must have come from HT.

[Blue_MiSfit]

I think we can safely agree that the Core i7 is the current ultimate x264 encoding platform.

The "best" x264 encoding workstation I can think of (off the top of my head) would be a MacPro running Windows. 2x Nehalem EX Xeon CPUs, and gobs of ECC DDR3, plus maybe some RAID action.

Dell and HP also make some very good workstations that have dual Nehalem Xeons as well.

~MiSfit

[kieranrk]

The "best" x264 encoding workstation I can think of (off the top of my head) would be a MacPro running Windows. 2x Nehalem EX Xeon CPUs, and gobs of ECC DDR3, plus maybe some RAID action.


Isn't Linux x86_64 a little bit faster.

[Sagekilla]

Too bad there's no quad socket motherboards for i7 yet (At least none I've heard of yet). That, along with 64 GB RAM (64 GB is enough for anyone (http://www.google.com/#hl=en&q=640k+is+enough+for+anyone) ;)) and you should be set for the next few years, or at least until Dark implements QNS again :)

[Blue_MiSfit]

Yes, Linux is a bit faster :)

Still, I prefer running things in Windows natively, without WINE for Avisynth support. Plus, Windows 7 is pretty cool anyway :)

~MiSfit

[aurorix]

Well, there is still piplining in the CPU, even without Hyperthreading. So several consecutive instructions from the same thread are executed concurrently. And they are using different execution units at different stages of the pipeline at the same time. Therefor even a single thread should be able to keep most (all?) executions units busy most of the time, thanks to pipelining. Only if one threads fails keep all executions busy and some of them would become "idle", the second one can "jump in" (however you want to call it, I know it's not identical to scheduling on OS level).

You've actually described several techniques here under the banner of "pipelining".

To clarify, pipelining divides a single execution path into multiple stages. You may only clock as fast as your slowest stage; the goal of pipelining is to balance the amount of time taken to execute each stage, thereby allowing you to maximise clock rate.

What you've alluded to in your post (multiple, concurrent, execution paths) is known as superscalar architecture. As Dark pointed out, out-of-order execution enables a superscalar CPU to make optimal use of its resources by reordering the incoming instruction stream. If there are 2 execution paths, say 1 ALU + 1 FPU for simplicity, and you can issue up to 2 instructions per clock, one instruction to each path, OOOE reorders instructions so that 2 instructions are issued each clock cycle. But this only works if two such instructions can be found.

Hyperthreading comes into play once the CPU is unable to extract any further parallelism through OOOE. Hyperthreading duplicates the hardware required to maintain thread context (i.e. register file) and allows thread 1 to issue instructions to any execution unit that thread 0 is not currently using. So in our example above, if thread 0 is a stream of ALU instructions and thread 1 is a stream of FPU instructions, these two threads can execute concurrently on a hyperthreaded CPU. By comparison, a non-hyperthreaded CPU will starve either the ALU or the FPU until the instruction stream becomes a mix of ALU/FPU instructions.

[paulvdb]

A few months ago I did some testing with hyperthreading on and off to see what was faster. First pass was faster with hyperthreading off and second pass was faster with hyperthreading on. I used the same commandlines (with threads=auto) and avisynth script (directshowsource/coreavc) to encode from three different UK HDTV channels to 720p x264. Unfortunately I don't remember exactly what the commandlines were that I used except that I used faster settings for the first pass. I got the following fps from these tests (first value is first pass, second value is second pass):

Hyperthreading off:
BBC HD 69.24 37.77
ITV HD 59.86 36.23
C4 HD 51.71 34.31

Hyperthreading on:
BBC HD 59.87 46.72
ITV HD 51.99 42.56
C4 HD 45.51 37.87

[burfadel]

That makes perfect sense. The speed of x264 is much faster in first pass than second pass, so the bottlenecks of the input become more apparent. Since avisynth isn't mutlithreaded, it is limited by the speed of the single core. Hyperthreading has both a positive and negative effect. The problem with it is that it isn't dynamic (from what I understand) so when it is on the thread cannot make 100 percent use of the core, whereas with hyperthreading off it can! :)

The second pass is faster with it on as the x264 process is much slower, so the benefit of the threading doesn't overcome the capability of the input thread to supply frame data despite it not being able to make 100 percent use of the core.

Since hyperthreading is a hardware feature than can be enabled and disabled by the bios software, and for single threaded or only partial threaded apps can't take advantage of it, I'm surprised Intel hasn't investigated dynamic hyperthreading that could turn on and off the hyperthreading of each individual core in Windows. Although it may cause a problem or two in Windows it shouldn't be too hard for Microsoft to add support for it (probably would require a software driver).

Even without Microsoft support the driver (or Intel programme) could simply disable it for a particular core dynamically and signal to the OS 100 percent load on the virtual core (so the system doesn't continually have cores creates and destroyed). Using this method you could have anywhere between 4 and 8 parallel threads depending on programme requirements!

[Zelos]

i changed my Q6600 for a core i7 920 , and there is huge difference especially in the 2nd pass.
But the i7 920 is now oc to 4.4ghz , so i can't tell you if it's the architecture, or if it's the frequency that has increase the speed.
My last Q6600 was 3.6ghz oc .

[Blue_MiSfit]

Nice overclock!! And I thought my Q6600 at 3.3GHz was fast :P

I'm seriously considering buying a dual socket Dell workstation for x264 encoding. Hell, I might even build my own so I can overclock it :)

~MiSfit

[Biggiesized]

Nice overclock!! And I thought my Q6600 at 3.3GHz was fast :P

I'm seriously considering buying a dual socket Dell workstation for x264 encoding. Hell, I might even build my own so I can overclock it :)

~MiSfit
Definitely go with the latter. You'll save a lot more money and have fun putting it together.

[burfadel]

I would seriously consider the Core i7 840 on socket 1156. All the reviews about the core i5/i7 have been for the core i5 and not on a release quality bios etc. The speeds for the most part have been quite close if not faster than the core i7 920. The core i7 840 not only runs at a higher clock speed but you'd expect it to run faster than the core i5 at the same clock speed, so at the moment it represents a great deal. The price of the core i7 840 seems to be similar to the core i7 920, not including the fact that the socket 1156 motherboards are cheaper which you can put in to faster ddr3 RAM (just remember that you can't really use anything but standard voltage models). The core i7 920 is geting quite old now and is supposedly going to be replaced soonish with a new stepping etc. At that time they should regain the crown for the best performance per clock speed, but again the difference won't be for the most part really that noticeable...