«

I have a compute-intensive program with a simple console user interface.
While the program is running (number crunching), WinXP's Task Manager's CPU
usage for it never goes above 50%. I'd like to use the other half of my CPU
I've tried, via a separate SetPriority utility, setting the java (JVM)
process priority to 256 (max; real time) and all of its threads' priorities
to 15 (max). This causes the JVM's Base Prio entry in Task Manager to
become Real Time -- but CPU usage remains at 50%.

The code that is running does no I/O, only calculation.

--
For mail, please use my surname where indicated:
(Steve Brecher)

Steve Brecher wrote on 14.11.2006 00:47:
> I have a compute-intensive program with a simple console user interface.
> While the program is running (number crunching), WinXP's Task Manager's CPU
> usage for it never goes above 50%. I'd like to use the other half of my CPU
> I've tried, via a separate SetPriority utility, setting the java (JVM)
> process priority to 256 (max; real time) and all of its threads' priorities
> to 15 (max). This causes the JVM's Base Prio entry in Task Manager to
> become Real Time -- but CPU usage remains at 50%.
>
> The code that is running does no I/O, only calculation.
>
Do you happen to have a dual processor/dual core computer? If so, then I suspect
your calculation is running in a single thread only which will not make use of
the second processor, and thus your overal CPU load will not exceed 50%

Thomas

Steve Brecher wrote:
> I have a compute-intensive program with a simple console user interface.
> While the program is running (number crunching), WinXP's Task Manager's CPU
> usage for it never goes above 50%. I'd like to use the other half of my CPU
> I've tried, via a separate SetPriority utility, setting the java (JVM)
> process priority to 256 (max; real time) and all of its threads' priorities
> to 15 (max). This causes the JVM's Base Prio entry in Task Manager to
> become Real Time -- but CPU usage remains at 50%.
>
> The code that is running does no I/O, only calculation.
>

Is there any possibility that you have a dual processor, possibly two
cores in one chip?

Utilization freezing at close to 50%, even at very high priority, for a
compute intensive job is typical of running a single threaded
application on a dual processor.

If that is what is going on, you should be able to run two copies of the
job (if it does not use too much memory) at the same time almost as fast
as one copy. If so, look at parallelizing the compute-bound portion of
the job.

What dominates the computation? Some algorithms are easier to
parallelize than others.

Patricia

Thomas Kellerer <> wrote:
> Steve Brecher wrote on 14.11.2006 00:47:
>> I have a compute-intensive program with a simple console user
>> interface. While the program is running (number crunching), WinXP's
>> Task Manager's CPU usage for it never goes above 50%. ...
>>
> Do you happen to have a dual processor/dual core computer? If so,
> then I suspect your calculation is running in a single thread only
> which will not make use of the second processor, and thus your overal
> CPU load will not exceed 50%

(Thanks also to Patricia, who responded similarly.)

It's a Pentium 4 (3.4G) vintage early 2004. If it's dual, I never knew it!
Might it be?

The calculation is definitely single-thread.

--
For mail, please use my surname where indicated:
(Steve Brecher)

"Steve Brecher" <see.signature@end> wrote in message
news:...
>I have a compute-intensive program with a simple console user interface.
>While the program is running (number crunching), WinXP's Task Manager's CPU
>usage for it never goes above 50%. I'd like to use the other half of my
>CPU I've tried, via a separate SetPriority utility, setting the java
>(JVM) process priority to 256 (max; real time) and all of its threads'
>priorities to 15 (max). This causes the JVM's Base Prio entry in Task
>Manager to become Real Time -- but CPU usage remains at 50%.
>
> The code that is running does no I/O, only calculation.

Do you by chance have a dual core system?

--
LTP

Steve Brecher wrote:
> Thomas Kellerer <> wrote:
>> Steve Brecher wrote on 14.11.2006 00:47:
>>> I have a compute-intensive program with a simple console user
>>> interface. While the program is running (number crunching), WinXP's
>>> Task Manager's CPU usage for it never goes above 50%. ...
>>>
>> Do you happen to have a dual processor/dual core computer? If so,
>> then I suspect your calculation is running in a single thread only
>> which will not make use of the second processor, and thus your overal
>> CPU load will not exceed 50%
>
> (Thanks also to Patricia, who responded similarly.)
>
> It's a Pentium 4 (3.4G) vintage early 2004. If it's dual, I never knew it!
> Might it be?
>
> The calculation is definitely single-thread.

