C++ does not support hyperthreading?

Red Squirrel

[H]F Junkie
Joined
Nov 29, 2009
Messages
9,211
Is this true? I don't have a HT box to test with, but someone was saying that to take advantage of HT you need to use C# or some other languages, but that C/C++ does not support it. That is news to me, since I thought HT was strictly a hardware thing, and had nothing to do with software. The OS just sees it as 2 cores and will schedule multithreaded apps the same was as if it was a real multi core.
 
Last edited:
since I thought HT was strictly a hardware thing, and had nothing to do with software. The OS just sees it as 2 cores and will schedule multithreaded apps the same was as if it was a real multi core.

Well not quite, an intelligent scheduler will treat a second thread on the same core slightly differently than a second core. You're right though, any language can fully utilize HT as long as the operating system supports it, it's not visible (in any meaningful way) at all to user code.
 
There's no concept of a thread in the language definitions of C or C++. That doesn't mean that you can't use them, you just have to use an OS-specific library to get to the functionality. C#, OTOH, has the concept of threads & thread-safety baked in from the beginning.

Your friend is half right. The dangerous sort of half-right.
 
Hmm so if I write a multithreaded C++ app, it should take advantage of HT then right, because of the library being able to handle it? He was reading something online, wish I had asked for the link as maybe he missinterpreted.
 
Hmm so if I write a multithreaded C++ app, it should take advantage of HT then right, because of the library being able to handle it? He was reading something online, wish I had asked for the link as maybe he missinterpreted.

The OS is responsible for scheduling the threads, and thus the OS is the thing that must support HT. As long as your language is able to create multiple threads or processes to do its work, the OS will treat it like any other thread/process, and utilize the SMT resources.

Probably ameoba is right, your friend is probably confusing the fact that C++ doesn't have native support for threads with hyperthreading - they are wholly different things. Even lacking thread support (which is available for C++ through libraries), it's still possible to utilize SMT resources with other techniques.
 
Ahh ok, makes sense then. So it's like saying C++ does not support GUIs. By default C++ does not really "support" much. But by using libraries then you can implement pretty much whatever you want.
 
The article is garbage. There are no hyper-threading-specific instructions, as the author says, to take advantage of regardless of what language you're using. His "pig_function()" example is nonsense. He's right that page faults are slow, but he's wrong about his implications for their causes. His advice about mixing C++ and C# using interop is too vague, and can lead to terrible performance without careful factoring.

Your original question is "C++ does not support hyperthreading?". The answer depends on what you mean by "support". At one level, you could argue that C++ doesn't support any form of threading because nothing in the language or the standard libraries offers threading support. A C++ program that uses threads is using a non-standard library or a platform-specific API of one form or another. C#, on the other hand, has threading features built in to its standard library, the .NET Framework.

On the other hand, given one of those libraries, there's nothing in C++ that precludes the use of hyper-threading.
 
i think programs can be optimized (on a binary level) to prevent pipeline stalls, this would be the default condition in a loop, there may be other things necessary in terms of resource sharing to make HT work well. Your C++ compiler may have options to generate that type of code.

Intel also has some docs on it. You can start here....
http://software.intel.com/en-us/articles/intel-hyper-threading-technology-your-questions-answered/
and grab PDFs that document programming the processors.

If you can find compiler switches for it though, that is the way to go.
 
In some ways, I don't even think it makes sense to talk about language support for SMT. It's a hardware feature largely transparent to software.

An SMT capable CPU will happily share its ALUs across two threads, regardless of what language they were originally written in.

This isn't to say there aren't programming considerations, but I would classify that as optimization, not support.
 
Last edited:
no, there are considerations. the virtual cpus share resources. if the instruction sets use a lot of these instructions you get stalls. I don't know how likely that is, but generally if a cpu has a "feature" then it really helps for programs to be compiled to use the "feature"
 
Right, but even then, it's not a language "feature" that is "supported".

Like any language, it's subject to limitations of its abstraction. Doing lots of floating point instructions on a desktop is no big deal, but on a microcontroller that can be real rough, even though the same C program could be compiled for each.

no, there are considerations. the virtual cpus share resources. if the instruction sets use a lot of these instructions you get stalls. I don't know how likely that is, but generally if a cpu has a "feature" then it really helps for programs to be compiled to use the "feature"
 
Back
Top