Regarding timestamp - of course it would be possible to create
your own timestamp string from the pieces you want but maybe
a new refinement on either the time or date value or 'now function
could be created. Call it /nonano to retrieve the classic time/date
stamp. Just a thought.
Regarding the benchmarks - I'm having a little trouble figuring
out why 'now is taking so long and also why my 'C' examples are
giving the results they are. Here are the functions I am comparing
(two in C++ and one in Rebol - WinNT 4):
static void testtime()
{
int n = 0;
time_t tt;
time_t t1 = time(0);
while (n < 1000000)
{
n = n + 1;
tt = time(0);
}
time_t t2 = time(0);
printf("time: %d", (t2-t1));
}
#include "windows.h"
static void testtime2()
{
int n = 0;
SYSTEMTIME tt;
SYSTEMTIME t1;
SYSTEMTIME t2;
GetSystemTime(&t1);
while (n < 1000000)
{
n = n + 1;
GetSystemTime(&tt);
}
printf("time: %d", (t2.wSecond - t1.wSecond));
}
REBOL[
t: now/time
n: 1
while [n < 1000000]
[
n: n + 1
nt: now/time
]
tt: now/time
probe (tt - t)
]
Here are the results from my system:
First C example using time() - prints around 3 seconds
Second C example using GetSystemTime() - prints around 1 second
Rebol example - prints around 16 seconds
I don't quite understand a couple of things. The first is how
GetSystemTime() can be faster than time() (since it is splitting
out all the fields year, day, etc.). The second is why it takes
Rebol so long. I of course would expect Rebol to take a longer
time but it seems a little excessive on the outset. Maybe Rebol
has no way of "compiling" a statement and interprets it each time?
Note that just comparing a C example of incrementing an integer
a million times vs the Rebol equivalent shows that Rebol is about
4 times slower with this task - again, not totally unexpected but
it does seem like a lot slower.
Another wierd thing I don't understand is if I replace the
'while loop in the Rebol example with a 'for loop, the result
is around 20 seconds! Thus, using a 'for loop in Rebol is
slower than using a 'while loop which doesn't seem right to
me. I tried the same thing with the C examples and for loops
are a little faster than while loops, but not much. Maybe
Carl and Co. have some clue about this.
So, not sure what all this means or if there is any way to optimize
the Rebol operations. My main concern is that the only way
to have a timer in Rebol and still perform other processing is
to loop and call 'now each time which obviously takes a big chunk
of time.
One bug I saw, even though the users-guide says that refinement of /second
should work on a date! type, it does not in Rebol/Core. Maybe
this is fixed in /View?
Rodney
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 20, 2000 7:46 AM
To: [EMAIL PROTECTED]
Subject: [REBOL] teeny-bits-of-time/2 Re:(2)
You are correct... that what all those bits for subseconds are hanging
around for. It's supposed to be part of REBOL/Core.
But, it would also create the problem of NOW returning that many digits. Do
you want your email to be timestamped: 20-June-2000/7:35:42.532654-7:00.
Maybe.
Also, WRT calling NOW in a loop. Note that it is very expensive on some
systems! Compare the loop timing on this line to that below that calls NOW.
It takes nearly 10 times longer (under WinNT) if you call NOW. Ryan's loop
should be up in the 400000 range rather than 38000. Amazing, isn't it.
t: now/time n: 1 while [n < 1000000] [n: n + 1] n / third (now/time - t)
-Carl
At 6/19/00 05:10 PM -0700, you wrote:
>I would think that /Core really needs to return the
>known subsecond value when now/time is called.
>RT obviously recognized the need because they allow you
>to represent times down to the nanosecond (look at the
>time! datatype description in users guide) and it seems
>restrictive to me to not allow now/time to return the
>nanoseconds part of the time.
>
>The only issue here is that every OS is different and some
>don't allow subsecond timing and most only allow millisecond
>timing. Plus the time functions for each OS are different if
>you want this subsecond info. But it is possible to handle it.
>
>Once /Command comes out you will be able to write your own function
>to do this - but then you'll be stuck with the OS you choose to write
>it for so I really hope RT puts this in /Core. There really is no
>good way to hack around it.
>
>Rodney Snell
>
>
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]
>Sent: Monday, June 19, 2000 4:26 PM
>To: [EMAIL PROTECTED]
>Subject: [REBOL] teeny-bits-of-time/2
>
>
>In my quest to count teeny bits of time in REBOL, I created the following
>counting expression which makes note of how high REBOL can count in
>increments of 1 within a single second.
>
>forever [ t: now
> c: 1
> while [ now = t ][ c: c + 1 ]
> print c
> append b c
> c: copy []
>]
>
>Of course, the results are entirely dependent upon the computer system you
>are using and how many other tasks the computer may be processing at the
>moment. Here are the results of running the expression on an Intel Celeron
>333MHz workstation running Windows NT 4 (bear in mind the first number
>returned is the remaining number of times the expression can count from 1
>within the second the expression begins):
>
>2498
>37594
>37261
>37103
>37313
>37555
>37551
>37274
>37472
>37563
>37195
>37539
>37556
>37496
>37579
>37386
>37540
>37108
>>>
>
>I guess this is a REBOL benchmarking expression of sorts.
>
>If you could run this expression continuously while running other REBOL
>scripts--and if you could call the count from within the expression using
>another REBOL script running in parallel--you could create a fraction of a
>second based on the average count total during a specified period of time.
>
>For example, you call 'c from the expression when 'c = 2000. Perhaps the
>average number of counts during the previous 10 seconds was 37,501 counts
>per second. Then the fraction would be .053331 seconds. REBOL could
>return a special 'now of
>
>>> now
>== 19-Jun-2000/18:20:44.053331-5:00
>
>or
>
>>> current-time: now/time
>== 18:20:44.053331-5:00
>
>Then you have your milliseconds, microseconds, and nanoseconds as
>follows:
>
>>> print current-time/second
>44
>>> print current-time/millisecond
>5
>>> print current-time/microsecond
>33
>>> print current-time/nanosecond
>31
>
>Of course, this is a very imprecise way of measuring sub-second intervals
in
>
>REBOL.
>
>Any suggestions on how this might be implemented?
>
>-Ryan
>
