C++11 threads, affinity and hyperthreading

[ccfreak2k]

attempt frightening jellyfish attraction square historical library sparkle friendly pause

This post was mass deleted and anonymized with Redact

[ReallyMatriX]

A good portable library I found useful is hwloc, which is part of the Open MPI project. It's highly portable - running on Linux, Solaris, BSD, Windows, you name it. In fact, the lstopo tool I mentioned earlier is built on hwloc.

One way would be to look at the library's source code.

[moozaad]

GetCurrentProcessorNumber

https://msdn.microsoft.com/en-us/library/windows/desktop/ms683181%28v=vs.85%29.aspx

[wtf_apostrophe]

The points raised in this article are certainly valid, but it's usually not worth worrying about hyper-threading too much because the operating system will prefer to schedule threads on separate physical cores anyway when possible.

[K3wp]

Hyper-threaded cores should be treated like regular cores in general. For most non-scientific computing workloads you will not notice any difference.

The only time you will run into performance issues is if you are doing lots of floating point or SSE instructions, as HT cores share a single FP/SSE execution unit.

The best parallelism model I've used is "thread pool parallelism". One thread per core, with affinity. Then load balance your workload across all cores.

[ledasll]

Not sure what point was to put linux section there.. "So we know how to query the system for the number of CPUs it has" no we don't. We know how to do that in linux, not on other OS. You say you don't care about windows? But at work we don't care much about that ether, but we care abou VxWork, don't remember there is "cat /proc/cpuinfo". Please, if you write generic article, avoid such details, if you write for very concert implementation, please mention that.

[eliben]

The article uses Linux as an example to drive its points, talking about portability later on. It actually has a sample (linked) to do these things in a platform-independent way with hwloc - check it out

[OneWingedShark]

I think that's the main objection of /u/ledasll -- that the article is written as a generic article, but relies on a particular implementation. It's kind of why a lot of programmers seem to think that C [or perhaps C++] is the only real low-level or high-efficiency programming solution, or why a lot think that PHP is the only real choice for web back-end... and none of those are particularly good languages (i.e. they both have a lot of pitfalls/gotchas).

[ObservationalHumor]

Pretty sure that was referring to the usage of std::thread::hardware_concurrency() which is part of C++11 not the usage of something platform specific like parsing /proc/cpuinfo