questions about threads

[Special K]

Maybe this would be appropriate to post in the discussion about SMT, but since I wasn't sure (and because it a more general question), I decided to make a new topic about it. The way I understand it, a thread is basically a piece of a program that can be executed independantly of others. I also understand that in order to make use of a dual or multi-processor machine, you need software that was specifically written for it, i.e. multi-threaded software. Here is what I do not understand: if I look at task manager in win2k, I can see that many of the processes listed have more than one thread. Yet by reading the many posts in GH about people asking about whether they should get a dual-processor computer or not, I was led to believe that there is not a large amount of software out there that actually makes use of more than one processor. So my question is, does any process with more than one thread benefit from more than one processor, or is there some other characteristic that a program must have in order to benefit from more than one processor? Also, what about quad processor (and above) systems? Does software have to be specifically written to take advantage of 4 processors, or will any program that can make use of two processors also be able to automatically use four?

 

[Nothinman]

Getting a dual box isn't a bad idea even if you don't run many multithreaded apps because the OS will take advantage of it and you'll be able to have 2 processes running at once. You won't notice a huge speed increase but multitasking will be much smoother, and one program eating all the CPU won't crush the box.

So my question is, does any process with more than one thread benefit from more than one processor, or is there some other characteristic that a program must have in order to benefit from more than one processor?

Well I can have a process with 2 threads, but have one central lock on the main data set, meaning that any time one of the threads wants to work on the data set it has to hold the lock leaving the other waiting on the lock. You'll get some speed increase but nothing amazing. The program has to be designed with multithreadedness in mind, otherwise it'll either not get a speed boost or it'll crash randomly (multiple threads writing to the same data in memory without some locking is bad).

Also, what about quad processor (and above) systems?

If you have a 2 threaded process the other 2 CPUs will be idle (or more likely doing some OS related things in the background).

It wouldn't be terribly hard to have your program find out the number of CPUs and launch an appropriate number of threads, but again the programmer has to write the program thinking there might be more than one CPU.

 

[bsobel]

> Here is what I do not understand: if I look at task manager in win2k, I can see that many of the processes listed have more than one thread.

The thread count of a program can be misleading when determining if it makes since to move to a SMP platform. The issue is not the number of threads that an application has, it's the number of schedulable threads. A scheduleable thread is one that has work to perform but is waiting for CPU time to be assigned to it.

A lot of applications have non scheduable threads, they are non schedulable because they are just sleeping waiting for some event to awaken them to perform work. A spreadsheet program may have a background thread that does recalculations. Unless a change was made to the spreadsheet the requires a recalc, the thread just keeps sleeping. So, while the program has two threads (in this example) the main UI thread and the recalc thread, only one is 'scheduable' most of the time. Getting a SMP system would do little to nothing to speed this program up.

Now take a multithreaded game where one thread is responsible for the games AI and is constantly calculating the compters next 'move' while other threads handle IO and graphics. In that case it's more likely to have multiple scheduable threads at the same time, and an SMP machine would indeed help.

Make sense?
Bill

 

[Special K]

<< Now take a multithreaded game where one thread is responsible for the games AI and is constantly calculating the compters next 'move' while other threads handle IO and graphics. In that case it's more likely to have multiple scheduable threads at the same time, and an SMP machine would indeed help. >>



Then why are there so few games that take advantage of more than one processor? Or is it just because software companies figure that the amount of gamers with dual processor machines is not worth the time and money it would take them to implement it?

 

[bsobel]

> Then why are there so few games that take advantage of more than one processor? Or is it just because software companies figure that the amount of gamers with dual processor machines is not worth the time and money it would take them to implement it?

The bread and butter for the game companies is still the 9X/ME platform. That will graduallly change as XP rolls out, but even there the home editon is single processesor. Now, the Foster technology in the new P4's may help, by simulating multi-processesor on a single chip (to give a 10-20% performance boost) may eventually cause more designers to take advantage of multithreaded design.

Bill

 

[Nothinman]

Now, the Foster technology in the new P4's may help, by simulating multi-processesor on a single chip (to give a 10-20% performance boost) may eventually cause more designers to take advantage of multithreaded design.

Sort of OT, but one thing I found funny was that MS was trying to get Intel to drop that technology because they currently charge higher prices for more CPU support and having 1 CPU look like 2 screws their licensing scheme all up.

Q3A was the only SMP supporting game I know of, and it's support was rather poor. It gave very little speed boost on NT and was disabled on Linux because of problems.

 

[bsobel]

