• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

Hyperthreading: does it only apply to threaded apps?

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.

magellan

Member
Joined
Jul 20, 2002
The only multi-threaded/multi-process programming I've ever actually done was on *ix. In that paradigm, a thread (i.e. as defined in the pthreads library) is not a process as it shares the memory space of the parent process and doesn't have an independent memory address space (and all the threads spawned from a process share the same PID).

In order to take advantage of Intel's hyperthreading from an application programmers' standpoint does your application have to be multi-threaded (i.e. SMT capable)?
 

Janus67

Benching Team Leader
Joined
May 29, 2005
I'm not sure what you mean, do you mean in order for an application to utilize a non-physical (HT'd core/thread) does it have to be coded that way? I would assume that the processor/windows decides which applications to put on which core/thread. In order to utilize more than 1 core/thread the application has to be coded to take advantage of it.

At least that's my assumption.
 

Mr.Scott

Beamed Me Up!
Joined
Jun 9, 2013
I'm not sure what you mean, do you mean in order for an application to utilize a non-physical (HT'd core/thread) does it have to be coded that way? I would assume that the processor/windows decides which applications to put on which core/thread. In order to utilize more than 1 core/thread the application has to be coded to take advantage of it.


At least that's my assumption.
You would be correct.

Although setting affinity does give you some manual control over what program goes to what core/thread.
 
OP
M

magellan

Member
Joined
Jul 20, 2002
You would be correct.

Although setting affinity does give you some manual control over what program goes to what core/thread.

But by this reasoning, there's no difference between SMP and SMT.

When I look at task manager in windows, there are commonly several threads associated w/a process, but all those threads have the same PID (as they would in the *ix paradigm). In *ix this is the difference between fork(ing) a process w/a brand new PID and memory space and using pthread_create to create a new thread with the same PID and memory address space.

I'm thinking only applications written to use multi-threading can use hyperthreads. For example, if I wrote a DOS mode program, I don't think it would be possible for it to use hyperthreading. I'd think only a parent process and its associated threads can use hyperthreading.
 

Mr.Scott

Beamed Me Up!
Joined
Jun 9, 2013
Dos is single threaded.
I'll give you example though. Using a 1c/2t processor.
Set affinity for your DOS program to core 1 and everything else to core 2.
More of your resources will be applied to your DOS program.
 
OP
M

magellan

Member
Joined
Jul 20, 2002
Dos is single threaded.
I'll give you example though. Using a 1c/2t processor.
Set affinity for your DOS program to core 1 and everything else to core 2.
More of your resources will be applied to your DOS program.

I'd think the DOS program, which runs in a 16-bit VM, would be arbitrarily
assigned to one or the other core anyway?

In task manager which cores are the hyperthread cores? Are they always
the odd numbered cores?
 

OC-NightHawk

Member
Joined
May 13, 2003
If I recall the way it was explained to me back when hyper threading first was released, the execution logic that would have gone to waste from the physical core is some how able to be reused as a second thread. HT will never be as fast as the actual core because of the nature of it using remaining execution logic that was unused. However if looked at in the sense of it wringing out every bit of execution logic it can from the core system performance is increased overall.

In answer to your question I do not believe the program needs to be programmed to work with hyper threading. :D
 

caddi daddi

Godzilla to ant hills
Joined
Jan 10, 2012
"In answer to your question I do not believe the program needs to be programmed to work with hyper threading."
they why does my maya program only use the number of "real cores" on a cpu and will never use any HT, weather the cpu is 4c/8t or 6c/12t?
the software seems to have to be written to use HT.
 

Mr.Scott

Beamed Me Up!
Joined
Jun 9, 2013
"In answer to your question I do not believe the program needs to be programmed to work with hyper threading."
they why does my maya program only use the number of "real cores" on a cpu and will never use any HT, weather the cpu is 4c/8t or 6c/12t?
the software seems to have to be written to use HT.
You are correct. Hence why I said set affinity of his program to a real core and the backround OS stuff to the HT. OS's will run on HT. Bencher's do it all the time on single threaded benches. It provides more resources for the benchmark. You know this, I don't need to explain it.
 

JrClocker

AKA: JrMiyagi
Joined
Sep 25, 2015
When you write code in Windows (.Net), you can do one of the following:

1. Use the parallel libraries: .Net will load up as many threads as it can, and schedule them into the Windows thread manager. Less overhead per thread, but you can only run as many threads at once as Windows says are available (HT cores)

2. Manually create your threads (thread pool in .Net is the easiest), and let Windows thread manager schedule them.

3. Manually create and manage your own threads.

(1) is the best if you have a large crunch task...parallel.for, parallel.foreach, and linq expressions work well here.

(2) is good if you need to launch and coordinate many tasks, and take advantage of the event driven nature of Windows

(3) is good if you need deterministic behavior from Windows.

If your app doesn't do anything special, it will only run in 1 thread.

Multithreaded programming requires that you avoid thread stalls, thread locks, data corruption, etc. (multiple threads trying to access the same data at the same time.). Too many "lock" statements will slow down your code.

