ThreadPool and Dual Core Opteron.

[Guest]

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]]

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,
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.

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

 

[Guest]

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.

 

[Tom Widmer [VC++ MVP]]

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

 

[Guest]

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.