> Sort of OT, but one thing I found funny was that MS was trying to get Intel to drop that technology because they currently charge higher prices for more CPU support and having 1 CPU look like 2 screws their licensing scheme all up.

Actually, I talked with Intel about this exact thing, at the hardware level MS definately knows the number of physcial cpu's, so the licensing stays according to physical cpu's not logial cpu's. The only thing I never got a clear answer to is how MS was handling this in XP home. I got the *impression* that XP home would indeed see two cpu's in this environment, but I havent tested XP home on any Foster chips to verify that.

Bill

 

[Special K]

I know there must be a problem with what I am about to ask (otherwise it would have been done already), but to take advantage of a dual processor computer, why couldn't the program just send every other instruction of the program to the other CPU? (ex. have CPU0 execute all of the even instructions and have CPU1 execute all of the odd ones)? Wouldn't that give almost double the performance?

 

[Nothinman]

For several reasons:

Not all operations take the same amount of time. You would get out of sync very quickly.
You want to keep the same process on the same processor as much as possible to keep cache hits up. If you keep swapping back and forth you have to save/restore the registers each time and you either have duplicated data in the caches or you have to keep going back to memroy because the cache doesn't have the correct data, and memory access is a lot slower than cache.
If the process isn't written for threading you'll have both processors accessing the same data, if CPU1's instruction completes before CPU0's and that's out of order you more than likely just got unreliable results in memory.

 

[alanwj]

<< have CPU0 execute all of the even instructions and have CPU1 execute all of the odd ones >>

Consider the set of instructions that might be executed for a typical line of C code such as :
x = x + y ; /* x += y. of course, but I'm using a simpler syntax for clarity. */

Instructions generated:
mov ax, x ; 1) Read x from memory into ax. (ax is a register on the cpu)
mov bx, y ; 2) Read y from memory into bx. (bx is a register on the cpu)
add ax, bx ; 3) Add the contents of bx to ax, store result in ax.
mov x, ax ; 4) Put the result back in memory.

First off, our processors (assuming 2 of them) would have to be extremely well synchronized for the odd instructions to go to cpu0 and the even to go to cpu1. We'll assume that they are. We'll also make the bold and completely inaccurate assumption that each instruction takes only 1 clock cycle. So...

cycle 0 :
cpu0's ax gets x.
cpu1's bx gets y.
No problem here. Both variables were successfully read from memory.

cycle 1 :
Oops #1: cpu0 has x in its ax register, and who knows what in its bx register. So the result will almost certainly be erroneous.
Oops #2: cpu1 is trying to store its ax register back to memory. But we have no idea what is even in ax, so this is a problem.
Oops #3: Provided that the CPUs could somehow share a register set, which would effectively take care of the first two problems, we still would have the problem that cpu0 is calculating the result to be stored back into memory at the same time cpu1 is trying to store it in memory. That certainly can't work.

The sequential nature of programs just won't allow hardware to arbitrarily decide how to thread something. It's pretty easy to see how this approach may fail even more drastically with more complex instructions and more processors.

Alan

 

[Special K]

Are there specific commands in a programming language (such as C) that specifically allow a programmer to create multiple scheduleable threads in a program (and therefore make the program able to take advantage of dual processors) or does the program just kind of "end up" that way as it is developed (that is, there are no specific commands in C that create separate threads)?

 

[Nothinman]

I don't believe there's any built-in threading functions in C, most are an external library like pthreads on most unixes. And if you don't have a thread library you could create seperate whole processes and use some inter-process communication to synchronize them.

 

[Special K]

In the introductory engineering class I took last semester, one of our projects involved programming one of those lego robots to do multiple tasks (simultaneously in some cases). We used a variant of C to program the robot (it was essentially C along with functions that were specific to the robot, such as turn on motors, etc.) and one thing we were able to do was write functions and then put the commands start <task> and stop <task> (without the <> ) to have more than one function run simultaneously. Would that be an example of multiple schedulable threads? It seemed odd to me that it would be so easy to implement something like that on such a cheap processor (just by using the commands start and stop), but not be able to do it that easily on today's modern processors.

 

[Nothinman]

I havn't done much multithreaded programming so I don't know off the top of my head. I believe with pthreads you tell it to create a thread and give it the address of a function to run in the thread and using something like fork (on unix, don't know the function on Windows) you call fork, then compare the returned pid number to figure out whether your'e in the parent or the child (parent gets back the child pid, child gets 0) and put your code inside an if statement. Please don't point out errors in my code or complain about the formatting =)

Kinda like:

if (pid = fork()) {
if (pid == 0) { // in child
do_work()
}
else { // in parent
do_work()
wait_for_child()
}