Impact of Hyper Threading on x264 encoding

[Stereodude]

Following some observations that were made in another thread I decided to test the impact of hyperthreading on x264 encoding.

I used a i7-2600k @ 4.3gHz under Windows 7 x64. Decoding was done using DGdecNV. x264 8bit 64-bit version r2008 was used. I did a 2 pass encode of the first 5 minutes (7193 frames) of Star Trek (2009) at a target bitrate of 20868kbit/sec. The first pass was run using placebo and was reused for all the subsequent encodes.

First pass:

x264.exe --bitrate 20868 --frames 7193 --preset placebo --tune film --weightp 1 --bframes 3 --ref 4 --bluray-compat --b-adapt 2 --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 --qpfile ST11.chp -o NUL ST11.AVS

Second passes:

"C:\HDTV Tools\x264\x264.exe" --bitrate 20868 --frames 7193 --preset xxxxx --tune film --weightp 1 --bframes 3 --ref 4 --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 --qpfile ST11.chp -o ST11_xxxxx.264 ST11.AVS

Results:

Setting		HT on	HT off	Improvement
placebo		39:29	51:28	23.28%
veryslow	22:56	28:22	19.15%
slower		15:53	19:43	19.44%
slow		06:37	08:17	20.12%
medium		05:01	06:18	20.37%
fast		04:15	05:17	19.56%
faster		03:10	03:57	19.83%
veryfast	02:05	02:23	12.59%
superfast	02:04	02:04	0.00%
ultrafast	02:04	02:04	0.00%

[Dark Shikari]

There's no improvement on superfast/ultrafast and minimal on veryfast because you're capped by the decoding speed of the input (it takes exactly 2:04 to decode the input on your machine).

A reasonable judgement would be that the improvement is roughly 20% across all presets.

[Stereodude]

Originally Posted by Dark Shikari

(it takes exactly 2:04 to decode the input on your machine).

Yes, that's what AVSMeter basically says also... I would need a card with VP5 instead of VP4 (on my GT 440) to decode it faster, but since all of my encoding is done at veryslow and placebo it's not really money well spent.

[upyzl]

For these tests, you should use RAW TYPES such as *.yuv, which have nothing with decode

[Stereodude]

Originally Posted by upyzl

For these tests, you should use RAW TYPES such as *.yuv, which have nothing with decode

And how would I do that?

I tried the fast recompress option in Virtualdub and got a massive 21GB avi file that crashes x264.

Edit: I tried feeding the .avi file back through AVIsynth and that works, but the operation becomes disk IO limited instead (a 2TB 7200RPM drive) and shaves off about 2 seconds from the time to decode the entire file. Instead of 2:04 it takes 2:02. So, unless there's something I'm missing this "raw" method doesn't really help benchmarking.

[upyzl]

well... I/O Performance will be bottleneck really... I forgot it

[henryho_hk]

I/O bottleneck? Not with SSD ^__^