Re: Why only 50% CPU usage?
"Jive Dadson" <firstname.lastname@example.org> wrote in message
> I am running Windows XP Pro, with all the latest updates.. My processor
> is a Pentium D (dual core) 2.8GHz with 1G RAM. I have an application
> that does pure computation, with no IO at all for long periods. It does
> not use much memory either for program or data. I can tell it does not
> hit the pagefile cache, because the hard disk stays completely inactive.
> When nothing else is happening, the task manager performance meter
> shows that the process is getting only 50% of the CPU time, with the
> other half going to the system idle process. If I invoke some other
> program or activity, it zooms up to 100% until the other activity
> settles down. Then back to 50%. Why is that, and is there anything I
> can do about it? The program can grind away for hours. It would sure
> be nice to be able to use my CPU at peak capacity.[/color]
XP allots all processing for your task to a single core. If your program
doesn't use threads, it's zero probability the other half of your CPU kicks
in. (And I'm not entirely sure about multithreading, either--but, you're
stuck with your app anyway.)
Re: Why only 50% CPU usage?
"Jive Dadson" <email@example.com> wrote
> I have an application that does pure computation, with no IO at all for
> long periods. ... When nothing else is happening, the task manager
> performance meter shows that the process is getting only 50% of the CPU
> time, with the other half going to the system idle process. If I invoke
> some other program or activity, it zooms up to 100% until the other
> activity settles down. Then back to 50%.[/color]
This is exactly what I'd expect. If the program is written
without using explicit threading, Open MP, or any other system for using
multiple processors within a single program ... it doesn't. Your system is
reporting 50% CPU usage, because with one CPU running flat-out and
one CPU idle, that's what's happening: half of the total available CPU
cycles are not being used.
You may have gained the impression that a dual-core processor would
execute programs twice as fast, irrespective of how they were written.
If so, you have just had the power of marketing demonstrated to you.
Intel marketing wish, very much, that a dual-core machine would run
twice as fast. Under specialised circumstances, that can even be true.
But in general, it isn't, not even slightly.
The easy way to have a dual-core run twice as fast is to have two
programs, both capable of consuming an entire processor. On a single-
core machine, they would have to share, and you would get about half
the power of a single CPU going to each program. On a dual-core
machine, each program gets to use an entire processor, and thus
run about twice as fast. However, this isn't a very common situation for
The hard way is to have a program that uses threads in some way
appropriate to whatever it actually does. It's hard because the
programmer has to either design this in from the beginning, or, for
extra difficulty, add it in afterwards. Designing multi-threaded
programs is harder than ordinary programs. Debugging them can
be very much harder than for ordinary programs.
The reason Intel (and other manufacturers) are selling you multi-
core processors is that this is what they can build. For complex
physics and electronics reasons, it's quite hard, at present, to make
single processors go faster than the current ones. Putting two
copies of the same processor onto a single chip is comparatively
easy. So they're doing that, and because marketing departments
always want to be positive, they are trying to sound as if it's the
best idea ever. But it isn't. They are aided in this by the inability
of most marketing people to understand the technical issues of
multi-threaded programming. There's also a really easy mistake
to make, which is to assume that the things that people who do
supercomputing want to make fast are the same as the things that
other kinds of software need. This is almost completely false.
Now, for web servers, which deal with lots of requests from many
different computers, multi-core processors are really good. It's
easy to have each request handled by a single thread, and having
lots of cores to handle lots of threads works well. The useful this
is that the requests are independent of each other, so there isn't
much need to coordinate between the threads, which is the hard
part of programming them. But that's web servers, not desktop