Date: Sat, 2 Jan 1999 12:15:47 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Gary Palmer" <gpalmer@FreeBSD.ORG> Cc: Jonathan Smith <jonsmith@fourier.physics.purdue.edu>, current@FreeBSD.ORG Subject: Re: Y2K, Y 2038? Message-ID: <199901022015.MAA34004@apollo.backplane.com>
next in thread | raw e-mail | index | archive | help
:While the world is still using 32bit CPUs the move to 64bit time_t will be
:expensive in terms of performance. We could probably make the move on the DEC
:Alpha, but until ppl move to the Merced (or whatever 64bit P.O.S. Intel
:produces) I don't think many people will like to take the performance
:degredation now.
:
:Personally, my thoughs on how to do this are to have new syscalls which return
:64 bit time_t variables, and you choose at compile time which ones you get
:(i.e. sorta like the way solaris 7 has done things)
:
:Gary
My personal opinion is that timekeeping and conversion is not generally
a critical performance component in any program, and that the only
time you typically manipulate it in a sophisticated fashion is when you
are doing time conversions, and even then you are only doing a few
multiplications and divisions before it is broken down enough that 'int'
can be used internally.
I consider the performance overhead of moving to a 64 bit time_t to be
minimal. In fact, I consider it to be virtually nil, just as the
performance overhead of using 64 bit file offsets internally is virtually
nil. Now, it seems doubtful to me that we can actually redefine 'time_t'
itself - we'd probably need a 'ltime_t' or 'dtime_t' or whatever the
standards organizations have come up with, but I see no problem in
converting all internal library routines to operate on a 64 bit time
quantity and just leave the leafs to support the old function calls.
-Matt
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications & God knows what else.
<dillon@backplane.com> (Please include original email in any response)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901022015.MAA34004>