Time.ticks is a 32-bit counter?

[tve]

Do I see correctly that Time.ticks is internally an unsigned 32 bit counter and will thus roll over after 49 days? I routinely write stuff like

const t0 = Time.ticks
.. some code ..
const dt = Time.ticks - t0

and that will produce garbage when crossing a roll-over.
Thoughts?
Would there be appetite for a Time.diff(t_end, t_start) function that does a 32-bit unsigned subtraction, i.e. deals with the roll-over properly? (Or Math.isub ?)

[phoddie]

This one is a bit complicated/subtle. Thanks for bringing it up. Let's try to sort it out.

Ticks is only guaranteed to have 32-bits of resolution. However, the implementation is host dependent. The simulator on macOS, for example, provides more bits (53, since it uses a double). There is arguably a bug on ESP8266/ESP32, as it sets the return value with xsmcSetInteger() which is signed, so the value is negative half the time.

But.... that does mean that your example does not return garbage on roll-over. When t0 is 0xfffffffe the value in JavaScript is -2. When Time.ticks is 1, the result will be 3, which is correct.

Math.isub() is an interesting idea. But, I doubt it will get through TC39. So, we should probably look elsewhere.

Time.diff() seems reasonable. Perhaps a bit more efficient and portable solution would be something like Time.delta(t_start). That would give the difference from the current ticks -- combining retrieval of ticks with the subtract.

If we take the Time.diff() route, we need to take care that it works with the simulator - either by reducing the number of bits in the simulator or ensuring the implementation of Time.diff() there gives the correct result.

[tve]

"Hmmmm...." :-)

So what if ticks was a true number, i.e., became a float64 at 2^32 ? That would take almost 9000 years to become non-integer (48 bits)? But oh horror, float64 arithmetic?

I ran the following test on an esp32-c3 (risc-v):

import Time from "time"

const f = Float64Array.from([1000, 1000 / 3, 2 ** 40])
for (const i of f) trace(`${i}: ${Number.isInteger(i)}\n`)

for (let v of [30000, Time.ticks, 2 ** 28, 268435456, 2 ** 40, 1048576 * 1048576]) {
  const v0 = v + 1000
  const t0 = Time.ticks
  let dv = 0
  for (let i = 1000; i > 0; i--) {
    dv += v++ - v0 
    dv += v++ - v0 
    dv += v++ - v0 
    dv += v++ - v0 
    dv += v++ - v0 
    dv += v++ - v0 
    dv += v++ - v0 
    dv += v++ - v0 
    dv += v++ - v0 
  }
  const dt = Time.ticks - t0
  trace(`v=${v} took ${dt}ms: ${dt / 10000}ms ea (dv=${dv})\n`)
}

v=39000 took 44ms: 0.0044ms ea (dv=31495500)
v=9293 took 44ms: 0.0044ms ea (dv=31495500)
v=268444456 took 66ms: 0.0066ms ea (dv=31495500)
v=268444456 took 44ms: 0.0044ms ea (dv=31495500)
v=1099511636776 took 67ms: 0.0067ms ea (dv=31495500)
v=1099511636776 took 67ms: 0.0067ms ea (dv=31495500)

Slower? Yes. Crazy slow? Not really...

I then changed the statement in the loop to:

    dv += (v++ - v0) / 4

v=39000 took 85ms: 0.0085ms ea (dv=7873875)
v=9293 took 85ms: 0.0085ms ea (dv=7873875)
v=268444456 took 97ms: 0.0097ms ea (dv=7873875)
v=268444456 took 85ms: 0.0085ms ea (dv=7873875)
v=1099511636776 took 97ms: 0.0097ms ea (dv=7873875)
v=1099511636776 took 97ms: 0.0097ms ea (dv=7873875)

This is the first time I try to benchmark anything in XS, so please educate me if what I did ends up being all optimized away... But if these times are representative that looks pretty promising for "rolling over" into Float64?

[phoddie]

