[x265] Question about NUMA and core/thread use

[Michael Lackner]

Thank you very much for your input!

Since --pmode and --pme seem to break NUMA support, I disabled them. I simply cannot tell
users that they have to switch off NUMA in their UEFI firmware just for this one
application. There may be a lot of situations where this is just not doable.

If there is a way to make --pmode --pme work together with x265s' NUMA support, I'd use
it, but I don't know how?

Ah yes, I've also found that 8K does indeed help a ton. With 4K and similar settings, I'm
able to load 16-25 CPUs currently, sometimes briefly 30. With 8K, load is much higher.

Maybe you can advise how to maximize parallelization / loading as many CPUs as possible
without breaking NUMA support on both Windows and Linux.

I'm saying this, because my benchmarking project is targeting multiple operating systems,
it currently works on:
  * Windows NT 5.2 & 6.0 (wo. NUMA)
  * Windows NT 6.1 - 10.0 (w. NUMA)
  * MacOS X (wo. NUMA)
  * Linux (w. and wo. NUMA)
  * FreeBSD, OpenBSD, NetBSD and DragonFly BSD UNIX (wo. NUMA)
  * Solaris (wo. NUMA)
  * Haiku OS (wo. NUMA)

Thank you very much!

Best,
Michael

On 05/10/2017 07:21 AM, Pradeep Ramachandran wrote:
> Michael,
> Adding --lookahead-threads 2 statically allocated two threads for
> lookahead. Therefore, the worker threads launched to work on WPP will 32-2
> = 30 in count. We've found some situations in which statically allocating
> threads for lookahead was useful and therefore decided to expose it to the
> user. Please see if this helps your use-case and enable appropriately.
> 
> Now as far as scaling up for 8K goes, a single instance of x265 scales up
> well to 25-30 threads depending on the preset you're running in. We've
> found pmode and pme help performance considerably on some Broadwell server
> systems but again, that is also dependent on content. I would encourage you
> play with those settings and see if they help your use case. Beyond these
> thread counts, one instance of x265 may not be beneficial for you.
> 
> Pradeep.
> 
> On Fri, May 5, 2017 at 3:26 PM, Michael Lackner <
> michael.lackner at unileoben.ac.at> wrote:
> 
>> I found the reason for "why did x265 use 30 threads and not 32, when I
>> have 32 CPUs".
>>
>> Actually, it was (once again) my own fault. Thinking I know better than
>> x265, I spawned
>> two lookahead threads starting with 32 logical CPUs ('--lookahead-threads
>> 2').
>>
>> It seems what x265 does is to reserve two dedicated CPUs for this, but
>> then it couldn't
>> permanently saturate them.
>>
>> I still don't know when I should be starting with that stuff for 8K
>> content. 64 CPUs? 256
>> CPUs? Or should I leave everything to x265? My goal was to be able to
>> fully load as many
>> CPUs as possible in the future.
>>
>> In any case, the culprit was myself.
>>
>> On 05/04/2017 11:18 AM, Mario *LigH* Rohkrämer wrote:
>>> Am 04.05.2017, 10:58 Uhr, schrieb Michael Lackner <
>> michael.lackner at unileoben.ac.at>:
>>>
>>>> Still wondering why not 32, but ok.
>>>
>>> x265 will calculate how many threads it will really need to utilize the
>> WPP and other
>>> parallelizable steps, in relation to the frame dimensions and the
>> complexity. It may not
>>> *need* more than 30 threads, would not have any task to give to two
>> more. Possibly.
>>> Developers know better...
>>
>> --
>> Michael Lackner
>> Lehrstuhl für Informationstechnologie (CiT)
>> Montanuniversität Leoben
>> Tel.: +43 (0)3842/402-1505 | Mail: michael.lackner at unileoben.ac.at
>> Fax.: +43 (0)3842/402-1502 | Web: http://institute.unileoben.ac.
>> at/infotech
>> _______________________________________________
>> x265-devel mailing list
>> x265-devel at videolan.org
>> https://mailman.videolan.org/listinfo/x265-devel

-- 
Michael Lackner
Lehrstuhl für Informationstechnologie (CiT)
Montanuniversität Leoben
Tel.: +43 (0)3842/402-1505 | Mail: michael.lackner at unileoben.ac.at
Fax.: +43 (0)3842/402-1502 | Web: http://institute.unileoben.ac.at/infotech