Another improvement of gmtime_r()

Corinna Vinschen vinschen@redhat.com
Thu May 28 09:47:00 GMT 2015


On May 19 20:48, Freddie Chopin wrote:
> Hello!
> 
> You may assume that I have some strange obsession with gmtime_r(), but that
> wouldn't be true (; I just found a very good document about date algorithms
> with very good code samples that are placed in public domain, so I couldn't
> resist checking how does that compare to current newlib's code.
> 
> http://howardhinnant.github.io/date_algorithms.html#civil_from_days
> 
> I've added the author of the code to CC list.
> 
> It turns out that gmtime_r() with the algorithm from civil_from_days() by
> Howard Hinnant is ~13% faster on ARM Cortex-M4 - 3 million calculations take
> 29.5s vs 34s. The code is slightly larger, but we're talking about ~100
> bytes in that case.
> 
> I've verified the correctness of the calculations by comparing the modified
> code with results of gmtime_r() from glibc over the span of ~1600 years
> (with 64-bit time_t), every 60 seconds - the results match. I've also
> compared the results of the modified function with result of current code in
> newlib and they are also equal.
> 
> I attach patch and a Changelog entry.

Thanks.  Did you test that this still works on 16 bit machines?  A comment
in the aforementioned document points out that some extra care may be
required.  E.g., EPOCH_ADJUSTMENT_DAYS should probably be explicitely defined
as long const (like DAYS_PER_ERA, etc).


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20150528/d931da6a/attachment.sig>


More information about the Newlib mailing list