No it is single core.

BUT it has hyperthreading.

Which in WinXP task manager looks like 2 CPU's !

And to utilize HT you still need to multithread.

Arne

"Patricia Shanahan" <> wrote in message
news:YT76h.5963$ ink.net...
> Steve Brecher wrote:
>> I have a compute-intensive program with a simple console user interface.
>> While the program is running (number crunching), WinXP's Task Manager's
>> CPU usage for it never goes above 50%. I'd like to use the other half of
>> my CPU I've tried, via a separate SetPriority utility, setting the
>> java (JVM) process priority to 256 (max; real time) and all of its
>> threads' priorities to 15 (max). This causes the JVM's Base Prio entry
>> in Task Manager to become Real Time -- but CPU usage remains at 50%.
>>
>> The code that is running does no I/O, only calculation.
>>
>
> Is there any possibility that you have a dual processor, possibly two
> cores in one chip?
>
> Utilization freezing at close to 50%, even at very high priority, for a
> compute intensive job is typical of running a single threaded
> application on a dual processor.
>
> If that is what is going on, you should be able to run two copies of the
> job (if it does not use too much memory) at the same time almost as fast
> as one copy. If so, look at parallelizing the compute-bound portion of
> the job.
>
> What dominates the computation? Some algorithms are easier to
> parallelize than others.

Utilizing multiple processors/cores to do tasks which seem to be iterative
(I'm sure there is probably a more formal/correct way to say this) is a very
active and fun area of computer science right now!

--
LTP

Patricia Shanahan <> wrote:
> Is there any possibility that you have a dual processor, possibly two
> cores in one chip?

It seems I do, virtually speaking -- Pentium 4, apparently with
Hyper-Threading Technology (thanks to Arne Vajhøj in
<45591a39$0$49200$>).

> Utilization freezing at close to 50%, even at very high priority, for
> a compute intensive job is typical of running a single threaded
> application on a dual processor.
>
> If that is what is going on, you should be able to run two copies of
> the job (if it does not use too much memory) at the same time almost
> as fast as one copy. If so, look at parallelizing the compute-bound
> portion of the job.
>
> What dominates the computation? Some algorithms are easier to
> parallelize than others.

It's nested loops enumerating cases; there's a computation for each case,
i.e., inside the innermost loop, and the computation results are
accumulated.

It should be possible to dual-thread it, e.g., one thread doing the odd
cases, so to speak, and the other the even ones. I could synchronize access
to the accumulation structures, or perhaps have two of them. For generality
maybe I can even N-thread it. I'll have to think about this...

--
For mail, please use my surname where indicated:
(Steve Brecher)

Steve Brecher wrote:
....
> It's nested loops enumerating cases; there's a computation for each case,
> i.e., inside the innermost loop, and the computation results are
> accumulated.
>
> It should be possible to dual-thread it, e.g., one thread doing the odd
> cases, so to speak, and the other the even ones. I could synchronize access
> to the accumulation structures, or perhaps have two of them. For generality
> maybe I can even N-thread it. I'll have to think about this...
>

Given trends in computer architecture, I suggest N-threading it while
you are about it. When you go to replace that computer, you may find
yourself getting something with multiple cores, each multi-threaded.

For reduction problems (problems that take a long vector and produce a
single answer, such as adding things up), it is generally better, if
permitted by the problem, to have an accumulator for each thread, and
only add them at the end. The less synchronization in the middle of the
problem, the faster it will go.

Consider organizing the work so that each thread operates on a
contiguous chunk of data, in case they get assigned to separate
processors with their own caches.

However, I would go for simplicity, within the at-least-dual requirement.

Patrica

Arne Vajhøj wrote:

> No it is single core.
>
> BUT it has hyperthreading.
>
> Which in WinXP task manager looks like 2 CPU's !
>
> And to utilize HT you still need to multithread.

But don't assume that making the application use the other "cpu" will
necessarily speed anything up. HT is (for most purposes) better regarded as a
cheap marketing gimmick than a valid technology.

Or -- to put it another way -- the CPU usage reported by TaskManager is
misleading. It suggests that 50% of your available horse-power is
unused. My bet would be that it's more like 5% -- if not actually zero.

-- chris