Threaded lookahead

[pepelugil]

Hello,

In latest x264 revision (2200), has been added a threaded lookahead that seems to improve speed but also seems to decrease quality, according to changelog: "Has a small impact on quality, but does not seem to be consistently any worse".

As I don't need this speed improvement and I don't want to lose any quality on my blu-ray reencodes, should I worry about threaded lookahead? Is there any way to deactivate it?

Best wishes

[LoRd_MuldeR]

First of all, the changelog says that "lookahead threads are 1/6 of regular threads". So unless you have a CPU with 8+ cores (which would result in 12 encoding threads and thus in 2 lookahead threads) nothing has changed for you.

Furthermore "does not seem to be consistently any worse" means that it isn't always worse. And even then, the difference will probably be too small to worry about. Anyway, you can set "--lookahead-threads 1" to be sure...

[burfadel]

If you have only a quad-core machine, and thus 6 encoding threads, is there any advantage of setting say, 2 lookahead threads, and setting the lookahead to say, 100? over that of leaving the lookahead at the default 40 and 1 thread?

[vivan]

So unless you have a CPU with 8+ cores (which would result in 12 encoding threads and thus in 2 lookahead threads) nothing has changed for you.not cores but threads. Almost any modern desktop CPU (intel i5/i7, amd FX-8) has at least 8 threads.

[Groucho2004]

not cores but threads. Almost any modern desktop CPU (intel i5/i7, amd FX-8) has at least 8 threads.
This is utter nonsense on several levels.

What LM wrote is correct.

[burfadel]

Plus the i5 has only 4 cores, 4 threads.

[LoRd_MuldeR]

The term "thread" nowadays is sometimes is sometimes used interchangeably with "logical core". I think even Intel itself sometimes used that terminology.

I prefer the term "logical core" though, because a "thread" is a software concept. A thread is "the smallest unit of processing that can be scheduled by an operating system". Sometimes also called a "lightweight process".

It is correct that the number of logical cores determines the number of threads that can be scheduled concurrently by the operating system. They are still two different things ;)


Back to topic:

When I said "cores" I actually meant cores as seen by a software program like x264, i.e. logical cores. And indeed there are some single-socked CPU's with 8 or even more logical cores now.

People that already own a single-socket CPU with 8+ (logical) cores or use a multi-socket system with an overall number of 8+ (logical) cores will now use 2+ "lookahead" threads with latest x264.

For everybody else nothing has changed...

[Groucho2004]

The term "thread" nowadays is sometimes is sometimes used interchangeably with "logical core". I think even Intel itself sometimes used that terminology.
Are you referring to hyper-threading? If so, it's still something entirely different than calling a (logical) core a thread. It's like getting the terms road and traffic mixed up.

[Groucho2004]

Plus the i5 has only 4 cores, 4 threads.
Yeah, that was one of the levels. :D

[pepelugil]

Ok, after looking with mediainfo the details of an encoded video with previous x264 I see I have threads=12 (I have a core i7) so this means I'll have 2 lookahead threads, so until I find how this quaility impact is, I'll use "--lookahead-threads 1".

Thanks

[LoRd_MuldeR]

Are you referring to hyper-threading? If so, it's still something entirely different than calling a (logical) core a thread. It's like getting the terms road and traffic mixed up.

Hyperthreading is a "feature" implemented in some Intel processors that emulates two logical cores for each physical core. Without Hyperthreading the number of logical cores is equal to the number of physical cores. With Hyperthreading the number of logical cores is twice as high as the number of physcial cores. Or in other words: With Hypterthreading the operating system can schedule two threads for each physical core. However Hyperthreading does not double the execution units in the processor core (it only doubles the register set). Hyperthreading only allows the physical core to more efficiently utilize the existing execution units. With AMD's Bulldozer things are more complicated: Bulldozer uses so-called "modules" and each module has two Integer cores but only a single Floating-point core. It is hard to decide whether a Bulldozer module should be considered as a single physical core that emulates two logical cores (similar two Hyperthreading) or as two full-fledged physical cores (that share some of their execution units) - the truth lies somewhere in the middle and depends on your point of view. And this all doesn't change the fact that a "thread" is a software concept and not a part or property of the CPU...

Now back to topic please ;)

Ok, after looking with mediainfo the details of an encoded video with previous x264 I see I have threads=12 (I have a core i7) so this means I'll have 2 lookahead threads, so until I find how this quaility impact is, I'll use "--lookahead-threads 1".

I would suggest you make two encodes, one with "--lookahead-threads 1" and one without that. Otherwise use identical settings and the identical source.

Unless the "--lookahead-threads 1" version consistently looks better, you can safely drop that option...

[Groucho2004]

