Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / Managed C++ / September 2006

Tip: Looking for answers? Try searching our database.

ThreadPool and Dual Core Opteron.

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
LLessieux - 17 Aug 2006 06:00 GMT
Hi,

I have been seeing a strange behaviour when doing some tests on a Dual -
Dual Core Opteron system using Windows XP (32bits with SP2).

In out application we have a wrapper around the thread pool to handle the
work on renderers and CPU intensive tasks. On the Dual - Dual Core Opteron,
the application is correctly starting 4 threads but it seems to be running
only 2 concurrently.

In fact, It's when checking the performance  that i realized something was
strange. My AthlonX2 4800 was as fast as my Dual Opteron 285...

Also we are using SetThreadIdealProcessor with the thread index (0 to 4 in
that case)  but that does not seem to have an effect at all. Even commenting
it didnt change a thing.

Any idea ?

Laurent.
Tom Widmer [VC++ MVP] - 21 Aug 2006 14:43 GMT
> Hi,
>
> I have been seeing a strange behaviour when doing some tests on a Dual -
> Dual Core Opteron system using Windows XP (32bits with SP2).

Is it XP Pro? XP Home only supports 1 CPU. In addition, I think you need
to have the CPUs installed at the time that XP Pro is installed,
otherwise read this: http://support.microsoft.com/kb/309283/

> In out application we have a wrapper around the thread pool to handle the
> work on renderers and CPU intensive tasks. On the Dual - Dual Core Opteron,
[quoted text clipped - 7 lines]
> that case)  but that does not seem to have an effect at all. Even commenting
> it didnt change a thing.

In general, you should probably leave scheduling to the scheduler,
unless you can measure a significant performance increase from handling
it yourself.

> Any idea ?

You should check that all 4 CPUs can work concurrently with a simple
test program. Otherwise, it's probably a problem with your Windows
installation.

Tom
LLessieux - 21 Aug 2006 15:00 GMT
It's a XP Pro indeed sorry that was so obvious that i forgot to mention it,
and i am pretty sure the 2 cpus where plugged when  the installation took
place.

I have seen the 4 CPU working so it doesnt seem to be the issue.
But now i wonder if the ThreadIdealProcessor deals with the cores as it
would with physical processors, I'll check that too. But i think it didnt
change anything when i disabled it.

With the amount of memory we tend to touch, it's much better if we don't
swap the thread accross processors to avoid trashing the other caches etc...

I'll modify one of our unittest to check that indeed the 4 threads can run
at the same time.

Laurent.

> > Hi,
> >
[quoted text clipped - 28 lines]
>
> Tom
Tom Widmer [VC++ MVP] - 21 Aug 2006 17:17 GMT
> It's a XP Pro indeed sorry that was so obvious that i forgot to mention it,
> and i am pretty sure the 2 cpus where plugged when  the installation took
> place.
>
> I have seen the 4 CPU working so it doesnt seem to be the issue.

You could check the HAL as per http://support.microsoft.com/kb/309283/ 
to be absolutely sure.

> But now i wonder if the ThreadIdealProcessor deals with the cores as it
> would with physical processors, I'll check that too. But i think it didnt
> change anything when i disabled it.
>
> With the amount of memory we tend to touch, it's much better if we don't
> swap the thread accross processors to avoid trashing the other caches etc...

Well, once you've got the 4 cpus working (if you ever do!), I'd try it
with and without to make sure you aren't accidentally slowing the code down.

> I'll modify one of our unittest to check that indeed the 4 threads can run
> at the same time.

Silly question, but I assume that 2 of the threads aren't blocked are
they? Are you sure you're seeing 4 threads with a ready status but only
2 actually running? Do you have any other threads? Does anything change
if you increase the priority of your 4 pool threads?

Tom
SmokedTrout - 26 Sep 2006 23:54 GMT
I am seeing something very similar. Although with VS2003 and XP32 all is
fine, the same code compiled with VS 2005 and ran in 64 bit XP or 64bit W2k3
Server will exhibit this behavior.
For example, I run two instances of Einstein@home and they have both cpu's
pegged, each process shows 50% utilization.
When I run my app which creates one thread per cpu, and they're very
computationally instense, my app is only showing 50% processor usage and one
of the EInstein@home instances remains at 50%. This behavior is not exhibited
with compile of same code with VS2003 and run under XP Pro 32 bit, he same
code shows my app using 99% and both EInstein instances at 0%. Note that the
Einstein instances are running at a lower priority. I've tried changing
thread priority but there's no difference in behavior.

Would setting thread affinity possibly remedy this? It seems the OS is not
scheduling correctly.
Signature

Still writing code...

> Hi,
>
[quoted text clipped - 16 lines]
>
> Laurent.

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.