Yes, the return value could be a JavaScript Number (double). But, that's just the binding between C and JavaScript. The underlying value on an MCU is often 32-bit. On ESP32, for example, ticks comes from xTaskGetTickCount() which returns a 32-bit value (I just confirmed that). The ticks property exists to be a lightweight way to measure intervals (the implementation of xTaskGetTickCount just returns a FreeRTOS private local variable, so basically free). Add more code and state around the value to get more bits would defeat that, as would promoting to a double. Adding all that is getting closer to Date.now().

I'm not averse to making a change here, I'm also not 100% what problem we're trying to fix. Is there a wraparound problem currently? The simulators use doubles, so practically speaking there isn't an issue there. The values returned on an MCU subtract correctly when wrapping from negative to positive, at least.

[tve]

Correct me if I'm wrong: on an esp32 when the count goes from 0x7fff_ffff to 0x8000_0000 the value jumps from 2^31-1 to -2^31, i.e. the one-tick delta becomes -2^32+1

I certainly have devices running non-stop for several months. If a delta-ticks value is just used for plotting performance then it will "just" cause a spike in the plot. But if it's used to average/integrate measurements that are used to control stuff it can cause "interesting" behavior.

NB: the idea for a Time.diff method comes from Micropython (https://docs.micropython.org/en/latest/library/time.html#time.ticks_diff).

[phoddie]

Thanks, I overlooked the other edge.

I certainly have devices running non-stop for several months.

You and me both.

I'm not sure we should change the values returned, as that has the potential to break something. A function that safely subtracts those provides a graceful migration path while allowing for differences in the host (e.g. the simulator has 53 bits significant today). We could combine the diff and delta into a single call. If passed two values, it differences them as you propose. If passed one, it uses that as the start time and subtracts it from the current ticks. That would be a bit faster and more compact for many common uses.

[phoddie]

Here's a quick implementation to try. I named the function difference to follow your idea.

It is declared in time.js. The end argument is optional.

	static difference(start, end) @ "xs_time_difference";

The ESP8266/ESP32 in time/esp/time.c impelemtation is:

void xs_time_difference(xsMachine *the)
{
	uint32_t start, end;
	
	start = (uint32_t)xsmcToInteger(xsArg(0));
	if (xsmcArgc > 1)
		end = (uint32_t)xsmcToInteger(xsArg(1));
	else
		end = modMilliseconds();
	xsmcSetInteger(xsResult, end - start);
}

On macOS in time/mac/modTime.c:

void xs_time_difference(xsMachine *the)
{
	xsNumberValue start, end;
	
	start = xsToNumber(xsArg(0));
	if (xsToNumber(xsArgc) > 1)
		end = xsToNumber(xsArg(1));
	else {
		c_timeval tv;
		c_gettimeofday(&tv, NULL);
		end = ((double)(tv.tv_sec) * 1000.0) + ((double)(tv.tv_usec / 1000));
	}
	xsResult = xsNumber(end - start);
}

Linux should be able to use the Mac implementation. Note that Time.ticks is currently unimplemented on Linux, so that should be copied over from macOS too.

If this seems like a good direction, I'll take care of the other platforms (Windows, wasm, Pico, etc). It would be good to get your evaluation and testing on this before that though. Thanks.

[tve]

Will try!
Any chance to call it "diff"? I often end up using it in trace statements or longer expressions and ... they get very long already...

[phoddie]

The API style favors full words. It can get confusing when some APIs are abbreviations and others are not. For developers using editors that make suggestions it doesn't matter much. Maybe delta() is better choice, as a shorter full word?

[tve]

delta sounds good. Btw, according to merriam-webster "diff" is a noun, and not just an abbreviation... 😇️

[phoddie]

delta sounds good

Let's plan on that. Please let me know if the implementations work for you.

Btw, according to merriam-webster "diff" is a noun, and not just an abbreviation... 😇️

Ha. True. But it also notes it is "slang" created "by shortening." First used in 1896.