Page 1 of 1

Efficient use of high core counts in next gen chips

Posted: Fri Jul 28, 2017 3:46 pm
by db1964
Please describe what you would like to see added to HandBrake:
According to the documentation Handbrake shows diminishing returns on processors with more than 6 cores. The recently released AMD Ryzen has 8 cores and the i9 has 10 with apparently more on the way ( possibly all the way to 18 ) . Are there any plans to develop Handbrake to fully utilize these core counts ? If so any guess on time scales ?

Why would you like to see this added:
Everyone want to speed up their encoding and fully use the capabilities of their hardware.

What version of HandBrake are you currently running:
1.0.7

What operating system and version and you currently running (e.g. OSX 10.11, Windows 7, Ubuntu 14):
Windows 10

Re: Efficient use of high core counts in next gen chips

Posted: Fri Jul 28, 2017 3:56 pm
by mduell
Entirely dependent on the underlying libraries, HB doesn't do any work here.

Also the "6" figure is a bit misleading, given the incredible range of sources and settings. It can be anywhere from 2 to 20 depending on your source and settings.

Re: Efficient use of high core counts in next gen chips

Posted: Fri Jul 28, 2017 5:48 pm
by BradleyS
x264 does have diminishing returns beyond about 8 cores at reasonable settings. You can use a slower x264 preset to better saturate more cores. Generally speaking, this is a mature codec and a limitation of its design. That said, there are new AVX-512 optimizations just hitting x264 master now, so performance will definitely improve overall on newer hardware soon enough.

x265 is based on x264 and seems to scale better with high core counts.

Re: Efficient use of high core counts in next gen chips

Posted: Fri Jul 28, 2017 7:39 pm
by mduell
BradleyS wrote: Fri Jul 28, 2017 5:48 pmx264 does have diminishing returns beyond about 8 cores at reasonable settings.
But the video encoder is only part of the story; there's a decoder thread(s), various filters that can be multithreaded, etc

Re: Efficient use of high core counts in next gen chips

Posted: Fri Jul 28, 2017 7:44 pm
by BradleyS
Absolutely. NLMeans for one can always use more cores and faster memory I/O. Should be considerably faster on upcoming hardware based on currently published specs.

Re: Efficient use of high core counts in next gen chips

Posted: Sat Jul 29, 2017 2:08 am
by nhyone
For slower presets (slower, veryslow, placebo), x264 is limited by the encoder. You can use 10+ cores, no problem. (But they won't be at 100% for other reasons.)

For faster presets, x264 is bottlenecked by its lookahead. It can't analyze the video fast enough to feed the encoder.

There are two more considerations when using many cores.

First, the output video will not be as compressed. The output is maybe 1-5% bigger. Quality is the same.

Second, if you are using dual CPU or Ryzen CPU with its CCX architecture (4 core per CCX), efficiency drops when you use all the cores. It is better to use each CPU / CCX to encode one video at the same time.

Re: Efficient use of high core counts in next gen chips

Posted: Sat Jul 29, 2017 2:22 pm
by db1964
Are you saying that Handbrake will be looking at releasing a version that can encode multiple sources simultaneously ? That would be another way to fully leverage the available hardware I suppose.

Re: Efficient use of high core counts in next gen chips

Posted: Sat Jul 29, 2017 2:41 pm
by rollin_eng
You can run multiple instances of HB already.

Re: Efficient use of high core counts in next gen chips

Posted: Sat Jul 29, 2017 2:42 pm
by s55
There is nothing stopping you running multiple instances of HandBrake today. That may eventually one day become 1 Instance, multi-encodes but there is a lot of other work to do first.

Re: Efficient use of high core counts in next gen chips

Posted: Mon Aug 07, 2017 4:54 pm
by DrXenos
Trying to reduce execution time via adding more cores will alway butt up against Amdahl's Law. There will be a point of diminishing returns for any process that isn't fully parallelized.