1. DOS time() [was Re: Rob: Bug with Windows trasking translator]
Vincent wrote:
<snip>
> Interesting...
>
> Any speed up with Windows programs? Perhaps also benchmark the DOS time()
> function
> to see if that speed-up any? You could also try a sieve test and see if that
> speed up a tiny bit on both DOS and Windows?
>
<snip>
I have found that using tick_rate()under DOS32 with any legal value other
than 0 increases the speed of time() by a factor of more than 100.
I think that it replaces the INT #08 (system timer) code with a different
function internally.
IIRC, it was necessary to call tick_rate() before trapping INT #08 (system
timer)
or my replacement ASM code wouldn't get executed.
Comments, Rob?
Bob
BTW, thanks for your effort on the include issue. I hope it all works.
2. Re: DOS time() [was Re: Rob: Bug with Windows trasking translator]
Bob Elia wrote:
> I have found that using tick_rate()under DOS32 with any legal value other
> than 0 increases the speed of time() by a factor of more than 100.
Yes, I just checked it.
time(), on DOS, takes much less time to execute when
you set a tick_rate (other than the default).
Another advantage to tick_rate() is that time() won't wrap around
every 24 hours, since I use a 32-bit clock-tick counter to count
the clock interrupts, rather than relying on the usual call to DOS.
I figure it would take several months to wrap, at 100 ticks/sec.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: DOS time() [was Re: Rob: Bug with Windows trasking translator]
- Posted by Bob Elia <bobelia200 at netzero.net>
Feb 18, 2006
-
Last edited Feb 19, 2006
Robert Craig wrote:
>
> Bob Elia wrote:
> > I have found that using tick_rate()under DOS32 with any legal value other
> > than 0 increases the speed of time() by a factor of more than 100.
>
> Yes, I just checked it.
> time(), on DOS, takes much less time to execute when
> you set a tick_rate (other than the default).
>
> Another advantage to tick_rate() is that time() won't wrap around
> every 24 hours, since I use a 32-bit clock-tick counter to count
> the clock interrupts, rather than relying on the usual call to DOS.
> I figure it would take several months to wrap, at 100 ticks/sec.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Ah, very interesting.
Does that mean that time(20) would take 5 * "several months" ?
Bob
4. Re: DOS time() [was Re: Rob: Bug with Windows trasking translator]
- Posted by Robert Craig <rds at RapidEuphoria.com>
Feb 18, 2006
-
Last edited Feb 19, 2006
Bob Elia wrote:
>
> Robert Craig wrote:
> > ...
> > Another advantage to tick_rate() is that time() won't wrap around
> > every 24 hours, since I use a 32-bit clock-tick counter to count
> > the clock interrupts, rather than relying on the usual call to DOS.
> > I figure it would take several months to wrap, at 100 ticks/sec.
>
>
> Ah, very interesting.
> Does that mean that time(20) would take 5 * "several months" ?
Yes. (You meant tick_rate(20))
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: DOS time() [was Re: Rob: Bug with Windows trasking translator]
- Posted by Vincent <darkvincentdude at yahoo.com>
Feb 19, 2006
-
Last edited Feb 20, 2006
Bob Elia wrote:
> I have found that using tick_rate()under DOS32 with any legal value other
> than 0 increases the speed of time() by a factor of more than 100.
> I think that it replaces the INT #08 (system timer) code with a different
> function internally.
> IIRC, it was necessary to call tick_rate() before trapping INT #08 (system
> timer)
> or my replacement ASM code wouldn't get executed.
Very Interesting. I've been using a machine coded time() routine, which offers a
simular performance factor.
> BTW, thanks for your effort on the include issue. I hope it all works.
I've done my testing and confirm it works great. This change will benefit
everyone now, later, or both.
Regards,
Vincent
