ansaurus

Question

Answer 1

+1 A:

Your method seems sound, but it's a little more difficult to get it to work for EPOCH_YR = 1970 because you are now mid-cycle on several cycles.

Can you see if you have an equivalent for that case and see whether it's still better?

You're certainly right that it's debatable whether that gmtime() implementation should be used in any high-performance code. That's a lot of busy work to be doing in any tight loops.

Cade Roux 2010-06-28 21:51:05

Just subtracting the number of days from years 0..1970 would work. This would be constant, could be stored as another #define.

Adam Shiemke 2010-06-28 21:56:58

As Adam said, simply subtracting the offset would fix that, although it would overflow a 32-bit timestamp. Setting the epoch to 2000 AD would fix both problems, requiring one extra operation before and after the main computation.If 64-bit timestamps are available, ISO year zero is probably better as it a) saves an operation, b) is more obvious, and c) easy calendar-agnostic day-of-week. On the other hand, if you're stuck with a 32-bit timestamp with a modern-day epoch, you might as well forget the 100- and 400-year cycles, since 2000 is a leap year anyways and 1900 and 2100 are out of range.

Thom Smith 2010-06-28 22:06:09

@Thom Smith The # of days in 2000 years (~730k) is well below 2^32. Neither code snip is concerned with seconds.

Adam Shiemke 2010-06-28 22:12:08

I cut out the other bits; they're in the links. The gmtime function takes in a standard UNIX timestamp from which dayno is derived.

Thom Smith 2010-06-28 22:23:14

@Thom Smith: You may argue that "ISO year zero is probably better", but existing practice on POSIX systems is to redefine `time_t` as a 64 bit type with the same epoch, as this allows old programs to continue to work.

caf 2010-06-29 02:04:45

If you have 64-bit timestamps, then both epochs have virtually identical performance anyway, so it shouldn't affect the code in question.

Thom Smith 2010-06-30 16:32:13

Answer 2

+2 A:

Ran your code as y2 minix code as y1 Solaris 9 v245 & got this profiler data:

 %Time Seconds Cumsecs  #Calls   msec/call  Name
  79.1    0.34    0.34   36966      0.0092  _write
   7.0    0.03    0.37 1125566      0.0000  .rem
   7.0    0.03    0.40   36966      0.0008  _doprnt
   4.7    0.02    0.42 1817938      0.0000  _mcount
   2.3    0.01    0.43   36966      0.0003  y2
   0.0    0.00    0.43       4      0.      atexit
   0.0    0.00    0.43       1      0.      _exithandle
   0.0    0.00    0.43       1      0.      main
   0.0    0.00    0.43       1      0.      _fpsetsticky
   0.0    0.00    0.43       1      0.      _profil
   0.0    0.00    0.43   36966      0.0000  printf
   0.0    0.00    0.43  147864      0.0000  .div
   0.0    0.00    0.43   73932      0.0000  _ferror_unlocked
   0.0    0.00    0.43   36966      0.0000  memchr
   0.0    0.00    0.43       1      0.      _findbuf
   0.0    0.00    0.43       1      0.      _ioctl
   0.0    0.00    0.43       1      0.      _isatty
   0.0    0.00    0.43   73932      0.0000  _realbufend
   0.0    0.00    0.43   36966      0.0000  _xflsbuf
   0.0    0.00    0.43       1      0.      _setbufend
   0.0    0.00    0.43       1      0.      _setorientation
   0.0    0.00    0.43  137864      0.0000  _memcpy
   0.0    0.00    0.43       3      0.      ___errno
   0.0    0.00    0.43       1      0.      _fstat64
   0.0    0.00    0.43       1      0.      exit
   0.0    0.00    0.43   36966      0.0000  y1

Maybe that is an answer

jim mcnamara 2010-06-28 22:00:35

Answer 3

+2 A:

This is pure speculation, but perhaps MINIX had requirements that were more important than execution speed, such as simplicity, ease of understanding, and conciseness? Some of the code was printed in a textbook, after all.

bk1e 2010-06-29 06:07:19

ansaurus

tags:

views:

answers:

Why is gmtime implemented this way?

related questions