About child time versus elapsed real time?

Hi,

Jan W. wrote here:

Interestingly I have removed this feature, since I figured out how
to measure elapsed real time on Java, JavaScript and Python platform.
But it could be still usefull, for example for concurrent_and/2.

But if you only have one concurrent_and/2 running in the top-level
thread, and no other threads calling concurrent_and/2, or no other
threads running on your machine, the elapsed real time measurement

can be as good, and is much simpler. You don’t need to code some
extra book keeping. But for SWISH this cannot be assured I guess,
multiple users might want to run concurrent_and/2? Or is this

blocked in the sandbox? I have stashed all my child time computation
stuff for a simpler Prolog system. I am not 100% sure whether SWI-Prolog
has elapsed real time, its a monotonic clock. So the daylight saving

this night, should not affect it, when you had your computer running
and if wall clock were adjusted.

Edit 26.03.2023
I did this changes the last days, and I am now using, the elapsed realtime
is in milliseconds. In nodeJS there is a new API which returns a BigInt!
The browser API is also relatively new:

Java: (System.nanoTime()+500000)/1000000;
JavaScript nodeJS: Number((process.hrtime.bigint()+500000n) / 1000000n);
JavaScript browser: Math.round(performance.now())
Python: int(round(time.monotonic()*1000))

As a monotonic clock it has an arbitrary reference point. I am using the
statistics/2 key “time” for it now. It can be also used for timed wait(),
to redo the wait() in case of a spurious yield. BTW: Since 2018, Firefox 60,

the accuracy of performance.now() is anyway 1 millisecond.

Funny :slight_smile: For real time I simply use get_time/1, which uses the wall time clock of the machine using clock_gettime(CLOCK_REALTIME, &tp) if provided. True is is not correct for measuring elapsed time due to daylight saving time switches as well as time adjustments for synchronization. Seems a bit theoretical to me. Who is going to run a performance test as DST switch? :slight_smile: If I’m not mistaken NTP time adjustments these days make the clock tick a bit slower or faster if it is ahead/behind.

The main idea is indeed to get timing from concurrent predicates such as concurrent_maplist/3, concurrent_and/2, etc. easier to interpret. I don’t really see how real time is particularly useful to that as it doesn’t deal with not getting enough cores or code waiting for I/O.

The code complexity is not impressive. The main issue is to keep track of the creator. There is a thread-handle, but these are subject to garbage collection and we do not want to interfere with that. Other thread identifiers are reused. Eventually added a 64-bit sequence number to a new thread.

So your answer to the below question is negative?

You would rather use CLOCK_MONOTONIC or CLOCK_BOOTTIME, if you want
to provide a monotonic clock, like I am now providing by the statistics/2 “time” key.
Actually it seems to me CLOCK_BOOTTIME is what is understood by the full phrase

“elapsed real time” in some jargon, note the little word “elapsed”, for example in
Androids elapsedRealtime() API, which says milliseconds since boot, including
time spent in sleep [continues to tick even when the CPU is in power saving modes].

It seems Linux can also make the distinctions as per discussion here:

  • CLOCK_REALTIME represents the machine’s best-guess
    as to the current wall-clock, time-of-day time.
  • CLOCK_MONOTONIC (optional feature): represents the absolute elapsed
    wall-clock time since some arbitrary, fixed point in the past.
  • CLOCK_BOOTTIME: Like CLOCK_MONOTONIC, but the clock
    does include the time during which the system is suspended.

Unlike CLOCK_REALTIME, the monotonic clocks aren’t affected by changes in
the system time-of-day clock. But since they have an unusual fixed point, they
are not suitable for date conversions.

Edit 26.03.2023
Maybe your Prolog system goes into power saving for this test case.
So what will be the result, if you use the wrong monotonic clock?

?- time(sleep(60.0)). /* 60.0 Seconds = 1 Minute */

Although its unlikely if your console has a blinking cursor? But
what if you run a batch without any kind of a console?

sleep/1 is implemented using POSIX nanosleep() if possible (with several fallbacks if needed). The Linux docs state some rather hard to understand things about the clock used. For Linux itself it is CLOCK_MONOTONIC. I don’t see how this related to power saving, neither to blinking cursors. The console is a separate process.

Introducing something like thread groups seems attractive as it may largely simplify concurrent_and/2, etc. As is, a lot of the code is on exception handling and cleanup in the case something goes wrong in one thread. Having a high level interface that would state “run this using threads, and if something goes wrong terminate all involved threads” could simplify writing concurrent algorithms and make them more robust in handling exceptions.