Multi-threading

[NicolasProy]

Hi!

In the VVenC whitepaper it is mentioned that for the multi-threading tests up to 16 threads are used for FHD sequences.
I tried to use threading in one 1920x1080 sequence and a different 1280x720 sequence with the Full Features expert mode by adding "-tN" in the command, N being the number of threads. It works for up to 8 threads but when I try using 16 threads the time performances are slightly worse than for 8 threads, how come?
The CPU I use is an I9-9900K, with 16 threads by the way.

Thanks in advance,
Nicolas.

[adamjw24]

Dear Nicolas,

Thanks for the inquiry. There are a few points to discuss.

First, I think you have a typo in your description. There needs to be a blank space between the argument short name and value, ie. "-t N".

Now to technical aspects. Which preset did you use? Because of different CTU size, the "faster" and "fast" presets scale much better than the 3 slower presets ("medium", "slow" and "slower"). We didn't test 720p so I don't know how the scaling is there, but 8 threads should be around 5-6x speedup for HD vs single threaded execution.

Further, you have a 8 core/16 thread CPU. We usually test the scaling up to the number of physical cores. Its only very recent that we can even utilize that on modern CPUs, so we don't know how well the encoder scales across virtual cores. Still, we tested the impact of overallocating threads and found it to be small (e.g. 8 threads on process bound to 1 or 2 cores). What kind of speed reduction are you seeing - what does "slightly worse" mean?

You have an Core processor. The Core processors decrease frequency when utilizing more threads. Combined with speedup saturation in VVenC that effect might play a minor role. This behavior is less present on Xeon or a comparable workstation/server processors. This playing a role in your problem is only speculation, though.

If you want to try to increase the threading performance you can always set --WaveFrontSynchro=1 (around 0.5-1% bitrate increse) or --CTUSize=64/32 (3% and more bitrate increase, depending on preset), or both, in the full-featured app. The options should only be used when just increasing the number of threads doesn't improve performance.

Best regards,
Adam

[NicolasProy]

Thanks a lot for the quick and detailed answer!

"-tN" was indeed a typo.

I compared 8 threads and 16 threads on my i9 for a 720p video, with the "slow" preset, 4 different QPs, and I have in this case a 16 threads encoding wich is at around 94 % of the speed of the 8 threads encoding.
I also did the same for a 1080p video with the "fast" preset, in this case the speed of the 16 thread encoding ranges from 96% to 99% of the 8 threads encoding, with the lowest speed difference being at the highest QP.

Following the infos you provided in your answer I did a few other tests on a Xeon 16 cores CPU.
I used the two same 720p and 1080p videos with the "faster" preset to compare the 8 and 16 threads options with 16 cores.
For the 720p video with 16 threads there is a speedup of 121% to 134% compared to 8 threads.
For the 1080p video the speedup ranges from 121% to 137%.
In both cases the lower the QP, the higher the speedup.

I did already consider decreasing the size of the CTUs and the use of "WaveFrontSynchro=1", but thanks for the tip anyway ;)

By the way, concerning the multi-threading VVenC uses, I figured WPP is used, but are there any other methods used that take advantage of the multiple threads available? Do you for example process multiple CUs with different threads or several pictures simultaneously?
And, may I ask, are there any big improvement planned for v0.4, especially concerning speed optimisation?

Thank you again for your answer,
Nicolas.

[adamjw24]

Dear Nicolas,

it really seems the number of physical cores and the different behavior of Xeon vs Core make the difference here. I'm glad to see that "faster" can still utilize more than 8 cores even for 720p without additional tuning.

About your follow up questions. Since the version 0.3 VVenC also support frame-level parallelism (encoding multiple frames at a time). It can be controlled using the MaxParallelFrames parameter in the FF-app and is set to min(4, NumThreads) in the simple-app (and also per default in the FF-app, if not specified differently). We don't process multiple CU's within the same CTU in parallel, since the relevant tasks would become very fine-grained and thus short. With many very short tasks the scheduling overhead increases so for now we are not looking into it.

After speed-oriented 0.3 and 0.3.1, the next release will be more about quality and features. For now it's back to smaller incremental improvements with regard to speed.

Best regards,
Adam

[NicolasProy]

Thanks a lot for your answers Adam, they have been very useful!

Best regards,
Nicolas