How to get more than 50% CPU usage 1

[pclancey]

I have two XP pro computers that I'm trying to run my image analysis software on. One's a P4 2.8 GHz with 512 Meg, the other's a Celeron 2.4 GHz with 256 Meg. I was suprised to see the Celeron was running my app (which is numerically intensive) more than twice as fast. The task manager shows that it runs on the Celeron with approx 95% CPU usage, on the P4 about 50% CPU usage. On both computers, the system idle task gets the rest of the CPU time. Both are running the app at "Normal" priority. The Celeron is SP1, the P4 SP2.

What setting would cause XP to limit my app on the P4 to 50% of the CPU time?

 

[LloydSev]

Hyper Threading

Computer/Network Technician
CCNA

 

[LloydSev]

BTW, that isn't a setting.. that's a "feature" of the P4. It basically divides the processor clock and memory in half to run two seperate programs at once.

Computer/Network Technician
CCNA

 

[bcastner]

Watch out for:

http://support.microsoft.com/?kbid=330512

 

[pclancey]

Thanks, LloydSev, but it's hard to believe I can't change that behavior somehow. How can all single applications be restricted to receiving half the processor time? It's as if I have a 1.4 GHz P4 instead of a 2.8.

This would change my question from, "what XP setting can I change", to "is there a compile option that I can set to tell XP to give full attention to my executable". I did verify that changing the priority of my executable from "Normal" to "High" had no effect, it still only got 50% CPU. From a programming standpoint, I suppose I could create two executables, each simultaneously analyzing even and odd frame numbers so that each could run at 50% CPU usage, but that's a lot of work to get around what shouldn't be a problem...

 

[bcastner]

Bring up Task Manager and right click on the application, set priority.

 

[LloydSev]

That's what the P4 is all about though.. hyperthreading. There is no compile option to change the behavior that is programmed into the processor.

HT is actually one of the many efficiencies that Intel engineers invented as a way to combat the perennial problem of latency - the fact that single-core processors can spend more than half their clock cycles executing nothing at all. In the mid-1990s, Intel discovered that traditional single-threaded programs were utilizing only about 35% of a processor's available resources. They realized that, with an added level of hardware sophistication, the processor could schedule at least one more thread of execution within the unused space. It could only achieve this, however, if each thread "believed" it had the entire processor to itself - including its registers, cache, and access to the front-side bus. So HT schedules the execution of two threads (for now) in alternating fashion - a few cycles for thread #1, a few for thread #2 - but only when the results of one thread do not corrupt the image of the CPU for the other. In other words, HT only alternates instructions that cannot get in each other's way.

The immediate benefit of HT parallelism is that it doesn't require the software - the programs that constitute each thread - to be aware of any parallelism taking place whatsoever. Each thread, not "knowing" it runs in a split environment, "believes" to have the processor all to itself. As a result, software originally compiled to run on standard single-core processors such as Pentium 4 and Xeon series, need not be recompiled in order to implement parallelism, and to realize at least some boost in performance without raising clock speed.

But while a hardware-based solution such as HT may be economical, remarks Dr. Palem, in practice, its performance gains can prove variable. Not all optimally compiled threads are suitable for subdivision. "It may be very easy to put a hundred 'adders' [on a CPU]," says Dr. Palem, "but it may be very hard to find 100 'ADD' instructions to give those hundred adders on the fly."

Insight 64 principal analyst Nathan Brookwood agrees. "I think hyperthreading was inherently somewhat limited in terms of performance benefits," he tells Tom's Hardware Guide. The reason, he states, is that while an HT thread "sees" that it has all the CPU's resources to itself, the CPU hasn't really replicated its resources for both threads. For example, since the L1 cache is so frequently polled by the processor, HT divides the cache in half and apportions each thread its own half. An apparently smaller cache provides a thread with a narrower view of memory, thus forcing it to refresh its contents far more often. "Therefore, dual-core comes a lot closer to providing 100% performance benefits," concludes Brookwood, "whereas hyperthreading typically [provides] 15-20% performance benefits."

http://www.tomshardware.com/business/20050330/index.html

Computer/Network Technician
CCNA

 

[bcastner]

There are a lot of P4s without HT.

 

[LloydSev]

Yes I know this. But there are a lot with it as well. I only throw this out, because his problem seems to me like a HT issue. Of course I'm open to being shown otherwise, just throwing what I know out there.

Computer/Network Technician
CCNA

 

[DragonQ0105]

Is there anything in the BIOS about it?

 

[LloydSev]

about hyperthreading? No. It's either enabled in the CPU, or it isn't. Even the P4 processors without HT come with it, it was just never enabled.

Computer/Network Technician
CCNA

 

[pclancey]

I found a BIOS setting for Hyperthreading and turned it off. It did seem to affect CPU usage, in that it climbed to around 70%. The overall application speed was unchanged, however, and the slower Celeron remains more than twice as fast. I did find the following on the PC World webiste, a little more insight into things. I did not bother to reinstall XP.

http://www.pcworld.com/news/article/0,aid,107492,pg,2,00.asp

I understand the intent for HP now, but it still baffles me that the "System Idle Task" gets run as the second thread, as if anyone would choose that behavior for a single threaded application.

 

[bcastner]

System idle is an important task for XP. See my notes here: faq779-4518