Date: Thu, 01 Nov 2001 07:53:47 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Bakul Shah <bakul@bitblocks.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011101075347.A94706@gsmx07.alcatel.com.au> In-Reply-To: <200110261914.PAA17908@devonshire.cnchost.com>; from bakul@bitblocks.com on Fri, Oct 26, 2001 at 12:15:00PM -0700
next in thread | previous in thread | raw e-mail | index | archive | help
[Resend due to mail bouncing]
On 2001-Oct-26 12:15:00 -0700, Bakul Shah <bakul@bitblocks.com> wrote:
>> >Okay, how about this? Define N types that will be
>> >*exactly* the same on *all* machines:
>> >
>> > time_t 32 bits (1 second resolution, upto yr 2038)
>> > nstime64_t 64 bits (10^-9 second resolution, upto yr 2554)
>>
>> Should be 1/2^32 resolution or you have a math nightmare dividing
>> by 1000000000 all the time.
>
>On my 500Mhz PIII it takes about 4.6ns to divide a 64 bit
>number by a 64 bit 10^9.
Are you sure? I've just _measured_ it on a PIII-600 and came up with
211nsec (averaged over 1e7 loops). Keep in mind that this solution
has to also work in embedded applications - which are several orders
of magnitude slower than this.
>> here: resolution 1/2^64 second.
>>
>> Decimal computers lost the race and they ai2768n't coming back. We want
>> arithmetic on binary computers to be fast and simple.
>
>Most everyone uses powers of ten for timing units.
No-one is suggesting that I/O has to be in binary. There's no
reason why you can't convert the internal binary format into
decimal. EDSAC managed this more than 50 years ago. Note that
it's _easier_ to convert a binary fraction to an arbitrary number
of decimal places than converting a integral number of zotto
(or whatever) seconds to decimal (feel free to consult [1] if
you disagree).
There are two logical timestamp formats for a binary computer:
1) Fixed point seconds with M bits to the left of the binary
point and N bits to the right.
2) Integral number of (fractional second units). (As used on
the IBM System 360 and later).
Both of which are far better than having programs full of
t1.tv_sec -= t2.tv_sec;
if ((t1.tv_usec -= t2.tv_usec) < 0) {
t1.tv_usec += 1000000;
t1.tv_sec--;
}
The former is probably a better choice because it's easier to expand
to the right (as things speed up) and you can more cheaply extract
lower-precision variants.
Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011101075347.A94706>