Simulating high cpu usage on multi-core pc
Angus
I am creating a test program which basically is just a busy loop to
simulate high cpu usage. My PC is multi-core - 2 processors and the
max cpu usage I get is 50%. I assume Windows is deciding to run busy
loop on just one processor. It is a MFC Windows app.
Is there a way I can run a busy loop on both processors? How would I
go about that?
Angus
Sebastian G.
Multithreaded code?
Kellie Fitton
Hi,
Well... it is possible to declare multiple threads on a dual
processor system and explicitly decide on which CPU each
thread will be executed, you can accomplish this by using
the following APIs:
GetProcessAffinityMask()
SetThreadAffinityMask()
SetThreadIdealProcessor()
http://msdn2.microsoft.com/en-us/library/ms683213.aspx
http://msdn2.microsoft.com/en-us/library/ms686247.aspx
http://msdn2.microsoft.com/en-us/library/ms686253.aspx
Kellie.
Nathan Mates
Any reason you can't just run your test app twice? Or write a
dead-simple app (even a console app) that chews up CPU and run that
twice?
Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Sebastian G.
> On Apr 30, 2:49 am, Angus <anguscom...@gmail.com> wrote:
>> Hello
>>
>> I am creating a test program which basically is just a busy loop to
>> simulate high cpu usage. My PC is multi-core - 2 processors and the
>> max cpu usage I get is 50%. I assume Windows is deciding to run busy
>> loop on just one processor. It is a MFC Windows app.
>>
>> Is there a way I can run a busy loop on both processors? How would I
>> go about that?
>>
>> Angus
>
>
> Hi,
>
> Well... it is possible to declare multiple threads on a dual
> processor system and explicitly decide on which CPU each
> thread will be executed,
Windows would most likely schedule them on different CPUs anyway, *if he
actually had more than one thread*.
Sten Westerback (MVP SDK 2005-6 :)
"Nathan Mates" <nat...@visi.com> wrote in message
news:NY2dnfj1ivl1PoXVnZ2dnUVZ_qCunZ2d@visi...
> In article
> <ea126710-87a9-4227...@l28g2000prd.googlegroups.com>,
> Angus <angus...@gmail.com> wrote:
>>I am creating a test program which basically is just a busy loop to
>>simulate high cpu usage. My PC is multi-core - 2 processors and the
>>max cpu usage I get is 50%. I assume Windows is deciding to run busy
>>loop on just one processor. It is a MFC Windows app.
>
>>Is there a way I can run a busy loop on both processors? How would I
>>go about that?
>
> Any reason you can't just run your test app twice? Or write a
> dead-simple app (even a console app) that chews up CPU and run that
> twice?
Why two processes when one with two threads, assigned to processors using
SetThreadAffinityMask), is enough.
But i didn't get the point of loading CPU's with busylooping. Without any
kind of delay in the loops they will take 100% of the combined CPU power and
make system fairly much unresponsive.
- Sten
Sebastian G.
> Why two processes when one with two threads, assigned to processors using
> SetThreadAffinityMask), is enough.
Because he doesn't even have two threads, and running the app twice is
easier than making it multithreaded.
> But i didn't get the point of loading CPU's with busylooping. Without any
> kind of delay in the loops they will take 100% of the combined CPU power and
> make system fairly much unresponsive.
Surely won't, since responsiveness is decided by priority.
Nathan Mates
Sten Westerback \(MVP SDK 2005-6 :\) <REMOVE_UPPERCASEe...@nokia.comX> wrote:
>But i didn't get the point of loading CPU's with
>busylooping. Without any kind of delay in the loops they will take
>100% of the combined CPU power and make system fairly much
>unresponsive.
If I remember the original poster correctly, his app had some bugs
or behavior that only showed up when the CPU's really busy. To me,
that sounds like a poorly coded multithreaded app. Threading gives you
many subtle ways to shoot yourself in the foot unless you've got a
good understanding of what's really going on.
ege...@gmail.com
> I am creating a test program which basically is just a busy loop to
> simulate high cpu usage. My PC is multi-core - 2 processors and the
> max cpu usage I get is 50%. I assume Windows is deciding to run busy
> loop on just one processor. It is a MFC Windows app.
I've kind of the same problem: I've created a program with the same
number of worker-threads as the number of cores (4). I'm able to move
the threads around using SetThreadAffinityMask, but the combined
process-CPU-usage don't exceed 25%!
I believe I should be able to utilize more processing power by
creating multiple threads, which is intuitively not the case!
Could it be a restriction in the scheduler?
- egeskov
Sebastian G.
> On Apr 30, 11:49 am, Angus <anguscom...@gmail.com> wrote:
>
>> I am creating a test program which basically is just a busy loop to
>> simulate high cpu usage. My PC is multi-core - 2 processors and the
>> max cpu usage I get is 50%. I assume Windows is deciding to run busy
>> loop on just one processor. It is a MFC Windows app.
>
> I've kind of the same problem: I've created a program with the same
> number of worker-threads as the number of cores (4). I'm able to move
> the threads around using SetThreadAffinityMask, but the combined
> process-CPU-usage don't exceed 25%!
Maybe thread stalling due to synchronization?
> I believe I should be able to utilize more processing power by
> creating multiple threads, which is intuitively not the case!
> Could it be a restriction in the scheduler?
Depends on what your program does. If you repeatedly call
SetThreadPriority(), you shouldn't wonder that the machine will spend most
time in kernel code in locking/unlocking the thread context blocks.
Nathan Mates
<ege...@gmail.com> wrote:
>I've kind of the same problem: I've created a program with the same
>number of worker-threads as the number of cores (4). I'm able to move
>the threads around using SetThreadAffinityMask, but the combined
>process-CPU-usage don't exceed 25%!
>I believe I should be able to utilize more processing power by
>creating multiple threads, which is intuitively not the case!
>Could it be a restriction in the scheduler?
This has come up before. There's several good reasons why this may
not be working as expected. (1) You may be I/O bound -- your threads
are starved waiting for disk/network data to be received. Throwing
more threads at a problem won't make your poor HD pull in data any
faster. (2) You may be running into Amdahl's law (see
http://en.wikipedia.org/wiki/Amdahl's_law ), where your threads are
all waiting on communication.
Not every program can be easily parallelized. The *less* your
threads have to communicate, and *less* I/O your threads need, the
better. Of course, in the real world, your problems probably don't
fit that model.
Jerry Coffin
@y21g2000hsf.googlegroups.com>, ege...@gmail.com says...
It sounds like you're setting them to all use the same processor (core).
To distribute the load across a number of processor( core)s, you'll need
to set the affinity mask differently for each thread. Alternatively, if
you don't set an affinity mask at all, but create at least as many
threads as there are processors available, the threads will be
distributed across the cores, though they may switch between cores as
thread switches happen.
--
Later,
Jerry.
The universe is a figment of its own imagination.
ege...@gmail.com
fitteling around with the worker-thread a noticed a synchronization
issue in Delphi's IntToStr function.
My test program was doing a lot of converting from integer to string
which for some unknown reason caused the threads to synchronize!
I tried using the thread-safe format function instead but it didn't
change anything.
Thanks for your responses.
Michael Wojcik
> I've stopped assigning affinity, so this is not the reason. But I was
> fitteling around with the worker-thread a noticed a synchronization
> issue in Delphi's IntToStr function.
>
> My test program was doing a lot of converting from integer to string
> which for some unknown reason caused the threads to synchronize!
I've never used Delphi, but a quick look at some online docs shows
that IntToStr is a function that takes an integer and returns a string.
Where does that string come from? You, the caller, didn't supply it,
so it's either a static buffer maintained by IntToStr or dynamically
allocated.
If it's dynamically allocated, you're hitting synchronization in the
allocator. Even if it's static (in which case its value could change
unpredictable in a multithreaded program, so using it is a bad idea),
strings in Delphi are apparently reference-counted, which introduces a
small synchronization window; and IntToStr may have additional
serialization to prevent simultaneous updates to the string.
> I tried using the thread-safe format function instead but it didn't
> change anything.
You don't say what the "thread-safe format function" is called, so I
can't look at its documentation, but it probably has the same issue.
Unless you're supplying the string, someone's got to allocate it.
Heaps are usually shared resources, so allocating objects usually
means access to a shared resource, which means synchronization. If you
want parallelism, you need to leave shared resources alone during the
parallel phase of your processing.
--
Michael Wojcik
Micro Focus
ege...@gmail.com
> I've never used Delphi, but a quick look at some online docs shows
> that IntToStr is a function that takes an integer and returns a string.
>
> Where does that string come from? You, the caller, didn't supply it,
> so it's either a static buffer maintained by IntToStr or dynamically
> allocated.
>
> If it's dynamically allocated, you're hitting synchronization in the
> allocator. Even if it's static (in which case its value could change
> unpredictable in a multithreaded program, so using it is a bad idea),
> strings in Delphi are apparently reference-counted, which introduces a
> small synchronization window; and IntToStr may have additional
> serialization to prevent simultaneous updates to the string.
Memory management was exactly the problem ;)
I rewrote the loop to use a single null-terminated string for all
calls to the conversion function. And pass a pointer to this string
instead of making the conversion function allocate a string each time.
This speeds up the process to 100% CPU utilization - great!)
Thanks for the input;)