Suppose you have Word2000 which happily ran on a PentiumII/AMD socket
7 system and you now put it on a high powered system with exactly the
same operating system and software installed. The power dissipation is
higher and all because the software is being run faster when it
doesn't need to be. Whereas in the past it might check for a user
response from the mouse or keyboard y times a second, now it's x*y
where x is how much much faster the system is. It's ridiculous, isn't
it?

Is this problem being confronted now, so that software has a speed
rating for all its modues that define how fast they are needed to run?

Modules requiring user input via the mouse or keyboard might have a
rating of 20 cycles per second, whereas the module that spools a file
for a printer could be done as fast as possible since it is done only
once and doesn't recycle. This way, as systems become faster, they
become more efficient by going into sleep or idle mode when a module
doesn't require servicing yet.

Interested in your views

blackhead ha scritto:
You seem to imply that the application is doing an active polling on the
input device to get the next event.

I don't think this is the case for any Windows program (or Linux for
that matter).

Last time I saw something as you describe is when AT replaced XT. The
"Turbo" button on the case was there to lower the clock frequency and
allow you to play DOS games that would have been far too fast for you

R.D.

"blackhead" <larryharson@softhome.net> wrote in message

Here's a loop for my current program

// Main message loop:
while (GetMessage(&msg, NULL, 0, 0))
{
// if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
// {
TranslateMessage(&msg);
DispatchMessage(&msg);
// }
}

(Translate accelerator has been cmmented out during development)

You see that bacially it is halting in GetMessage(). So whether the
processor is a might 3Ghz or a lowly 2 MHz, as long as it processes messages
fast enough it will run at the same speed, and it won't waste processor
time.

If you mean processors should reduce clockrate and thus energy consumption
when lightly loaded, yes I agree, but there are technicial reasons why that
is harder to do than seems at first sight.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

blackhead wrote:
If the purpose of the system is to run W2000, and it was
satisfactory, why did you replace it in the first place?

In general it would have made more sense to replace Windoze with
Linux. Ubuntu will almost usually mount immediately without
trouble. Replacements for most of the Microsoft monsters are
immediately available, and the result is almost totally virus
proof.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


--
Posted via a free Usenet account from http://www.teranews.com

On Feb 13, 11:06*am, blackhead <larryhar...@softhome.net> wrote:

Most Intel and AMD mobile CPUs can vary their speed and power
consumption - see SpeedStep and PowerNow!. AMD's version for desktops
is called Cool'n'Quiet, while Intel just calls it SpeedStep on the
desktop Core2's that support it.

The OS is responsible for watching the CPU load and adjusting the CPU
speed. That's not enabled by default in Windows when installed on a
desktop, but is enabled if you select the (for example) portable/
laptop power scheme.

In any event, most applications do not poll for user input. At least
well written ones do not, or you'd see them spike the CPU meter to
100% all the time. They are notified of a keystroke by the OS, and
then react accordingly. There *are* situations where CPU speed makes
a difference, for example, if you're dragging a window, you might see
more (finer) movements with a faster CPU, rather than fewer bigger
jumps.

On 13 Feb, 17:29, "Malcolm McLean" <regniz...@btinternet.com> wrote:
But the faster the processor, the faster GetMessage will be executed
when it doesn't need to be. I'm talking about each module in an
application defining for itself a maximum rate of service by the
processor. The message dispatch loop for user input would have the
lowest rate and while not being serviced, the processor would be
asleep or servicing another module, rather than continually polling
loops.

blackhead wrote:
) But the faster the processor, the faster GetMessage will be executed
) when it doesn't need to be.

GetMessage sleeps until an actual message has arrived.
So it's only executed when it *does* need to be.
That's the whole point.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

On Thu, 14 Feb 2008 15:14:07 -0600, blackhead wrote
(in article
<2be810ec-c28b-4129-b97c-08af170eaccc@i29g2000prf.googlegroups.com>):

Wouldn't it be a lot simpler if the CPU itself was clocked down based
upon system load (with some obvious dampening for spikes)? Oh wait,
that's already been done on a lot of systems.


--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

On 14 Feb, 21:50, Willem <wil...@stack.nl> wrote:
The GetMessage function may be 'asleep' while it waits for a message
to arrive, but the GetMessage() code is still being executed and
probably polled at an unnecessary rate.

On Feb 15, 8:31 am, blackhead <larryhar...@softhome.net> wrote:

No, it's not. If a thread is blocks (which include a thread waiting
in GetMessage()), it simply doesn't run, and the OS will run another
thread (one that's not blocked), or execute the idle thread or process
if there's truly nothing that needs to run. On many systems the idle
process executes a "halt" instruction, which many CPUs use to enter a
lower-power state. More power aware CPUs monitor ongoing CPU
utilization (basically watching the fraction of idle vs. elapsed
time), and then use things like SpeedStep to adjust the speed of the
CPU.

Just fire up task manager in Windows, and watch it show little or no
utilization for applications like Office, when they're not actually
doing anything but waiting for the user. Heck, fire up word, type a
letter, and before you shot it down, look in task manager to see the
total CPU time Word consumed for the task, and compare it with the
actual elapsed time.

Again, applications that poll for input or busy wait (without darn
good reason) are generally considered badly broken, and in practice
few "real" applications do so.

On 16 Feb, 05:00, "robertwess...@yahoo.com" <robertwess...@yahoo.com>
wrote:
So what unblocks GetMessage?

On Feb 18, 11:08*am, blackhead <larryhar...@softhome.net> wrote:

The entry of a message into the queue the GetMessage() is blocking on.

This can be another application sending a message of some sort (a drag-
and-drop notification, for example), the system notifying the
application that something has happened or needs to be done ("repaint
part of your window," "a file has been added to a directory"), or some
sort of hardware event ("the mouse moved," "timer fired," "network I/O
event"). Of course these all overlap in how they can be generated.
For example automation and training stuff often sends mouse and
keyboard messages to drive an existing application.

Of course there are all sorts of other ways an application can block
(waiting on I/O is pretty popular), but most GUI apps in Windows that
are waiting for keystrokes or mouse event end up waiting in
GetMessage() for those event. Note that character mode applications
don't use GetMessage(), and will either wait on the stdin stream, or
something like ReadConsoleInput() for keystrokes.