Date: Fri, 26 Oct 2001 16:20:12 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, Bakul Shah <bakul@bitblocks.com>, Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG, Poul-Henning Kamp <phk@critter.freebsd.dk> Subject: Re: 64 bit times revisited.. Message-ID: <Pine.BSF.4.21.0110261602270.11653-100000@InterJet.elischer.org> In-Reply-To: <200110262128.f9QLSX838762@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
geez, guys if you all preceeded your comments by "In my opinion" or "It seems to me that ..." we'd get less agro here. Here are some random thoughts.. Often, just the seconds are needed, a 128 but fixed point value can be replresented by 2 x 64bit values, and there is no need to read the fractional part. Things that are going to want decimal are destined for humans. In that case it seems to me that other formatting that will be going on will mask the time needed to do a decimal conversion. Humans probably don't care about the picosecond parts anyhow. With a 64 bit mantissa, a nanosecond acn be expressed to an accuracy of 1 part in 16 billion. that's certainly close enough for me, considering the accuracey of timesources.. I would put it that possibly, if we look at the options, that the internal time reference could be best represented by 64 bits of second and 64 bits of 1/(2^64)th of a second. Constants of mSecs, uSecs, uSecs can be easily given to an accuracy that will cover all human scale concerns. When needed this can be treated as a single 128 bit number, or a single 64 bit number of seconds, with no conversions needed. I can't really think of places where the kernel internal representation of time needs to be accessed as a decimal number except for file timestamps (and that's only if they are defined that way). Certainly not cases that are really time critical. I think that when programs look for such things the interface can convert. Julian On Fri, 26 Oct 2001, Matthew Dillon wrote: > > :>::so far for the in-kernel time keeping, IMO. > :> > :> And I will also note that trying to represent both seconds and sub-seconds > :> in a single fixed point integer is a real bad idea. It makes life > :> unnecessarily difficult for the 95% of the code that only needs the > :> seconds portion. Any fractional representation should be a SEPARATE > :> field. > : > :Err it is a separate field. You have a 128-bit counter. The high 64-bits are > :the seconds portion. You just shift to get the seconds. This is not hard. > :Computers have been good at doing shift right's for quite some time now. > : > :-- > : > :John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ > > The phrase 'no freaking way' comes to mind. > > You guys are outsmarting yourselves. Seconds, ok. That's it. Nothing > else. The *VAST* majority of programs only need seconds, it would be > utterly stupid to require that they mess around with some weird fixed > point quantity when all they want is seconds, no matter how supposedly > 'simple' that messing around is (i.e. '>> 64' is not acceptable). > > -Matt > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > 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?Pine.BSF.4.21.0110261602270.11653-100000>