How much faster is octo-core vs quad-core?

[DoomNlNE]

I have a server that I use for encoding. The server company is offering a free upgrade.

I currently have 4 cores 2.5Ghz Xeon.
The upgrade is to a similar family 8 cores 2.5Ghz Xeon.

What is the performance increase? (assume same clock speed and architecture)

My workloads:
1. Upscale low resolution video game console captures to 1080p with:
x264 --preset fast --qp 0

2. Encode low resolution footage to files with:
x264 --preset veryslow --qp 0
And
x264 --preset placebo --crf 14

3. Encode high resolution (1080p+) to a lossless file with:
x264 --preset slow --qp 0

I would like to know what speed boost I will get if I upgrade!
I will not upgrade if the speed performance boost is low (~30%).

I do not run multiple encodes at once. Only one at a time.

It is a significant upgrade, so I should only upgrade if the performance improves significantly.

Thank you.

[Asmodian]

1: this one is hard to know, maybe limited by single threaded processes or maybe get ~100% improvement.

2: vertical resolution dependent, "V.res" / 40 = number of threads. 480p would use up to 12 threads so it should give a very good increase in speed moving from 4 to 8 cores (I assume hyper threading Xeons? 8 and 16 threads at once?) I would expect >50% improvement for 480p.

3: a good increase, just a bit under 100%.

This thread (http://forum.doom9.org/showthread.php?p=1646307#post1646307) gives some more information on how extra cores/theads affect x264.

[DoomNlNE]

1: this one is hard to know, maybe limited by single threaded processes or maybe get ~100% improvement.

2: vertical resolution dependent, "V.res" / 40 = number of threads. 480p would use up to 12 threads so it should give a very good increase in speed moving from 4 to 8 cores (I assume hyper threading Xeons? 8 and 16 threads at once?) I would expect >50% improvement for 480p.

3: a good increase, just a bit under 100%.

This thread (http://forum.doom9.org/showthread.php?p=1646307#post1646307) gives some more information on how extra cores/theads affect x264.
Yes Xeon with hyper threading.

100%! Holy damn! I will upgrade.

Thanks :)

[Blue_MiSfit]

Yeah, provided the other pieces of your workflow can keep up, x264 can eat a lot of cores :)

[DoomNlNE]

I have just noticed that many of my encodes do not use 100% CPU on my current quad-core. Most of my encodes use ~30% CPU according to Windows Task Manager.

In this case, does it mean moving to octo-core will not give any improvement at all for this task?

Many of my encodes are using a very low resolution. My latest encode was a video game console source (256x240), up-scaled 8x to lossless:

x264 --preset ultrafast --qp 0 --threads 8 -o out.mkv hd.avs
hd.avs:
AVISource("in.avi").PointResize(AVISource("in.avi").width*8, AVISource("in.avi").height*8)

I then upload the resulting file to youtube, where it gets 'original' and HD quality options.

