Multiple Processors - or - Multi-Core Processor

  • Thread starter Thread starter Mythran
  • Start date Start date
M

Mythran

Just as a quick note before my question, I am not creating an application
for this, or library, or anything else. Just knowledge I'd like to obtain.

Now, question is, when developing a multi-threaded application (such as a
game) is there anything special that needs to be done to make use of the
multi-processors (or cores)?

That's it :)

Mythran
 
Mythran said:
Just as a quick note before my question, I am not creating an application
for this, or library, or anything else. Just knowledge I'd like to obtain.

Now, question is, when developing a multi-threaded application (such as a
game) is there anything special that needs to be done to make use of the
multi-processors (or cores)?

That's it :)
Click to expand...

Not really - you're just slightly more likely to see any threading bugs
if you've *actually* got it running on multiple cores.
 
In most instances, the multiple core/multi proc set up may actually help you
notice bugs in your code, which is a good thing (and what Jon stated, albeit
in a more roundabout way). Provided you are coding threads properly, it
should not matter.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

*************************************************
| Think outside the box!
|
*************************************************
 
Cowboy (Gregory A. Beamer) said:
In most instances, the multiple core/multi proc set up may actually help you
notice bugs in your code, which is a good thing (and what Jon stated, albeit
in a more roundabout way). Provided you are coding threads properly, it
should not matter.
Click to expand...

The other thing I didn't think of - it will give you a better idea of
whether your threading is actually having an effect or not. If you have
a multi-threaded version and a single-threaded version, but they run at
the same speed even on a 4-core box, then either you're doing something
wrong or your problem isn't very parallelisable :)
 
In addition, if you are not properly locking the shared resources, you will
more likely end up with a FUB when working on a multi-core, especially when
process #1 runs on the primary core that windows is running on and another
process runs on another core.

There are no guarantees of course, where the thread will fire, so testing of
threaded applications needs to be more than a couple of unit test hits. Of
course, that applies to all programming, so I am being redundant. :-)

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

*************************************************
| Think outside the box!
|
*************************************************
 
Great addition. My two cents.

In general, multi-threading is done for architectural reasons, not
performance. I know there are instances where you do it solely for
performance, but that can lead to serious problems if designed incorrectly.
Of course, bad multi-threaded design is dangerous, no matter how you slice
it. :-)

You generally do it, at least today, to run in parallel rather than serial
(or allow a user to continue working while a long running process runs on
another thread,k aka run in parallel). This is changing a bit now, but also
leading to some really bad applications.

Please note that I do not consider allowing a second process to run while a
long running process has its thread locked down a performance gain, although
that is one of its symptoms.

Performance is overrated. It is too often made the primary concern when it
should not be.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

*************************************************
| Think outside the box!
|
*************************************************
 
Cowboy (Gregory A. Beamer) said:
Great addition. My two cents.

In general, multi-threading is done for architectural reasons, not
performance. I know there are instances where you do it solely for
performance, but that can lead to serious problems if designed
incorrectly. Of course, bad multi-threaded design is dangerous, no matter
how you slice it. :-)

You generally do it, at least today, to run in parallel rather than serial
(or allow a user to continue working while a long running process runs on
another thread,k aka run in parallel). This is changing a bit now, but
also leading to some really bad applications.

Please note that I do not consider allowing a second process to run while
a long running process has its thread locked down a performance gain,
although that is one of its symptoms.

Performance is overrated. It is too often made the primary concern when it
should not be.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

*************************************************
| Think outside the box! |
*************************************************
Click to expand...

Thanks all who have responded thus far, the comments have been great...

One reason I would use multiple threads in an application is ANY time an app
I'm writing is downloading something off a slower than intranet speeds
(anything off the Internet or off an extranet). Also, anytime my
application would otherwise *hang* for even a brief period of time (ie:
looping or writing to disk), I would separate that logic into another thread
and then display a message stating what the thread is doing, or allow the
user to continue working, if appropriate. It all depends on the situation.

Now, is there anyway for the programmer to actually *take advantage* of a
multiple processor/core configuration and actually do some lower level
development to ensure the application runs specific parts on a dedicated
processor/core (all it's threads run in the same core/processor) while the
rest of the application (ie: GUI) runs on one of the others? I can see
using something like this for games or even advanced imaging/video/sound
software where processing power may be important to physics (imaging/video)
software, or dynamic realistic sound generation for 3-D environments (or
anything else NASA wants). Having a physics processor would help with that,
but if all I have is something like a QUAD-CORE processor, I'd like to run
some threads on a dedicated core that the O.S. would not use for other
things (lock it down temporarily for my own use)...

I could see some bad side effects of doing this (what if the machine has
only a single-processor with a single-core?). But all in all, can .Net, or
ANY OTHER programming framework do this?

Once again, this is all hypothetical for me. Just some questions and
thoughts that I've had regarding multiple-processors and, more accurately,
multiple-core processors.

Thanks,
Mythran
 
Peter Duniho said:
[...]
One reason I would use multiple threads in an application is ANY time an
app I'm writing is downloading something off a slower than intranet
speeds (anything off the Internet or off an extranet).
Click to expand...

Keeping in mind that in .NET, it's not necessary to explicitly use threads
to do this. All of the i/o classes have an asynchronous API that allows
for starting an i/o operation to be completed at a later time, without
blocking the current thread.

The underlying implementation does use threads, but in that case you don't
need to explicitly start any new threads yourself.
[...]
Now, is there anyway for the programmer to actually *take advantage* of
a multiple processor/core configuration and actually do some lower level
development to ensure the application runs specific parts on a dedicated
processor/core (all it's threads run in the same core/processor) while
the rest of the application (ie: GUI) runs on one of the others?
Click to expand...

You seem to be putting the cart before the horse.

To take advantage of multiple CPUs, all you need to do is make sure you've
got enough threads to keep all the CPUs busy. The OS will take care of
the rest.

It is in fact possible to assign a specific thread to a specific CPU, but
this is usually not actually what you want to do. The CPU will preserve
affinity as much as possible/necessary, but if you've explicitly set CPU
affinity for a thread, you could in fact wind up interfering with
performance. For example, for some other threads they actually require
affinity to work correctly, and if you dedicate your own thread to the
same CPU those threads have affinity to, your own thread could wind up
waiting on a CPU core when there's another core sitting idle.

Pete
Click to expand...

Ahh yeah, I understand where you are going with that. Theoretically, if I
was to write an application for a machine that would be dedicated for this
application only (and of course, the OS, drivers, etc for that system), it
would be optimal. But in reality, what your saying would still be true and
my application's dedicated thread for a core would end up waiting for an
"in-use" core until the core is free'd, even if another core was not in use.
I understand that.

Thanks,
Mythran
 
Back
Top