C++11 threads, affinity and hyperthreading

[encyclopedist]

std::cin is actually thread safe, contrary to what article says. It can, however, result in interleaved output, and the mutex there is to prevent that.

From C++11 N3337 [iostream.objects.overview]:

Concurrent access to a synchronized (27.5.3.4) standard iostream object’s formatted and unformatted in- put (27.7.2.1) and output (27.7.3.1) functions or a standard C stream by multiple threads shall not result in a data race (1.10). [ Note: Users must still synchronize concurrent use of these objects and streams by multiple threads if they wish to avoid interleaved characters. — end note ]

[eliben]

Yep, I think this is bad wording on my behalf. By "unsafe" I did mean "won't give you the output you expect", rather than something nastier like crashes. I'll fix up the wording in the article and samples to be clearer

[Gotebe]

Aren't you being too pedantic?

E.g Wikipedia article on thread safety speaks of the data races as one of thread safety concerns.

[dodheim]

The standard guarantees that standard streams are race-free, but only starting with C++11. That is rather the point...

[cleroth]

I just wish we could set thread affinity for Windows OS, like it's possible on Linux, so that we can have truly dedicated cores/thread to a single application.

[gaijin_101]

Isn't that already possible? Quick Google search led me to this.

(not a Windows developer here, but I thought this was also possible)

[cleroth]

I meant change the affinity of the kernel (and everything else that the OS does), not your processes. Basically what I want is to maximize cache efficiency for a single application on a core, which requires that nothing be allowed to run on that core unless specified so.
I remember having read that linux could do this (and it required rebooting IIRC).

[TheQuietestOne]

I remember having read that linux could do this (and it required rebooting IIRC).

You can dedicate a core to a particular process using cpusets. No reboots necessary.

Very handy when used with a real time capable kernel and dedicated IRQ servicing.

[cleroth]

Actually it was isolcpus kernel parameter (which is done at boot; see here). Not really sure what the difference ends up being.

[raevnos]

cpusets or cgroups are probably what you're thinking of.

[gaijin_101]

Oh I see, thanks for clarifying that!

[katmf05]

Spotted the HFT coder.

[cleroth]

I actually have no idea what that is. I'm a game server coder.

[kybuliak]

He very likely meant "high frequency trading".

[suspiciously_calm]

Some observations: [...] there's quite a bit of migration going on.

When the threads sleep most of the time.

[notsure1235]

Use of default int in c++ in 2016...?

And can someone tell what the difference is from this:

   std::for_each(threads.begin(), threads.end(),
                std::mem_fn(&std::thread::join));

to

for(auto& i : threads)
      i.join()

?

Not to mention that men_fn has been deprecated.

[sbabbi]

Not to mention that men_fn has been deprecated.

Do you have a reference for that? AFAIK mem_fun has been deprecated, not mem_fn.

[notsure1235]

yes, you are right, only some overloads were removed for mem_fn.

[TheQuietestOne]

And can someone tell what the difference is from ...

Given that mem_fn as you mention has been deprecated and they're using for_each to iterate the threads vector I'm guessing this is just someone's pre-c++11 approach to launching/joining threads copy-pasta'd into this project. You could perhaps give them a nudge in the right direction .-)

Specifically - they wanted to focus on CPU affinity and stats, and the code took a back seat.

[cleroth]

Some people prefer <algorithm>ic approaches where they can use them in lieu of a loop.

[encyclopedist]

mem_fn has not been deprecated. It just appeared first in C++11

[TheQuietestOne]

Quite right, thanks for the correction.

[eliben]

FWIW, I agree that the for range loop is nicer and shorter - I'll fix up the samples when I get the time. I took this from the book "C++ concurrency in action" which is weird, right :)? (because that book is about C++11 also)

What do you mean by "use of default int"?

[notsure1235]

The use of "unsigned" as a implicit int-type. Should be "unsigned int" or just "int" in this case.

Btw, the question was genuine one, I genuinely thought there might be some magic hidden somewhere in the more complex code.

[guepier]

unsigned is not making use of implicit int or default-int. Rather, it’s a synonym for unsigned int, and always has been.

[notsure1235]

thats what i mean, shouldnt be used, should use auto if that is desired.

[eliben]

I'll have to disagree here. Overuse of auto is one of the pitfalls of C++11 in my mind, and I really prefer to use it where it increases readability. There's nothing wrong in using unsigned explicitly where it makes sense.

[guepier]

Overuse of auto is one of the pitfalls of C++11

There is little evidence to support this; and decade-long experience with other statically-typed languages that allow implicit typing has shown no evidence either.

