[Interest] NUMA and processing groups

[Etienne Sandré-Chardonnal]

> That's what they said in the nineties as well. Didn't happen so far.
> Although there are aspects of NUMA in all processors today, it seems the
> general consensus is that you need very specific cases for any affinity
> sensitive code to actually be faster.
>

Yes, except if OSes put your process into a single group by default, and if
you need to manually override affinity for using all cores. Then you have
to be NUMA-aware for using 100% of the CPU.


>
> That said, it's not great the the QThread ideal thread count isn't correct
> (assuming it isn't). If you want to investigate this issue and see if you
> can come up with a fix that doesn't break everything else...
>
>
You are right in the sense that it's not the purpose of Qt to implement
fine-grained affinity. But using a sub-optimal number of cores in
QtConcurrent and by taking the return value of idealThreadCount() is not
good at all.
This means, that idealThreadCount() should be fixed to take into account
all cores, at least.

Disabling NUMA in the BIOS did change the result of idealThreadCount() from
20 to 40, so yes the result was incorrect. I will post a bug report. Under
windows, this is because the function only returns the result from
GetSystemInfo()whereas it should the more complex
GetLogicalProcessorInformation()


> If your system is special hardware, just set the number of threads
> manually.
>

This is not a special hardware : a freshly unboxed standard dual CPU HP
workstation.



>
> Bo Thorsen,
> Director, Viking Software.
>
> --
> Viking Software
> Qt and C++ developers for hire
> http://www.vikingsoft.eu
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20151222/2575b250/attachment.html>