Re: Missing messages

new topic     » goto parent     » topic index » view thread      » older message » newer message

Vincent wrote:
> Robert Craig wrote:
> > Yes, I figured it out.
> > 2.5 ex.exe is actually faster than 1.2 ex.exe by about 20% when
> > doing sequence operations. Where 1.2 is winning big-time is
> > on the time() function. Each of these benchmarks 
> > calls time() each time around the loop. 1.2 uses the old
> > DOS4GW DOS extender that I think had a special optimization
> > for time(). Anyway it's about 70x faster than the time()
> > in 2.5. time() does a DOS interrupt, something that's often quite
> > expensive with a DOS extender. 
> 
> Does this affect time profiling with DOS Euphoria too, or is there no
> connection?

time() and time profiling are connected, but the performance of time()
has little to do with the accuracy or performance of time profiling.

> What about with the cooperative tasking in DOS, after re-scheduling from a
> paused
> state?

The scheduler checks time() quite often, but it's usually when
it has nothing to do but wait for the clock to tick ahead, so  
it doesn't matter much. I might replace time() with something better
anyway, so we can get better resolution for scheduling.
 
> > Note: With exw, time() is extremely fast.
> > Much faster even than ex version 1.2.
> 
> Yea I noticed it's alot fast, but what about Linux and FreeBSD?

time() on Linux and FreeBSD is a couple of orders of magnitude
faster than on DOS.

> When I tested it with v2.5 'exw.exe', the results where alot better, but v1.2
> 'ex.exe' oddly still won overall:
> 
> v1.2 performed 180,461 more initializations per second than v2.5 (lost)
> v1.2 performed 170,586 more sequence-adds per second than v2.5 (lost)
> v1.2 performed 5,062,951 more appends per second than v2.5 (lost)
> v2.5 performed 2,859,499 more slices per second than v1.2 (won) ???
> v2.5 performed 64,637 more look-ups per second than v1.2 (won)
> 
> Perhaps there is more to this than just the speed of time()?

You are comparing Windows vs DOS.
The storage allocator is quite different.
The timings of some benchmarks could be better or worse.
 
> > I checked 2.5, 2.4, 2.1, 1.4, 1.3 and 1.2. 
> > The change comes between 1.3 and 1.4.
> > That's when I switched to the CauseWay DOS extender.
> > 2.5 comes out a bit faster than all the other releases
> > after 1.3 on this benchmark. I think the benchmark is 
> > a bit flawed because it inadvertantly places a lot of 
> > importance on the time() function.
> 
> The sieve benchmark uses time() too. Eu v1.2 'ex.exe' performs 813 more sieves
> a second than v2.5 'ex.exe'. However v2.5 'exw.exe' performs 107 more sieves
> a second than v1.2 'ex.exe'. Without time(), v2.5 'ex.exe' probably performs
> better than v1.2 'ex.exe'; we just couldn't see the results that way.

It's better to change the benchmark so it does a fixed number
of iterations (e.g. for i=1 to 1000000 do), 
rather than checking time() each time around the outer loop.
 
> > Fortunately, when a program calls time(),
> > it's usually not in a time-critical section. 
> > Often it's just waiting for the clock to advance,
> > or it's timing some operation.
> 
> Is there anyway you could make the DOS time() routine faster? Possibly by
> re-writing
> it in ASM? If that could be done, I think 70x slower is enough to warrant a
> new implementation for DOS! By re-writing it, you could also remove that nasty
> 24 hour reset limit? One thing is for sure, you wouldn't have any trouble
> implementing
> it; there are several Euphorians' with x86 ASM coding experience, certainly
> enough to help you write a new DOS time().

I vaguely recall (from a decade ago!) that DOS4GW (used in 1.2) 
might be quickly peeking into memory to see if the time has advanced.
Only if the time has changed since the last call does it actually
call DOS to get the official time. When a DOS extender calls DOS,
it must switch the CPU into 16-bit mode, call DOS, then switch the
CPU back into 32-bit mode. There's a significant amount of overhead.

Yes, I would be interested in making DOS time() faster,
and immune to the 24-hour problem.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu