Re: Exposing subsecond precision in current-seconds

[Peter Bex]

On Thu, Apr 30, 2020 at 01:04:08AM +0200, address@hidden wrote:
> > I was trying to illustrate how annoying it'd be to have to jump through
> > hoops if you need to print the time in a human-readable way or convert
> > it to a more "standard" epoch-based representation that includes
> > subsecond information.
> 
> I find this unconvincing. These appear to me already as special cases
> that would require a customized approach. I see subsecond timing
> as a necessarily lightweight internal time-measurement device.

Fair enough, but the original question was about having subsecond info
about the current time.  So if I'm understanding you correctly this
is something better developed as an egg, outside of core.

I'm not 100% in agreement, but if it's this controversial I think an egg
is the best way forward for this particular functionality.

> > And also, if current-seconds returns time since the epoch, it's confusing
> > if current-microseconds or current-milliseconds returns time since
> > <something else>.  See also the mistake in the SRFI-19 egg where it
> > appends current-milliseconds to the timestamp, assuming it's using the
> > same base as current-seconds is.
> 
> I don't disagree here, confusing it is. You suggested deprecating
> "current-milliseconds", right? Perhaps it should be replaced by
> a differently named primitive.

Yeah, like I said in my other message, we could use the name
current-process-milliseconds, like Racket;
https://docs.racket-lang.org/reference/time.html

I like the name, because it's pretty clear what it does; it yields the
number of milliseconds the process has been running for.

We can make it a procedure without arguments, because that part of the
Racket interface looks messy and confusing to me.

> > In that case, you'd definitely be allocating, which would probably
> > eat more words than a plain bignum, so I'm kind of confused as to
> > what your goals are for this API.
> 
> In that case you have special needs, that's all I'm saying. My goal is
> quite clear: I want something simple and efficient, a primitive operation
> that is sufficient for cases where efficiency is required, not designed
> for what look to me as uncommon cases.

In that case I think we should keep the current situation, except we fix
the confusion surrounding the procedure's name.

> Something like "current-microseconds" is likely to be used in time
> critical code (schedulers, profilers, etc.) You want to to be fast, ideally
> not consing, especially on small or embedded systems.

Yes, I agree that for those use cases you don't want to be consing.
But then microsecond precision might be too much already, on 32 bit
platforms.  A program that has an uptime of a month already needs 42
bits to represent the time since startup in microseconds.

> > I'd like to point out that current-seconds already returns a bignum
> > on 32-bit systems.
> 
> Correct. But it's resolution is too coarse to be a suitable candidate for
> tight timing code.

I think millisecond precision is enough for core, and I'm not sure we
need microseconds.  So far, I think the use cases we've discussed aren't
necessarily those of OP.

Cheers,
Peter

signature.asc
Description: PGP signature