lkml.org 
[lkml]   [2014]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00/25] Change time_t and clock_t to 64 bit
On Wed, 14 May 2014, H. Peter Anvin wrote:

> On 05/14/2014 02:33 PM, John Stultz wrote:
> >
> > We can do some tricks for internal optimizations here if these are
> > critical. I'd be more concerned about userland divisions where moving
> > to a 64bit time_t would cause performance issues that we cannot help
> > optimize.
> >
>
> Honestly, the cost of not addressing the Y2038 problem in plenty of time
> is going to be way, way, way, way more expensive than some additional
> arithmetic.
>
> As far as converting to calendar notation (e.g. the Gregorian calendar),
> only the first division needs to be done with full time_t width.
> Furthermore, since the divisor is known a priori, the compiler *should*
> be able to do it as an inverse multiply.[1]

The compiler is apparently not that smart. It does it already for 32 by
32 bit divisions, but not for 64 by 32 divisions. Fortunately, with
gcc-4 at least, constant propagation on long longs works well enough to
do it by hand. That's how I implemented do_div() for ARM years ago.
See arch/arm/include/asm/div64.h from line 65. The same could be
implemented for x86 and others.


Nicolas


\
 
 \ /
  Last update: 2014-05-15 06:01    [W:0.364 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site