multi-cores & multi-processors how does that effect threaded programming?

[Coaster]

I am designing a process which will spawn a good number of threads and some
of them will execute a c++ process which is quite memory intensive (although
not multithreaded). This will run on a 2 cpu (both dual core) server. What
do I need to do if anything in order to spread the workload across the cpu's
/ cores in order to tune it properly?

I googled it and found this post but its somewhat dated and didn't know if
it applied to 2.0


http://groups.google.com/group/micr...ad+multi+processor+gc&rnum=1#1caf8e569498ee9b

the posting makes reference to this guide by MS but it only speaks of .Net
1.0 so I'm not sure how accurate it still is in 2.0

http://www.microsoft.com/downloads/...4d-f30e-4e72-b531-75384a0f1c47&displaylang=en


any thoughts or references?

thanks alot

 

[Brian Gideon]

I am designing a process which will spawn a good number of threads and some
of them will execute a c++ process which is quite memory intensive (although
not multithreaded). This will run on a 2 cpu (both dual core) server. What
do I need to do if anything in order to spread the workload across the cpu's
/ cores in order to tune it properly?

I googled it and found this post but its somewhat dated and didn't know if
it applied to 2.0

http://groups.google.com/group/microsoft.public.dotnet.framework.clr/...

the posting makes reference to this guide by MS but it only speaks of .Net
1.0 so I'm not sure how accurate it still is in 2.0

http://www.microsoft.com/downloads/details.aspx?familyid=8a2e454d-f30...

any thoughts or references?

thanks alot

You shouldn't have to do anything. The OS will affinitize the threads
automatically.

 

[not_a_commie]

One thing to watch out for is that the tick count on the various
processors may not be identical. Some vendors have BIOS updates to fix
this. I also understand that Vista handles this issue as well. But if
you're using the StopWatch or high frequency counters accessed some
other way -- watch out! You'll need to set thread affinity on those.

 

[Peter Duniho]

I am designing a process which will spawn a good number of threads and
some of them will execute a c++ process which is quite memory intensive
(although not multithreaded). This will run on a 2 cpu (both dual core)
server. What do I need to do if anything in order to spread the
workload across the cpu's / cores in order to tune it properly?

Nothing really. Keep in mind that for CPU-intensive tasks, it doesn't do
any good to have more threads than you have processors, and in fact adding
more than that many threads will only slow things down due to the context
switch costs. If your tasks involve a lot of i/o, then having lots of
extra threads can help by allowing new work to be started or finished
while other threads are waiting for i/o to complete. It's okay to have a
few extra threads, but if you have too many runnable threads (not waiting
on i/o or other things) at once they will just spend a lot of time
fighting over the processor(s).

Multi-threaded algorithms can get very complicated, there are lots of
little details to get right, and lots of different ways to optimize how
things work. So sure, in that sense you can do lots to ensure that your
code is "tuned properly". But fundamentally, the main goal is to have
just enough threads to ensure that there's exactly one thread that is
runnable for each processor on the computer. If you do that, Windows will
take care of the rest.

The links you posted aren't, I don't think, very relevant to your
question. They do address some relatively esoteric issues related to
multi-threading programming, but I don't think they should affect you.
The same general rules apply.

Pete

 

[Coaster]

Nothing really. Keep in mind that for CPU-intensive tasks, it doesn't do
any good to have more threads than you have processors, and in fact adding
more than that many threads will only slow things down due to the context
switch costs. If your tasks involve a lot of i/o, then having lots of
extra threads can help by allowing new work to be started or finished
while other threads are waiting for i/o to complete. It's okay to have a
few extra threads, but if you have too many runnable threads (not waiting
on i/o or other things) at once they will just spend a lot of time
fighting over the processor(s).

Multi-threaded algorithms can get very complicated, there are lots of
little details to get right, and lots of different ways to optimize how
things work. So sure, in that sense you can do lots to ensure that your
code is "tuned properly". But fundamentally, the main goal is to have
just enough threads to ensure that there's exactly one thread that is
runnable for each processor on the computer. If you do that, Windows will
take care of the rest.

The links you posted aren't, I don't think, very relevant to your
question. They do address some relatively esoteric issues related to
multi-threading programming, but I don't think they should affect you.
The same general rules apply.

Pete

ok thanks for the info, it makes sense, I never thought about it like that.
For the links I was just wondering if the information still applied to the
2.0 environment.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I am designing a process which will spawn a good number of threads and some
of them will execute a c++ process which is quite memory intensive (although
not multithreaded). This will run on a 2 cpu (both dual core) server. What
do I need to do if anything in order to spread the workload across the cpu's
/ cores in order to tune it properly?

As other has stated: you do not need to do anything. .NET and Windows
will utilize all the CPU's and cores.

But a small extra note: if your code is not as thread safe as it should
be, then moving from a 1 core environment to a 4 core environment can
bring out the problems. So be sure to test in a multi core environment !

I speak from experience ... :-(

Arne