Impact of Hyper Threading on x264 encoding

[Stereodude]

Following some observations that were made in another thread (http://forum.doom9.org/showpost.php?p=1515458&postcount=44) 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]

(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]

For these tests, you should use RAW TYPES such as *.yuv, which have nothing with decodeAnd 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 ^__^