(The up-scaling makes the video look unquestionably better and sharper. Long story if you don't know retro video-game sources well)

[Stereodude]

I have just noticed that many of my encodes do not use 100% CPU on my current quad-core. Most of my encodes use ~30% CPU according to Windows Task Manager.

In this case, does it mean moving to octo-core will not give any improvement at all for this task?That is most likely correct.

[LoRd_MuldeR]

I have just noticed that many of my encodes do not use 100% CPU on my current quad-core. Most of my encodes use ~30% CPU according to Windows Task Manager.

Why are you setting 8 threads explicitly? On a 4 core machine with HT (i.e. 8 logical cores), x264 would use 12 threads by default, I think.

Did you try to just stick with the x264 defaults? Or did you at least try other "--threads" values on your system? Maybe you can improve CPU usage quite a bit this way!

Another thing to check: Is x264 really the bottleneck here or is it your AVS input script? Try the script alone (e.g. in AVSMeter) and compare that FPS value to what you are seeing in x264.

Finally, did you try other presets? Maybe, with a somewhat "slower" preset, you can get the same encoding speed with better compression - at the "cost" of higher CPU load.

[Groucho2004]

AVISource("in.avi").PointResize(AVISource("in.avi").width*8, AVISource("in.avi").height*8)
What a bizarre script. You should read up on Avisynth syntax a bit.
Try this for a more sane approach:
AVISource("in.avi")
PointResize(width()*8, height()*8)
Also, PointResize is the worst possible choice for upscaling. Try Spline64 or - probably even better - nnedi_rpow2().

[LoRd_MuldeR]

For such low resolution video game recordings PointResize() might give exactly the effect that is intended. The "normal" resizers would destroy the "pixel graphics" look.

But nnedi3_rpow2() can give quite interesting effects with such footage, indeed.

[Groucho2004]

For such low resolution video game recordings PointResize() might give exactly the effect that is intended. The "normal" resizers would destroy the "pixel graphics" look.
Good point (no pun intended :D). Also, I don't know what Youtube does to uploaded videos...

[ajp_anton]

--preset ultrafast
is probably the reason you're not seeing 100% CPU usage.

[Bloax]

Good point (no pun intended :D). Also, I don't know what Youtube does to uploaded videos...
We had a little discussion about it here (http://forum.doom9.org/showthread.php?p=1623196#post1623196).

Whatever it is that Youtube does, upscaling even true 480p videos to 720p will drastically improve the final video quality when watching the 720p video.
Upon further inspection, the horrible video player doesn't help 480p's cause either. (The 480p video looks much better in MPC-HC with MadVR)

[pandy]

Also, PointResize is the worst possible choice for upscaling. Try Spline64 or - probably even better - nnedi_rpow2().

It depend what is goal to achieve and what with next processing steps - for example for fractional pixel scrolling using pointresize is OK and point sampling is perfect from mathematical point of view (Zero-order hold).

[osgZach]

Isn't windows task manager a horribly incorrect when it comes to actual CPU usage?

I think it has something to do with stuff "reserving" cycles but not actually using them or something like that.. I know I've seen this discussion before on other forums where people were advised to not use Task Manager for accurate data gathering. I certainly have run programs in the past which pegged the CPU as "100%" but know there was no way in hell it was using the whole thing (i.e running a simple script in a MUD client).

If you were truly seeing 100% usage wouldn't the system slow to a crawl, or at least present periods of "pausing" while the offending code was being run ? (or is that the domain of process Priority?)

[LoRd_MuldeR]

The "CPU usage" you see in Taskmanager is nothing but the fraction of the overall time that the CPU has spent executing either user processes (threads) or kernel code - as opposed to the fraction of the overall time that the CPU has been idle. Not more and not less. It tells you absolutely nothing about whether the "used" CPU time has actually been spent for useful calculations. The CPU might as well have been spinning in a NOP loop ;)

Example: Assume we have a single-threaded application that uses at most 25% of the CPU time on a Quadcode machine. Of course I can easily add three dummy threads to that application, which do absolutely nothing but spinning in a NOP loop. Now you may look at Taskamanger and notice that the CPU usage has increased from 25% to 100%. Awesome! But did the actual throughput of our application increase? Not at all. You are just spending more CPU time (energy) for nothing!

In reality we would not add such dummy threads. Still, making applications multi-threaded almost always comes at an increased overhead, e.g. because we need to spent additional CPU cycles for thread synchronization. Or because we need to use a different algorithm that better scales to multiple threads, but requires more overall CPU cycles. So CPU usage isn't everything! We also need to keep an eye on the actual throughput of our software...

(In other words: Twice the throughput at twice the CPU usage is optimal, but rarely reached in reality. 50% more throughput at twice the CPU usage may still be okay. But 1% more throughput at twice the CPU usage certainly isn't)

[osgZach]

Good info, thanks for that.