Time-related procedures Lassi Kortela (09 May 2019 11:36 UTC)
|
Re: Time-related procedures
Lassi Kortela
(09 May 2019 15:38 UTC)
|
Re: Time-related procedures
John Cowan
(10 May 2019 00:54 UTC)
|
Re: Time-related procedures
Lassi Kortela
(10 May 2019 11:48 UTC)
|
Re: Time-related procedures
Lassi Kortela
(10 May 2019 11:57 UTC)
|
Time-related procedures Lassi Kortela 09 May 2019 11:36 UTC
Should time stuff be in scope for this SRFI? I would leave it out, except for file timestamps. The rationale is as follows. >(process-times) >Returns four values: >user CPU time in clock-ticks >system CPU time in clock-ticks >user CPU time of all descendant processes >system CPU time of all descendant processes >Note that CPU time clock resolution is not the same as the real-time >clock resolution provided by time+ticks. What is CPU time -- If a process runs code on several cores, are all the cores counted? If not, does it count the core making the query or the "main" core of the program? What about hyper-threading (e.g. a dual-core processor having 4 "virtual cores")? How does one distinguish between user and system time on microkernel OSes like QNX, GNU HURD, etc.? What would be the applications of this procedure, and can we specify it so that it serves their purpose? Process monitor programs like "top" and "htop" are notorious in that they basically have to be re-implemented for each OS they support. There is little in the OS APIs that is both portable and unambiguous. > (cpu-ticks/sec) > Returns the resolution of the CPU timer in clock ticks per second. > This can be used to convert the times reported by process-times to > seconds. What about CPUs that can adjust their clock frequency while running? What about multi-core systems? What about counter wraparound? What would be the applications of a CPU tick counter, and can we serve them? The only one I can think of off the top of my head is profiling the execution time of code. That application would be better served by a dedicated profiling API. Then the Scheme implementation would be free to use whatever techniques make for the most accurate profiling. More generally, portable interfaces to microsecond/nanosecond precision timers are questionable (i.e. I would put the burden of proof on whoever proposes them to prove that they are reliable and useful for some application). Timestamps that have been recorded at some previous time are OK (e.g. file timestamps). Then we are simply reading an old timestamp that isn't dependent on accuracy of any timer measuring the current time. But anything that depends on sub-second timing _in the present moment_ should give us a little pause (no pun intended :) > (time+ticks) ---> [secs ticks] > The current time, with sub-second resolution. The time is returned as > elapsed seconds since the Unix epoch excluding leap seconds, plus a > number of sub-second "ticks." I would recommend being more explicit with the time APIs. Dealing with time is like quicksand (even more so than OS APIs in general). It's best to specify precisely what kind of timestamp we want and assure ourselves that we can reliably get one. There are several clock sources which all have their own uses: * Any monotonic (never decreasing) clock source, used as a counter. * Human time in TAI (can decrease when adjusted, counts leap seconds). * Human time in UTC (can decrease when adjusted, skips leap seconds). * Human time in local time (timezone, daylight saving time). * Various profiling and tick timers close to the hardware. * Vectored clocks for network applications. Good references for time stuff include: Implementing POSIX clocks under Linux (Markus Kuhn) https://www.cl.cam.ac.uk/~mgk25/posix-clocks.html The Long, Painful History of Time (Erik Naggum) http://naggum.no/lugm-time.html D. J. Bernstein's time pages: https://cr.yp.to/time.html