You can have your code query the system for the number of cores and hyperthreaded cores...and do (3) accordingly.

At the end of the day, you can only run a maximum simultaneous number of threads as the cores (hyper threaded) that the system has.


 

OC-NightHawk

Member
Joined
May 13, 2003
"In answer to your question I do not believe the program needs to be programmed to work with hyper threading."
they why does my maya program only use the number of "real cores" on a cpu and will never use any HT, weather the cpu is 4c/8t or 6c/12t?
the software seems to have to be written to use HT.

I haven't worked on the code in Maya but based on experience I can say that in Windows it is possible to use an API call to enumerate the number of cores in the machine and determine if the machine is using hyper threading. From there it is a simple matter of a little branching logic. Maybe in Autodesk's thought process they decided they didn't want to have more threads then actual cores. However by itself this doesn't mean a thread for Maya won't execute on a core that is actually HT. Unless you go in and set the process to only run on certain cores the task manager will hop the threads onto any core available.

Code:
If (HT == True)
{
    NumThreads = NumProcessors / 2;
}
Else
{
    NumThreads = NumProcessors;
}

- - - Updated - - -

You are correct. Hence why I said set affinity of his program to a real core and the backround OS stuff to the HT. OS's will run on HT. Bencher's do it all the time on single threaded benches. It provides more resources for the benchmark. You know this, I don't need to explain it.

That is a wonderful tactic. Background tasks get the left over logic. :D
 

caddi daddi

Godzilla to ant hills
Joined
Jan 10, 2012
mr scott is dead on, as per normal.
my arnold/maya/nuke will not use HT so it's just not of any interest to me.
on my rigs that have it I just turn it off.
 
OP
M

magellan

Member
Joined
Jul 20, 2002
When you write code in Windows (.Net), you can do one of the following:

1. Use the parallel libraries: .Net will load up as many threads as it can, and schedule them into the Windows thread manager. Less overhead per thread, but you can only run as many threads at once as Windows says are available (HT cores)

2. Manually create your threads (thread pool in .Net is the easiest), and let Windows thread manager schedule them.

3. Manually create and manage your own threads.

(1) is the best if you have a large crunch task...parallel.for, parallel.foreach, and linq expressions work well here.

(2) is good if you need to launch and coordinate many tasks, and take advantage of the event driven nature of Windows

(3) is good if you need deterministic behavior from Windows.

If your app doesn't do anything special, it will only run in 1 thread.

Multithreaded programming requires that you avoid thread stalls, thread locks, data corruption, etc. (multiple threads trying to access the same data at the same time.). Too many "lock" statements will slow down your code.

You can have your code query the system for the number of cores and hyperthreaded cores...and do (3) accordingly.

At the end of the day, you can only run a maximum simultaneous number of threads as the cores (hyper threaded) that the system has.

Does the Windows paradigm have anything to facilitate SMP programming (e.g. fork in *ix)?

- - - Updated - - -

Code:
If (HT == True)
{
    NumThreads = NumProcessors / 2;
}
Else
{
    NumThreads = NumProcessors;
}

- - - Updated - - -



That is a wonderful tactic. Background tasks get the left over logic. :D

Wouldn't the number of threads be equal to twice the number of cores?
 

JrClocker

AKA: JrMiyagi
Joined
Sep 25, 2015
Does the Windows paradigm have anything to facilitate SMP programming (e.g. fork in *ix)?

Yes..all the standard threading functions. The newer .Net libraries (4.0 and higher) eliminate the need for using "forks" and the related tools. Of course, you have to change your programming logic to take advantage.



 

OC-NightHawk

Member
Joined
May 13, 2003
Does the Windows paradigm have anything to facilitate SMP programming (e.g. fork in *ix)?

- - - Updated - - -



Wouldn't the number of threads be equal to twice the number of cores?

If you look in device manager you can see how the processor is enumerated by Windows. Windows see the core and the HT both as individual processors. This is why Microsoft makes the distinction of how many sockets are in use and places restrictions on sockets for some Windows types.

So if you want a thread count limited to the number of cores in the processor which has HT you have to divide by two. Keep in mind that if affinity is not manually set in Task Manager it doesn't mean the threads can't be run on a HT thread.
 

Zantal

Member
Joined
Mar 19, 2009
Your thread is another logical abstraction from the processors of windows, So even when you run a single threaded program, you won't know on which logical thread it will run on (unless using affinity) but ultimately you definitely won't know on which physical core it is running on be it in HT mode or not. CPUs nowadays have a mind of their own.

I am not 100% sure because I think I read about it something like 6 years ago but I remember that the cpu is in charge of the execution logic and it decides to run stuff where it wants to based on some rules, the only one I remember being core temperature, if a core is too high it unloads from that one to another to even out the temperature.

Please someone correct me on this.

To take advantage of HT while programming, just use all threads available and let the OS decide, I never really understood why someone would limit the thread count to the actual number of cores, Every time I built a MT program I have always seen noticeable gains when setting the highest number of threads possible.