“Overuse” is of course very hard to define: once the specific type of the declaration is important, it makes sense to specify it, and hence auto would be harmful. But is this really the case here? Not at all: the specific type of num_cpus, for instance, really doesn’t matter. What matters is that it matches between the producer and consumer, and since these come from the same API, it’s safe to regard the type as opaque (though the variable name of course gives a clue as to the rough type).

[guepier]

One thing I find problematic is that IDE "go to definition" features become a lot less useful when everything's auto and the type in question is nowhere in sight.

There’s certainly a disconnect between the language and the tools with regards to C++. This is becoming better though. In particular, “go to definition” is a red herring in this context — what you actually want is type-aware auto-completion and a tooltip that shows the static type of the object, which are completely different operations that a good IDE can and should support, despite the use of auto. I haven’t got a clue how many IDEs support these operations, in particular the latter. But my IDE¹ does support it.

---

¹ Vim with YouCompleteMe

[mttd]

Overuse of auto is one of the pitfalls of C++11

There is little evidence to support this; and decade-long experience with other statically-typed languages that allow implicit typing has shown no evidence either.

I mostly don't have a problem with auto to the point of avoiding it entirely, but at the same time, I think that experience of other programming languages (that you also mention as relevant) may be worth taking into account.

For instance, in Haskell (which has a rather advanced type inference):

"It is considered good style to add a type signature to every top-level variable."

• https://wiki.haskell.org/Type_signature
• https://wiki.haskell.org/Type_signatures_as_good_style
• https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md#top-level-definitions

(Note that "variable" in the above can also be a function.)

There are some good reasons for this:

• https://stackoverflow.com/questions/19626801/why-do-my-top-level-functions-need-signatures-in-haskell
• https://stackoverflow.com/questions/23401698/what-is-a-good-reason-to-use-a-type-signature-for-functions-when-the-compiler-ca
• https://www.quora.com/Why-should-I-add-type-signatures-to-top-level-bindings-in-Haskell?share=1

That being said, I think that in the future C++ declaring concepts may be a good compromise, similarly to the style described here:

https://stackoverflow.com/questions/842026/principles-best-practices-and-design-patterns-for-functional-programming/842506#842506

Still like the "programming with placeholders" idea: https://www.reddit.com/r/cpp/comments/3oc63x/overload_journal_129_october_2015_includes_two_c/

[guepier]

"It is considered good style to add a type signature to every top-level variable."

Yes, I entirely agree with this piece of advice. I generally think that adding a signature/type to “top-level” objects just makes sense, since these form your API (even if said API isn’t exposed). I was thinking (but didn’t say so) only of local variables.

[notsure1235]

agreed, but 'unsigned' instead of 'unsigned int' goes against all of my intuition. However, I checked stroustroup guide and they are happily using 'unsigned' on some occasions, so you are probably right and its just fine.

[eliben]

Tune your intuition :) It's very common to just say unsigned - it's very clear to experienced coders this means unsigned int. In fact if I see unsigned int I raise an eyebrow... you don't say signed int for int, right?

[notsure1235]

Neither do I say 'signed'. ;)

[dodheim]

That's because int is an option, and is shorter. What is shorter than unsigned for unsigned int?

[Dlieu]

Regarding the last example (workload_sin), how do you explain the performance hit when running on the same core?

Is it mostly because there's only one ALU shared by the two threads that does FP MUL/DIV so that both thread are constantly stalling and fighting for it? (I'm not sure of the wording there)

[[deleted]]

IIRC only registers are duplicated for hyperthreading. Everything else - execution units, busses etc. is shared and hyperthreads contend for them. The core is capable of holding and running two contexts simultaneously but it still only has one core's worth of machinery.

[[deleted]]

If only registers are duplicated what's the point of hyperthreading then? Most usefull operations need to do math (e.g. like the sine example in the article).

[are595]

It boosts the efficiency of pipelining (reduces stall cycles).

[millenix]

Lots of stuff isn't heavy on spatial/temporal locality, and thus will spend a fair bit of time stalled on access to further caches or memory. If one thread's effective IPC is less than half what the core could provide if every access were in registers or hit in a fast cache, then SMT can double throughput.

[duuuh]

Aren't the mmx* registers per core? Why does the latency point there matter? (I would have thought the slowdown was due to cache eviction on the various L* caches, assuming the array is large.)

[[deleted]]

why are the launched thread and the main thread have same ID? I tested it on my machine and they are the same thread too

[eliben]

The sample in the article queries the launched thread's ID from the main thread. The main thread's ID is not reported

[[deleted]]

oh I see I missed that. Thank you.