Hyperthreading is a "feature" implemented in some Intel processors that emulates two logical cores for each physical core. Without Hyperthreading the number of logical cores is equal to the number of physical cores. With Hyperthreading the number of logical cores is twice as high as the number of physcial cores. Or in other words: With Hypterthreading the operating system can schedule two threads for each physical core. However Hyperthreading does not double the execution units in the processor (it only doubles the register set). Hyperthreading only allows the physical core to more efficiently use the existing execution units. With AMD's Bulldozer things are more complicated: Bulldozer uses so-called "modules" and each module has two Integer cores but only a single Floating-point core. It is hard to decide whether a Bulldozer module should be considered as a single physical core that emulates two logical cores (similar two Hyperthreading) or as two physical cores that share some of their execution units - the truth lies somewhere in the middle (depends on your point of view).
Nicely explained but I was just wondering where you saw Intel using the term threads for cores.

[LoRd_MuldeR]

Nicely explained but I was just wondering where you saw Intel using the term threads for cores.

On their web-site:
http://ark.intel.com/products/65523/Intel-Core-i7-3770K-Processor-%288M-Cache-up-to-3_90-GHz%29

[Dark Shikari]

Hmm. I should probably tweak this because more lookahead threads will definitely help on the first-pass encode (or any similar heavily-lookahead-bottlenecked situation), even with fewer threads.

But coming up with an algorithm to decide things might be a little tricky. 1/6 is just a start.

[mandarinka]

Unless the "--lookahead-threads 1" version consistently looks better, you can safely drop that option...

Generally it's impossible to gauge minor differences like this. Most likely, the results will look different but you won't be able to figure out which is better. I'd say that even just changing crf isn't something that one can reliably tell, unless the difference in bitrate gets huge. Usually you will think you see improvement in some frames but a quality drop in others. In other words, pita.

Something's impact not being blatantly big doesn't mean that it is negligible. Mainly because there can be more of these "nothings" stacking up.

[Sagittaire]

Hmm. I should probably tweak this because more lookahead threads will definitely help on the first-pass encode (or any similar heavily-lookahead-bottlenecked situation), even with fewer threads.

But coming up with an algorithm to decide things might be a little tricky. 1/6 is just a start.

Sound like OpenCL is not miracle way ... ???

[me7]

If I understand this right, x264 used to have a single lookahead thread that could become a bottleneck if the encoding threads that depend on it were too fast (CPU utilization below 100%). Multithreaded lookahead improves such scenarios, but if you already get 100% CPU utilization with a single lookahead thread you don't need to care. Is this correct?

[LoRd_MuldeR]

If I understand this right, x264 used to have a single lookahead thread that could become a bottleneck if the encoding threads that depend on it were too fast (CPU utilization below 100%). Multithreaded lookahead improves such scenarios, but if you already get 100% CPU utilization with a single lookahead thread you don't need to care. Is this correct?

That's exactly how I understand it.

(If with "you don't need to care" you mean that the new multi-threadead lookahead won't give you a speed-benefit in that case and therefore can safely be disabled)

[JoeH]

So, just to make sure I understand correctly, a 4 core Intel processor with Hyperthreading (and thus 8 threads) WILL benefit from the lookahead option since it has 8 logical cores for X264? Is that correct?

[Firebird]

So, just to make sure I understand correctly, a 4 core Intel processor with Hyperthreading (and thus 8 threads) WILL benefit from the lookahead option since it has 8 logical cores for X264? Is that correct?

Yes, it will use 2 lookahead threads.

[me7]

It will use 2 lookahead threads but whether you benefit from it depends on the CPU utilization. If you use a fast preset on a highly clocked CPU and the lookahead becomes a bottleneck, the second lookahead thread will give you a significant overall speed benefit. If you use a slow preset and get 100% CPU utilization anyway, the second lookahead thread will do nothing for you.

[Dark Shikari]

yes, it will use 2 lookahead threads.8 / 6 = 1

[Didée]

8 / 6 = 1

Well ... the changelog isn't quite clear about what-is-what.

By default, lookahead threads are 1/6 of regular threads.
Question is what are "regular threads" - is that "CPU threads" (aka logical cores), or rather "x264 default encoding threads" (being 1.5 times logical cores).

[Dark Shikari]

Oh, right. I can't do math.

12 / 6 = 2.

[ajp_anton]

And manually setting threads lower (from auto=12 to 4 for example) will of course also lower the lookahead threads?

[Dark Shikari]

Yes. Auto-lookahead-threads derives itself from threads, not cores.

[filler56789]

Nitpick: the MeWiki page about x264 (http://mewiki.project357.com/wiki/X264_Settings) still doesn't have an entry for --lookahead-threads :confused:

[Makaveli84]

Nitpick: the MeWiki page about x264 (http://mewiki.project357.com/wiki/X264_Settings) still doesn't have an entry for --lookahead-threads :confused:

Still.....