1. Missing messages
Can anyone explain why my original post about the getPixel problem
appears on my PC on EuForum, but my second one definitely does not. And
yet other people have seen it because it has been responded to!
Something very odd is going on - I'd rather like to know what!
Andy
2. Re: Missing messages
Andy Drummond wrote:
> Can anyone explain why my original post about the getPixel problem
> appears on my PC on EuForum, but my second one definitely does not. And
> yet other people have seen it because it has been responded to!
> Something very odd is going on - I'd rather like to know what!
> Andy
In a nutshell:
Topica = unreliable (messages delayed, out of order, sometimes lost)
RDS EUforum Web interface post/view messages = reliable
RSS feed = reliable (if you check it daily)
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Missing messages
- Posted by Vincent <darkvincentdude at yahoo.com>
Dec 16, 2005
-
Last edited Dec 17, 2005
Robert Craig wrote:
> In a nutshell:
> Topica = unreliable (messages delayed, out of order, sometimes lost)
> RDS EUforum Web interface post/view messages = reliable
> RSS feed = reliable (if you check it daily)
How come you chose Topica anyway?
BTW... Where you able to pinpoint the issue with sequence operations or you
still trying to figure it out? That might be a good program to include with
modern Euphoria distrobutions and for your personal testing. I would test again
when you build Euphoria with Open Watcom v1.4 with better compiler optioned.
Regards,
Vincent
4. Re: Missing messages
Vincent wrote:
> Robert Craig wrote:
> > In a nutshell:
> > Topica = unreliable (messages delayed, out of order, sometimes lost)
> > RDS EUforum Web interface post/view messages = reliable
> > RSS feed = reliable (if you check it daily)
>
> How come you chose Topica anyway?
Chris Bensler set it up.
It was free.
It was better than Yahoo or MSN groups.
We needed a moderated group since someone was causing
problems and we had no way to control what he posted or
how often. We had kind of overstayed our welcome on
a university server that we had little control over,
and which had no decent moderation facility.
Lately Topica has deteriorated a bit more.
I recommend that people consider RSS or simply
use the RDS web interface.
> BTW... Where you able to pinpoint the issue with sequence operations or you
> still trying to figure it out? That might be a good program to include with
> modern Euphoria distrobutions and for your personal testing. I would test
> again
> when you build Euphoria with Open Watcom v1.4 with better compiler optioned.
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.
Note: With exw, time() is extremely fast.
Much faster even than ex version 1.2.
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.
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.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: Missing messages
Robert Craig wrote:
> Chris Bensler set it up.
> It was free.
> It was better than Yahoo or MSN groups.
> We needed a moderated group since someone was causing
> problems and we had no way to control what he posted or
> how often. We had kind of overstayed our welcome on
> a university server that we had little control over,
> and which had no decent moderation facility.
> Lately Topica has deteriorated a bit more.
> I recommend that people consider RSS or simply
> use the RDS web interface.
I see. I only use the web interface and RSS, so I'm saved from their mail server
reliability issues.
> 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? What about with the cooperative tasking in DOS, after re-scheduling
from a paused state?
> 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?
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()?
> 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.
> 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().
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Regards,
Vincent
6. Re: Missing messages
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
