TR Forums

Did a bunch of speed/voltage encode testing and found that
with a 10minute (dvd) mpg file (to X264.mp4@VerySlow preset)
(TMPGEnc Video mastering 6)

16 cores were consistantly 2 seconds faster then the full 16/32 threads setting.
Encode time 3minutes 20 seconds. Gained 1% in fps.

Got 90 hours to encode. should take 30 hours to do it and every fps helps.
(only 10-11 cores used, no point going for that 32 core threadripper)
So wish I had the new enhanced Boost 2(?) support... well, got what I got.
86% faster then my 3930 6/12HT core from 2012...It is used at 90+%
So again 10-11 threads used. Not so far apart.

Crashes at 4Ghz but got 8 hours of encoding @ 3.95Ghz done yesterday.
Air cooled Noctua. Temps Mid 65 C +/- with an ambient 86 F(30 C) (florida).

Always hope for that "4Ghz" but can never get there (with good temps).
There is a high speed fan on the cooler and the case to keep temps down.
Good thing is that you KNOW when the computer has finished it's job.

jmc

(only 10-11 cores used, no point going for that 32 core threadripper)

That's when you start thinking about running two encoding jobs in parallel (if that's possible to do) and then figure out if it's actually a benefit to overall performance by using more cores or if it's actually harming performance by oversubscribing the system. It might also be a fun way to test stability at 3.95GHz since you weren't pegging all the cores before.

There are 2 levers that can be used to extract parallelism from encoding workloads (neither of which are featured in your test case):
1) high bitrates (think Blu-ray quality or higher)
2) high resolution (think 1080p or even 4k)

I regularly peg my 10c/20t 7900x @ 100% with Handbrake transcoding from m2ts to mkv by maintaining bitrate and source resolution using a 2-pass process and vbr.

You may find that it's not so easy to find an "optimal" number of threads for encoding(and probably for many other tasks as well). Optimal in terms of "this is the best this application can do", and "this is the best my leet CPU can do" can often be different things.

Just chiming in to say that your software is definitely to blame here.

My experience is of Vray (raytracing) on a renderfarm and we use a management tool called Deadline to chop up single jobs feed portions of it to multiple machines. Needless to say that Intel Hyperthreading adds around 40% more performance to the mix in our scenario and that Ryzen 7 1700 nodes (the most power-efficient by a country mile, and that's what matters when you have dozens of them running 24/7) definitely outperform hyperthreaded Broadwell-E so all threads MUST be being fully utilised.

If you're talking about 90 hours of encoding, and underutilised CPU, split the job into two clips and run them concurrently, then spend five minutes manually rejoining them once complete. AMD's SMT isn't quite at Intel's level, but you should see a 25-30% improvement, which is potentially 25+ hours shaved off the job.

The benefits of HT/SMT are totally dependent upon software scaling and the actual workload you're running. If you don't have pipeline bubbles and you're fully subscribing the various FPU/ALU/memory resources...you're not going to gain anything.

Waco wrote:

The benefits of HT/SMT are totally dependent upon software scaling and the actual workload you're running. If you don't have pipeline bubbles and you're fully subscribing the various FPU/ALU/memory resources...you're not going to gain anything.

Heck, its even harmful! Because if you've got 100% full pipeline and everything, then cutting the effective L1 cache in half will harm a lot of workloads. 32-threads means your L1 and L2 cache has to hold less-data per thread and work with main memory more.

HyperThreading / SMT making things slower is a known issue. It generally makes "inefficient" code faster (CPU-bound), but "highly efficient" (cache bound) code slower. Unfortunately, there's no easy way to tell if your workload is CPU-bound or cache-bound. You can use like perftools on Linux, but I'm not aware of any easy access to low-level performance counters on Windows.

EDIT: Oh, AMD? So you can use AMD's CodeXL to profile programs. So that's a benefit, but you gotta learn low-level stuffs to understand all the knobs and buttons. Intel's VTune costs a lot of money (nearly $1000ish) but is considered one of the best performance tools in the market.

If you're doing well enough that HT hurts you, you're also likely smart enough to only engage the first thread on each core.

All the talk about HT on or off is interesting but since the original poster doesn't seem to be the software developer I don't think he can rewrite the encoding application to fix whatever bottlenecks it has.

Nothing new about this on x86 since, what, 2001? not all code likes HT/SMT/etc.

There are also various security implications to various implementations, some well documented...some not yet

The biggest question is does his software (TMPGEnc Video mastering 6) like that many threads and hyperthreading or not?

That's a question for the developer and their forums.

jmc2 wrote:

Got 90 hours to encode. should take 30 hours to do it and every fps helps.
(only 10-11 cores used, no point going for that 32 core threadripper)

Do 2 or 3 at a time. Sure, code only scales to 10 cores. But just run the code 3 times at the same time to get good scaling across 32 cores.

Just split your files into 3 groups, and then run those three groups simultaneously, with 3 instances of your encoder.

Aranarth wrote:

The biggest question is does his software (TMPGEnc Video mastering 6) like that many threads and hyperthreading or not?

That's a question for the developer and their forums.

Nah, you can figure this stuff out and strategize without even going to developer tools. The original poster has already done a good job figuring out if hyperthreading / SMT is good or bad (bad in this case. Yeah, it happens. Good job figuring out though, that always takes a bit of testing).

So the only thing left is to figure out the optimal number of threads and the optimal number of simultaneous processes for his 30+ hour job.

chuckula wrote:

That's when you start thinking about running two encoding jobs in parallel (if that's possible to do) and then figure out if it's actually a benefit to overall performance by using more cores or if it's actually harming performance by oversubscribing the system. It might also be a fun way to test stability at 3.95GHz since you weren't pegging all the cores before.

Thanks for mentioning that.(to all)
There (was/is?) a limit of only one instance of AC3 encoding allowed(Dolby).
But I have heard that AC3 is now an "open" standard.
So maybe I could now run two encodings at once.
Will have to try that and see if the AC3 encoding still works.

If I find that I can run two encodes at once then I'll be set.
Probably be turning on all the Threads then.

May to have to remove that silicone pad finally and put
in the top end heat paste...Grizzly Kryonaut rated=12 vs pad=6.
60s C is ok, 70s C is not.

-----------------
@techguy
1)high bitrates (think Blu-ray quality or higher)
-----So right there! Core use skyrockets.
Because of the heavy load, I avoid HD material
unless that is the sole source.
So thankful that I find dvd quality "good enough".

----------Here is some interesting info I got------------(uses FFmpeg I believe)
As an FYI, the mpeg2 decoder will use up to 8 threads but on SD, and even some HD material it's probably effectively less. However, the mpeg2 decoder will decode SD on your system at 250-400 FPS.

Looking at the X.264 encoder threading logic, it will use up to 3 threads for SD material in the first pass. It's basically height in pixels / 128. The comments in the code says that more threads reduces quality in pass 1.

Pass 2 threading uses max 32 threads for encoding on HD, and about 15 threads for SD. At one point we experimented with letting you set the thread counts, but it turned that x264 does an optimal job automatically.
------------------------------------------------------------------------------------------------
That explains my "Pass 2"(X264) being 5 times faster then "Pass 1".
(With VideoReDo) So wish I could use it.
But deinterlacing does not work with X264 and 2:3 pulldown video.
(H264 works but so slow)

Thanks again to all for the ideas!
jmc2