| Re: [AD] Add timeBeginPeriod(1) to wtimer.c |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: Re: [AD] Add timeBeginPeriod(1) to wtimer.c
- From: Chris <chris.kcat@xxxxxxxxxx>
- Date: Fri, 18 Feb 2005 10:07:11 -0800
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Kg2zKHATUnP86z/dbaVTUuAHnjSQlHu7UC0SkJvouoOAxEKKzAaEvYF7m2t8zzf/KCaqTFo4ufv0+zDyfKwrphseK+w1wPewP/6Ijxy4s6i2qc7VnnmRWZBkm+1tm84ZmRLllOCd4OSP/tH5rCQXJdfMf3IqOOHiy9jTvoHcBI4=
Tobias Scheuer wrote:
On my winXP athlon64 3000+ machine.
setting the timeBeginPeriod(1) once globally results in much better
performance. possibly due to better timing.
Hence why I said: Faster CPU's may not show as much speed defficiency
(and perhaps at some point, it'll become more efficient), but I don't
think current CPUs are ready for it, hence why the scheduler is still
10ms by default.
The CPU has to be fast enough, or else most of the time will be spent in
the kenrel doing context switches than running actual user code.
For the global setting it might be woth considering giving install_timer() a
new parameter of type int, specifying the timer resolution to use. That way
it yould be up to the programmer how üprecise things would be, and it would
be configurable, maybe dependant on the CPU speed. Or however.
Well, we can't change install_timer. Perhaps a set_timer_resolution
function, but there's a couple problems. For one, it's Windows-only.
AFAIK, no other OS gives such a function to user-space programs. In such
a case, it may be just as worth it to do
#ifdef ALLEGRO_WINDOWS
timeBeginPeriod(get_config_int(...));
#endif
yourself. But my other point, user-space programs shouldn't be able to
have such an effect on the system. Just imagine, a program sets
timeBeginPeriod(1), then either exits forgetting to reset it, or
crashes. The user's system will now be stuck with this alternate
scheduler timer, potentially causing their system to lag. You don't want
to do that.
I remember a similar problem I once had... everytime I ran Trillian on
my 233-then-400MHz Windows macghine, my system would seem fine, but
videos would play absolutely horrible (pretty CPU intensive on such a
system). Even if I exited Trillian, videos would never play right until
I reset the computer. I wouldn't doubt it did something like
timeBeginPeriod, and neglected to reset it when done.
It's one thing for a specific program to do it, but not an entire library.