Re: Lua for Time Travel (!)

[Ross Berteig <ross@...>]

On 1/25/2017 2:49 PM, Rena wrote:

On Wed, Jan 25, 2017 at 3:25 PM, William Ahern <william@25thandclement.com> wrote:

On Wed, Jan 25, 2017 at 01:21:36PM +0000, Joseph Manning wrote:
> Dear All,
>
>    Have you ever wondered how the Lua Team manage to retain their
>    ever-youthful good looks?

I always assumed there were some paintings in a vault that are aging slowly...

> ....
>    So, I was timing a section of code by wrapping it in calls to
>    'os.clock( )', and under certain conditions, the second such call
>    returned a value that was substantially smaller than the first --
>    in fact, it returned a negative value, which should never happen.
....

In C I just explicitly type cast clock_t values (each operand individually)
to unsigned long, and everything just magically works because of modulo
arithmetic. But I'm making assumptions about the platform--that it's two's
complement and that unsigned long is the corresponding unsigned type for
clock_t. I really only use it for debugging and quick benchmarking. But as
mentioned in that ticket there's no [easy] portable way to figure out which
unsigned type to convert to. For Lua you'd probably have to use a function
with conditional logic, just like a portable C solution would likely use.

According to the clock() manpage [1], CLOCKS_PER_SEC effectively must be the constant 1000000. I'm not sure why clock_t is permitted to be signed, but it clearly is a signed type on 32-bit x86 linux. Even if unsigned, clock() rolls over after a little less than 72 minutes or 2^32 microseconds.

So perhaps Lua's implementation of os.clock() ought to cast the result of clock() to a platform-specific sized unsigned value since by the time it has been converted to a floating point value it is too late for the Lua code to do much with it in a portable way when it goes negative.

....

Perhaps it would be ideal for Lua to automatically save the previous result of clock() and subtract it from the next call? Or would that be too different from the underlying API?

If you did anything like this, it would be to remember the value returned from the first call to clock() and subtract that from all subsequent calls, and possibly make that first call to clock() as part of initializing the os module so that 0 is close to the actual start of the program. The Lua manual [2] does say "Returns an approximation of the amount in seconds of CPU time used by the program" so taming the fact that POSIX permits clock() to return anything at all at the start of the process might be arguably the correct thing to do. Or relax the documentation to merely claim that os.clock() will be monotonic until it wraps, which might be in 72 minutes, or until the heat death of the universe, depending.

Either way, it does seem like a bug that os.clock() could return a negative number, and fixing that would not be difficult. Preventing the wrap to zero on 32-bit systems would be substantially more difficult, technically possible, and likely completely not worth the effort. It could also be done in pure Lua, if you can make the assumption that os.clock() will be called often enough.

[1]: https://linux.die.net/man/3/clock
[2]: https://www.lua.org/manual/5.3/manual.html#6.9

-- 
Ross Berteig                               Ross@CheshireEng.com
Cheshire Engineering Corp.           http://www.CheshireEng.com/
+1 626 303 1602