Re: Best way to deal with long loops?
From: Maarten Wiltink (maarten_at_kittensandcats.net)
Date: 01/10/05
- Next message: Marc Rohloff [TeamB]: "Re: Hiding virtual methods"
- Previous message: J French: "Re: Best way to deal with long loops?"
- In reply to: Raptor: "Re: Best way to deal with long loops?"
- Next in thread: Raptor: "Re: Best way to deal with long loops?"
- Reply: Raptor: "Re: Best way to deal with long loops?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 10 Jan 2005 15:00:42 +0100
"Raptor" <bogus@none.com> wrote in message
news:crtlmi015d8@news2.newsguy.com...
> J French <erewhon@nowhere.uk> wrote in message
> news:41e23069.669097@news.btclick.com...
>> On Sun, 9 Jan 2005 14:16:24 +0100, "Maarten Wiltink"
>> <maarten@kittensandcats.net> wrote:
>>> Measuring system speed is dangerous. People, smart people, have been
>>> bitten by a delay loop no longer taking any measurable time as CPUs
>>> grew too fast. But you can't make the delay loop too long; it must
>>> work on that 100 MHz processor, too. You don't want to have it take
>>> ten seconds extra to start up there just because on next week's 20
>>> GHz CPU it must not fall between clockticks.
>
> Rats. Some of these posts are not showing up on my server.
> I would have missed yours, Maarten, had JF not responded.
>
> OK. Smart people have been bitten, so I'll use caution. Now,
> what's a cautious way to do it?
Actually, there isn't even all that much caution involved... with
the benefit of hindsight. What went wrong in most cases was that they
timed a loop over a fixed number of iterations, then blindly took the
reciprocal of the elapsed time to go from "delay" to "speed". One day,
processors caught up with the resolution of the timer used, and speed
became infinite, or would have if we could divide by zero.
The best way would probably be to count the number of iterations
required to fill ten milliseconds or so, instead of measuring how
long a thousand iterations take. In either case, you should check
for the possible zero and do an exponential backoff or something.
[...]
> But surely there has to be a simple and reasonably reliable
> way to determine how to issue an Update or ProcessMessages
> about every (say) 100 milliseconds or so--and not have it
> happen every millisecond or every second instead?
It's very easy to get your layers mixed up. These are _primitives_.
You can't have them depend on a layer of Windows (message processing)
that it wants to control.
Calibrating at startup is fairly simple and reliable if you avoid the
pitfalls; they're mostly well known.
> Even +/- 50% tolerance would probably not be noticed. How
> hard can that be, he asked, his head blissfully tucked in a
> dark, anatomically difficult position?
Smelly, too. Depending on your starting point, 5000% might not
be noticed. An update every 200 ms should be enough; if you tune
your program so that it updates every 200 ms on that mythical
486DX4-100, it will be perceived as slow and choppy - which it is.
The processor, I mean. That's not the same as unworkable; it would
probably be perceived as about right.
On a Celeron-500, it might get about 50 Hz instead of 5, and on a
current Pentium IV-3000 it might reach 500 Hz. That means the 500 MHz
CPU will already be smooth, but when you do it right I doubt all the
updating would cost an appreciable amount of time.
Very roughly, that means you can stand about ten million clockticks
between GUI updates. Say a thousand iterations of a not too small loop.
Just don't go to disk.
Groetjes,
Maarten Wiltink
- Next message: Marc Rohloff [TeamB]: "Re: Hiding virtual methods"
- Previous message: J French: "Re: Best way to deal with long loops?"
- In reply to: Raptor: "Re: Best way to deal with long loops?"
- Next in thread: Raptor: "Re: Best way to deal with long loops?"
- Reply: Raptor: "Re: Best way to deal with long loops?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
