[WIP] Make get-internal-real-time monotonic

[eugeneia]

See Also: #20

This work-in-progress PR moves ccl:current-time-in-nanoseconds from lib/time to l1-lisp-threads, and uses it to implement get-internal-real-time and ccl::get-tick-count.

The previous implementation of get-internal-real-time remembered the initial seconds value and subtracted it from values before returning them. I.e. the values returned by get-internal-real-time would be close to zero after starting CCL. The new implementation does no such thing, the value returned is relative to system boot time.

Additionally it changes ccl:current-time-in-nanoseconds to

• return a monotonic value on Windows (>=Vista, see https://msdn.microsoft.com/en-us/library/windows/desktop/ms724411%28v=vs.85%29.aspx)
• return a nanosecond value on Darwin (presumably, there was a bug here, see https://developer.apple.com/library/content/qa/qa1398/_index.html)

Could anyone on Windows/Darwin test these changes? I remember Microsoft to provide virtual machine images for testing, but I doubt they include a C compiler? Anyway, this should print as shown below:

(let* ((a (get-internal-real-time)) (at (ccl::get-tick-count))
         (_ (sleep 3))
        (b (get-internal-real-time)) (bt (ccl::get-tick-count)))
   (print (float (/ (- b a) internal-time-units-per-second)))
   (print (float (- bt at)))
   (print ccl::*ticks-per-second*)
   (values))
;Compiler warnings :
;   In an anonymous lambda form at position 0: Unused lexical variable _
3.000157 
3000.0 
1000

[xrme]

This looks like a job for defconstant.

[xrme]

Also defconstant.

[xrme]

For the record, I believe the reason that we saved the initial seconds value from gettimeofday was so that operations on internal time unit values would likely be fixnum operations.

It's definitely more correct to use mach_timebase_info instead of assuming that Mach absolute time units are nanoseconds. They are on the Mac, but I think they're different on iOS devices (not that there's much chance that we'll run on iOS devices, but you never know). Good catch there.

If we use GetTickCount64, that means we're dropping support for running on Windows XP. I'm not necessarily against this, but we need to make that clear.

We might also have to generate new Windows headers so that the #_ reader macro will know about GetTickCount64. Or we could just use ccl:external-call and put off dealing with new headers. I'll check all this on a Windows box as soon as I can.

[eugeneia]

Note that only on Windows this ccl:current-time-in-nanoseconds includes the time passed while the system is suspended. For instance, the laptop lid is closed, etc.

[eugeneia]

I also thought about fixnums with regard to internal-time-units-per-second.

(float (/ most-positive-fixnum internal-time-units-per-second 60 60 24))

• On 32bit CCL the value returned by get-internal-real-time is a fixnum for at most 6.2137837 days
• On 64bit CCL the value returned by get-internal-real-time is a fixnum forever
• If internal-time-units-per-second were nanoseconds the value returned by get-internal-real-time is a fixnum for at most ~36 years on 64bit CCL and always boxed on 32bit CCL

I am temped to ignore the six days of fixnums on 32bit CCL because it’s an easily imaginable run time of a program. Since we are getting time in nanoseconds here anyways, the 36 year mark applies indirectly through ccl:current-time-in-nanoseconds. I figured we could change internal-time-units-per-second to nanosecond precision. It’s a somewhat messy change (I ended up needing to rebuild twice to get a correct build because the compiler did constant things), but would simplify things.