'clock clicks per ms' differs remarkably per build (on Windows)

52 views
Skip to first unread message

Erik Leunissen

unread,
Jul 17, 2021, 7:56:04 AMJul 17
to
On my Windows 7 system, this proc:

proc ccpms {} {
set t0 [clock clicks]
after 1000
return [expr {([clock clicks] - $t0)/1000.0}]
}

returns a consistent result of around 1000 (give or take some ten clicks) on all my instances of
tclsh that originate from ActiveTcl (8.5 and 8.6, both 32bit and 64bit).

However, when executed with self built instances of tclsh, cross compiled from Linux using gcc,
(8.6.11, 8.7a4, all 64bit), the result is consistent around 1850 (give or take a few).

I have trouble understanding this duality, on one and the same machine.

Does anyone have an explanation?

Thanks in advance,
Erik Leunissen
--
elns@ nl | Merge the left part of these two lines into one,
xs4all. | respecting a character's position in a line.

Erik Leunissen

unread,
Jul 17, 2021, 8:38:04 AMJul 17
to
... unrelated the issue but:

of course *ms* needs be *s* everywhere.

Robert Heller

unread,
Jul 17, 2021, 10:40:27 AMJul 17
to
At Sat, 17 Jul 2021 13:54:16 +0200 Erik Leunissen <lo...@the.footer.invalid> wrote:

>
> On my Windows 7 system, this proc:
>
> proc ccpms {} {
> set t0 [clock clicks]
> after 1000
> return [expr {([clock clicks] - $t0)/1000.0}]
> }
>
> returns a consistent result of around 1000 (give or take some ten clicks) on all my instances of
> tclsh that originate from ActiveTcl (8.5 and 8.6, both 32bit and 64bit).
>
> However, when executed with self built instances of tclsh, cross compiled from Linux using gcc,
> (8.6.11, 8.7a4, all 64bit), the result is consistent around 1850 (give or take a few).
>
> I have trouble understanding this duality, on one and the same machine.
>
> Does anyone have an explanation?
>
> Thanks in advance,
> Erik Leunissen

gollum% tclsh
% proc ccpms {} {
set t0 [clock clicks]
after 1000
return [expr {([clock clicks] - $t0)/1000.0}]
}
% ccpms
1001.292
% set tcl_patchLevel
8.6.8
% parray tcl_platform
tcl_platform(byteOrder) = littleEndian
tcl_platform(engine) = Tcl
tcl_platform(machine) = x86_64
tcl_platform(os) = Linux
tcl_platform(osVersion) = 4.15.0-147-generic
tcl_platform(pathSeparator) = :
tcl_platform(platform) = unix
tcl_platform(pointerSize) = 8
tcl_platform(threaded) = 1
tcl_platform(user) = heller
tcl_platform(wordSize) = 8
% heller has logged on pts/2 from :0 at 17-Jul-2021 10:32.
gollum% uname -a
Linux gollum 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021
x86_64 x86_64 x86_64 GNU/Linux
gollum% cat /etc/is
issue issue.net
gollum% cat /etc/issue
Ubuntu 18.04.5 LTS \n \l



--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

Robert Heller

unread,
Jul 17, 2021, 10:40:29 AMJul 17
to
At Sat, 17 Jul 2021 13:54:16 +0200 Erik Leunissen <lo...@the.footer.invalid> wrote:

>
> On my Windows 7 system, this proc:
>
> proc ccpms {} {
> set t0 [clock clicks]
> after 1000
> return [expr {([clock clicks] - $t0)/1000.0}]
> }
>
> returns a consistent result of around 1000 (give or take some ten clicks) on all my instances of
> tclsh that originate from ActiveTcl (8.5 and 8.6, both 32bit and 64bit).
>
> However, when executed with self built instances of tclsh, cross compiled from Linux using gcc,
> (8.6.11, 8.7a4, all 64bit), the result is consistent around 1850 (give or take a few).
>
> I have trouble understanding this duality, on one and the same machine.

Is Linux running in a VM or is this machine dual booting?

If a VM what Virtualization system are you using.

In my other message I am running Ubuntu 18.04 *on the bare metal* on an older
Lenovo laptop.

>
> Does anyone have an explanation?
>
> Thanks in advance,
> Erik Leunissen

--

Robert Heller

unread,
Jul 17, 2021, 10:40:29 AMJul 17
to
At Sat, 17 Jul 2021 13:54:16 +0200 Erik Leunissen <lo...@the.footer.invalid> wrote:

>
> On my Windows 7 system, this proc:
>
> proc ccpms {} {
> set t0 [clock clicks]
> after 1000
> return [expr {([clock clicks] - $t0)/1000.0}]
> }
>
> returns a consistent result of around 1000 (give or take some ten clicks) on all my instances of
> tclsh that originate from ActiveTcl (8.5 and 8.6, both 32bit and 64bit).
>
> However, when executed with self built instances of tclsh, cross compiled from Linux using gcc,
> (8.6.11, 8.7a4, all 64bit), the result is consistent around 1850 (give or take a few).
>
> I have trouble understanding this duality, on one and the same machine.
>
> Does anyone have an explanation?
>
> Thanks in advance,
> Erik Leunissen

On a Pi4:

fruitloops% cat /etc/issue
Raspbian GNU/Linux 10 \n \l

fruitloops% tclsh
% set tcl_patchLevel
8.6.9
% proc ccpms {} {
set t0 [clock clicks]
after 1000
return [expr {([clock clicks] - $t0)/1000.0}]
}
% ccpms
1001.156
% fruitloops%

Erik Leunissen

unread,
Jul 17, 2021, 11:56:04 AMJul 17
to
On 17/07/2021 16:40, Robert Heller wrote:
>
> Is Linux running in a VM or is this machine dual booting?
>

Thanks for responding Robert,

but I'm afraid you seem to have misunderstood:

All observations were done when running tclsh under Windows 7 (no VM playing a role b.t.w.).

The duality comes from using two different types of binary:
- built by ActiveState, result is consistently +/- 1000)
- built by myself (cross compiled from Linux using gcc), result is consistently around 1850.

(But good to know that, just as here, when running under Linux, all your results correspond with
mine: no duality, and consistently returning around 1000).

Erik.
--

> If a VM what Virtualization system are you using.
>
> In my other message I am running Ubuntu 18.04 *on the bare metal* on an older
> Lenovo laptop.
>
>>
>> Does anyone have an explanation?
>>
>> Thanks in advance,
>> Erik Leunissen
>


--

Erik Leunissen

unread,
Jul 17, 2021, 12:04:52 PMJul 17
to
On 17/07/2021 17:53, Erik Leunissen wrote:
>
> but I'm afraid you seem to have misunderstood:
>

I now see that the title of the message could be understood in the way you did.
I'm sorry.

Erik.
--

Paul Obermeier

unread,
Jul 17, 2021, 2:35:38 PMJul 17
to
On my system (Windows 8, gcc compiled Tcl 8.6.11, 8.7.a5) I get a value of 2350.
If I change "clock clicks" to "clock microseconds" I get a consistent value of 1000.

From the clock manpage:
In addition, there is a clock clicks command that returns a platform-dependent high-resolution timer. Unlike clock seconds and clock milliseconds, the value of clock clicks is not guaranteed to be tied to any fixed epoch; it is simply intended to be the most precise interval timer available, and is intended only for relative timing studies such as benchmarks.

So it seems, that the ActiveState binaries have some modification, which changes the behaviour of "clock clicks" to "clock microseconds".

Regards,
Paul

EL

unread,
Jul 17, 2021, 3:22:05 PMJul 17
to
On 17.07.2021 20:35, Paul Obermeier wrote:

> So it seems, that the ActiveState binaries have some modification, which
> changes the behaviour of "clock clicks" to "clock microseconds".

Why should they do this? AFAIK they just create binary distributions
from the sources.


--
EL

Robert Heller

unread,
Jul 17, 2021, 3:54:13 PMJul 17
to
From the clock man page:

clock clicks ?-option?
If no -option argument is supplied, returns a high-resolution
time value as a system-dependent integer value. The unit of the
value is system-dependent but should be the highest resolution
clock available on the system such as a CPU cycle counter. See
HIGH RESOLUTION TIMERS for a full description.

If the -option argument is -milliseconds, then the command is
synonymous with clock milliseconds (see below). This usage is
obsolete, and clock milliseconds is to be considered the preâ€
ferred way of obtaining a count of milliseconds.

If the -option argument is -microseconds, then the command is
synonymous with clock microseconds (see below). This usage is
obsolete, and clock microseconds is to be considered the preâ€
ferred way of obtaining a count of microseconds.

[clock clicks] != [clock milliseconds], at least under MS-Windows. Under
Linux they appear to be interchangable.


At Sat, 17 Jul 2021 20:35:32 +0200 Paul Obermeier <ober...@poSoft.de> wrote:

>
> On my system (Windows 8, gcc compiled Tcl 8.6.11, 8.7.a5) I get a value of 2350.
> If I change "clock clicks" to "clock microseconds" I get a consistent value of 1000.
>
> From the clock manpage:
> In addition, there is a clock clicks command that returns a platform-dependent high-resolution timer. Unlike clock seconds and clock milliseconds, the value of clock clicks is not guaranteed to be tied to any fixed epoch; it is simply intended to be the most precise interval timer available, and is intended only for relative timing studies such as benchmarks.
>
> So it seems, that the ActiveState binaries have some modification, which changes the behaviour of "clock clicks" to "clock microseconds".
>
> Regards,
> Paul
>
> Am 17.07.2021 um 13:54 schrieb Erik Leunissen:
> > On my Windows 7 system, this proc:
> >
> > proc ccpms {} {
> >     set t0 [clock clicks]
> >     after 1000
> >     return [expr {([clock clicks] - $t0)/1000.0}]
> > }
> >
> > returns a consistent result of around 1000 (give or take some ten clicks) on all my instances of tclsh that originate from ActiveTcl (8.5 and 8.6, both 32bit and 64bit).
> >
> > However, when executed with self built instances of tclsh, cross compiled from Linux using gcc, (8.6.11, 8.7a4, all 64bit), the result is consistent around 1850 (give or take a few).
> >
> > I have trouble understanding this duality, on one and the same machine.
> >
> > Does anyone have an explanation?
> >
> > Thanks in advance,
> > Erik Leunissen
>
>

Erik Leunissen

unread,
Jul 17, 2021, 5:10:05 PMJul 17
to
On 17/07/2021 21:54, Robert Heller wrote:
> From the clock man page:
>
> clock clicks ?-option?
> If no -option argument is supplied, returns a high-resolution
> time value as a system-dependent integer value. The unit of the
> value is system-dependent but should be the highest resolution
> clock available on the system such as a CPU cycle counter. See
> HIGH RESOLUTION TIMERS for a full description.
>

Right.

Before reading this man page text, I understood a click-interval to be a hardware-construct, that
cannot be altered by software (like a cpu-cycle). That's one interpretation of the above, if
"system" corresponds to "platform" or cpu-os combination.

What does "system" in "system-dependent" mean? Also from the same man page:

HIGH RESOLUTION TIMERS

<snip> ... In addition, there is a clock clicks command that returns a
platform-dependent high-resolution timer.
^^^^^^^^^^^^^^^^^^

This explanation appears to exclude that a click-interval varies with system *load*, but also that
it varies with the compiler used to build software (given a specific combination of cpu-os), like I
experience.

I wonder whether the click interval for an optimized binary shows a difference when compared to
non-optimized (on the same cpu-os combination).

I'm going to investigate that. To be continued ...

I'm curious after Tcl users that can also compare the click-interval between binaries that originate
from different compilers.

Erik.
--


> If the -option argument is -milliseconds, then the command is
> synonymous with clock milliseconds (see below). This usage is
> obsolete, and clock milliseconds is to be considered the preâ€Â
> ferred way of obtaining a count of milliseconds.
>
> If the -option argument is -microseconds, then the command is
> synonymous with clock microseconds (see below). This usage is
> obsolete, and clock microseconds is to be considered the preâ€Â
> ferred way of obtaining a count of microseconds.
>
> [clock clicks] != [clock milliseconds], at least under MS-Windows. Under
> Linux they appear to be interchangable.
>
>
> At Sat, 17 Jul 2021 20:35:32 +0200 Paul Obermeier <ober...@poSoft.de> wrote:
>
>>
>> On my system (Windows 8, gcc compiled Tcl 8.6.11, 8.7.a5) I get a value of 2350.
>> If I change "clock clicks" to "clock microseconds" I get a consistent value of 1000.
>>
>> From the clock manpage:
>> In addition, there is a clock clicks command that returns a platform-dependent high-resolution timer. Unlike clock seconds and clock milliseconds, the value of clock clicks is not guaranteed to be tied to any fixed epoch; it is simply intended to be the most precise interval timer available, and is intended only for relative timing studies such as benchmarks.
>>
>> So it seems, that the ActiveState binaries have some modification, which changes the behaviour of "clock clicks" to "clock microseconds".
>>
>> Regards,
>> Paul
>>
>> Am 17.07.2021 um 13:54 schrieb Erik Leunissen:
>> > On my Windows 7 system, this proc:
>> >
>> > proc ccpms {} {
>> >     set t0 [clock clicks]
>> >     after 1000
>> >     return [expr {([clock clicks] - $t0)/1000.0}]
>> > }
>> >
>> > returns a consistent result of around 1000 (give or take some ten clicks) on all my instances of tclsh that originate from ActiveTcl (8.5 and 8.6, both 32bit and 64bit).
>> >
>> > However, when executed with self built instances of tclsh, cross compiled from Linux using gcc, (8.6.11, 8.7a4, all 64bit), the result is consistent around 1850 (give or take a few).
>> >
>> > I have trouble understanding this duality, on one and the same machine.
>> >
>> > Does anyone have an explanation?
>> >
>> > Thanks in advance,
>> > Erik Leunissen
>>
>>
>


--

Erik Leunissen

unread,
Jul 17, 2021, 5:24:04 PMJul 17
to
On 17/07/2021 23:08, Erik Leunissen wrote:
>
> I wonder whether the click interval for an optimized binary shows a difference when compared to
> non-optimized (on the same cpu-os combination).
>

No, it's not both the optimized and non-optimized gcc binary return 1840 clicks per ms.

Mysterious.

Paul's explanation could be true, but that would be very surprising (and mysterious in another way).

Erik.
--

Erik Leunissen

unread,
Jul 17, 2021, 5:44:04 PMJul 17
to
On 17/07/2021 19:10, EL wrote:
> Erik Leunissen <lo...@the.footer.invalid> wrote:
>
>> The duality comes from using two different types of binary:
>> - built by ActiveState, result is consistently +/- 1000)
>> - built by myself (cross compiled from Linux using gcc), result is
>> consistently around 1850.
>
> Probably it has to do with the way in which the cross compiler creates
> binaries.
>

In what direction would a binary that executes faster affect the result of "ccpms" according to you?

Would it increase or decrease the result of "ccpms"?

Erik
--

> Even when using gcc on windows, the binaries are different from the ones
> built with MSVC - different sizes and execution speed. When I compared this
> the last time, the gcc binaries were always larger (factor 2-3) and slower
> than the MSVC binaries. However, this was some 12-15 years ago and I didn’t
> do concrete benchmarks. I don’t know whether this observation would be
> different today, because I for my part just use MSVC since several years.

Erik Leunissen

unread,
Jul 17, 2021, 5:58:05 PMJul 17
to
On 17/07/2021 23:22, Erik Leunissen wrote:
>
> No, it's not both the optimized and non-optimized gcc binary return 1840 clicks per ms.
>

Ah, and that's logical: [after 1000] just returns after 1000 ms, but otherwise it doesn't really
execute anything, let alone "execute nothing faster" ;-)
It just lets the cpu-cycles pass by.

Erik.

Robert Heller

unread,
Jul 17, 2021, 6:04:16 PMJul 17
to
At Sat, 17 Jul 2021 23:08:40 +0200 Erik Leunissen <lo...@the.footer.invalid> wrote:

>
> On 17/07/2021 21:54, Robert Heller wrote:
> > From the clock man page:
> >
> > clock clicks ?-option?
> > If no -option argument is supplied, returns a high-resolution
> > time value as a system-dependent integer value. The unit of the
> > value is system-dependent but should be the highest resolution
> > clock available on the system such as a CPU cycle counter. See
> > HIGH RESOLUTION TIMERS for a full description.
> >
>
> Right.
>
> Before reading this man page text, I understood a click-interval to be a hardware-construct, that
> cannot be altered by software (like a cpu-cycle). That's one interpretation of the above, if
> "system" corresponds to "platform" or cpu-os combination.
>
> What does "system" in "system-dependent" mean? Also from the same man page:
>

"system" means Operating System. "system-dependent" means Operating System
dependent.

Basicly it means that "clock clicks" is not cross-platform portable and what
is returned cannot be depended to be the same for different builds on
different systems. If you want the same behavior on different systems, then
use "clock milliseconds", which always returns milliseconds for all platforms
and all combinations of builds.

> HIGH RESOLUTION TIMERS
>
> <snip> ... In addition, there is a clock clicks command that returns a
> platform-dependent high-resolution timer.
> ^^^^^^^^^^^^^^^^^^
>
> This explanation appears to exclude that a click-interval varies with system *load*, but also that
> it varies with the compiler used to build software (given a specific combination of cpu-os), like I
> experience.
>
> I wonder whether the click interval for an optimized binary shows a difference when compared to
> non-optimized (on the same cpu-os combination).
>
> I'm going to investigate that. To be continued ...
>
> I'm curious after Tcl users that can also compare the click-interval between binaries that originate
> from different compilers.
>
> Erik.
> --
>
>
> > If the -option argument is -milliseconds, then the command is
> > synonymous with clock milliseconds (see below). This usage is
> > obsolete, and clock milliseconds is to be considered the preâ€ÂÂ
> > ferred way of obtaining a count of milliseconds.
> >
> > If the -option argument is -microseconds, then the command is
> > synonymous with clock microseconds (see below). This usage is
> > obsolete, and clock microseconds is to be considered the preâ€ÂÂ
> > ferred way of obtaining a count of microseconds.
> >
> > [clock clicks] != [clock milliseconds], at least under MS-Windows. Under
> > Linux they appear to be interchangable.
> >
> >
> > At Sat, 17 Jul 2021 20:35:32 +0200 Paul Obermeier <ober...@poSoft.de> wrote:
> >
> >>
> >> On my system (Windows 8, gcc compiled Tcl 8.6.11, 8.7.a5) I get a value of 2350.
> >> If I change "clock clicks" to "clock microseconds" I get a consistent value of 1000.
> >>
> >> From the clock manpage:
> >> In addition, there is a clock clicks command that returns a platform-dependent high-resolution timer. Unlike clock seconds and clock milliseconds, the value of clock clicks is not guaranteed to be tied to any fixed epoch; it is simply intended to be the most precise interval timer available, and is intended only for relative timing studies such as benchmarks.
> >>
> >> So it seems, that the ActiveState binaries have some modification, which changes the behaviour of "clock clicks" to "clock microseconds".
> >>
> >> Regards,
> >> Paul
> >>
> >> Am 17.07.2021 um 13:54 schrieb Erik Leunissen:
> >> > On my Windows 7 system, this proc:
> >> >
> >> > proc ccpms {} {
> >> >     set t0 [clock clicks]
> >> >     after 1000
> >> >     return [expr {([clock clicks] - $t0)/1000.0}]
> >> > }
> >> >
> >> > returns a consistent result of around 1000 (give or take some ten clicks) on all my instances of tclsh that originate from ActiveTcl (8.5 and 8.6, both 32bit and 64bit).
> >> >
> >> > However, when executed with self built instances of tclsh, cross compiled from Linux using gcc, (8.6.11, 8.7a4, all 64bit), the result is consistent around 1850 (give or take a few).
> >> >
> >> > I have trouble understanding this duality, on one and the same machine.
> >> >
> >> > Does anyone have an explanation?
> >> >
> >> > Thanks in advance,
> >> > Erik Leunissen
> >>
> >>
> >
>
>

--

Christian Gollwitzer

unread,
Jul 17, 2021, 6:28:57 PMJul 17
to
Am 17.07.21 um 13:54 schrieb Erik Leunissen:
> On my Windows 7 system, this proc:
>
> proc ccpms {} {
>     set t0 [clock clicks]
>     after 1000
>     return [expr {([clock clicks] - $t0)/1000.0}]
> }
>
> returns a consistent result of around 1000 (give or take some ten
> clicks) on all my instances of tclsh that originate from ActiveTcl (8.5
> and 8.6, both 32bit and 64bit).
>
> However, when executed with self built instances of tclsh, cross
> compiled from Linux using gcc, (8.6.11, 8.7a4, all 64bit), the result is
> consistent around 1850 (give or take a few).

Also check out TIP 7: https://core.tcl-lang.org/tips/doc/trunk/tip/7.md
It explains how the timing resolution on Window was improved by the High
Performance Counter. This counter runs at CPU clock speed and is usually
used to benchmark tight loops in high performance code down to the cache
level.

As pointed out by others, the tick speed of "clock clicks" is not
system-defined - in contrast, "clock milliseconds" and "clock
microseconds" are guaranteed to return the result in wallclock time. So
I wouldn't use "clock clicks", it is not that useful, unless you want to
debug the clock code or suspect rounding of the time to some imprecise
base. As long as "after" waits for the correct amount of time and "clock
milliseconds" is in agreement, there is no bug.

Christian

Erik Leunissen

unread,
Jul 17, 2021, 6:30:04 PMJul 17
to
On 17/07/2021 23:08, Erik Leunissen wrote:
>
> I'm curious after Tcl users that can also compare the click-interval between binaries that originate
> from different compilers.
>

I can readily provide 64 bit windows binaries of tcl86.dll (any patchlevel from 8.6.6 to 8.6.11)
built with gcc, for anyone prepared to compare with the corresponding binary built with another
compiler.

You would need to replace your copy of the dll and run the proc ccpms.

Just say the word ...
Erik.
--

Rich

unread,
Jul 17, 2021, 11:48:34 PMJul 17
to
Erik Leunissen <lo...@the.footer.invalid> wrote:
> On my Windows 7 system, this proc:
>
> proc ccpms {} {
> set t0 [clock clicks]
> after 1000
> return [expr {([clock clicks] - $t0)/1000.0}]
> }
>
> returns a consistent result of around 1000 (give or take some ten
> clicks) on all my instances of tclsh that originate from ActiveTcl
> (8.5 and 8.6, both 32bit and 64bit).
>
> However, when executed with self built instances of tclsh, cross
> compiled from Linux using gcc, (8.6.11, 8.7a4, all 64bit), the result
> is consistent around 1850 (give or take a few).
>
> I have trouble understanding this duality, on one and the same machine.
>
> Does anyone have an explanation?

One possible explanation could be the two different compilers [1]
utilizing two different windows "get high-resolution timer" API's that
have different 'clicks' resolution. Given the differences, it would
appear that the Linux compiler is using an API that 'ticks' faster than
the API that ActiveState's compiler used.





[1] I'm assuming here that the ActiveState binaries were likely not
compiled with the same compiler revision you used on Linux. This seems
like a safe assumption to make.

EL

unread,
Jul 18, 2021, 2:22:05 AMJul 18
to
On 18.07.2021 05:48, Rich wrote:

> [1] I'm assuming here that the ActiveState binaries were likely not
> compiled with the same compiler revision you used on Linux. This seems
> like a safe assumption to make.

AFAIK the ActiveState binaries are generated with MSVC.


--
EL

Erik Leunissen

unread,
Jul 18, 2021, 5:32:04 AMJul 18
to
On 18/07/2021 00:28, Christian Gollwitzer wrote:
>
> Also check out TIP 7: https://core.tcl-lang.org/tips/doc/trunk/tip/7.md
> It explains how the timing resolution on Window was improved by the High Performance Counter. This
> counter runs at CPU clock speed and is usually used to benchmark tight loops in high performance
> code down to the cache level.

Thanks, highly interesting in this respect.

>
> As pointed out by others, the tick speed of "clock clicks" is not system-defined

You mean the opposite: "is system-specific" ?


- in contrast,
> "clock milliseconds" and "clock microseconds" are guaranteed to return the result in wallclock time.
> So I wouldn't use "clock clicks", it is not that useful, unless you want to debug the clock code or
> suspect rounding of the time to some imprecise base.

This is not about a selection of use cases, based on a usefulness, not even conditionally ("unless
...").

I'm simply observing something that questions the correct functioning of [clock clicks] per se,
under the circumstances reported.

Therefore, all intended use cases are relevant (especially including those that you deem useful
after your selection).

As long as "after" waits for the correct amount
> of time and "clock milliseconds" is in agreement, there is no bug.

Maybe, based on your selective understanding of usefulness.


>
>     Christian

Erik Leunissen

unread,
Jul 18, 2021, 7:52:05 AMJul 18
to
On 18/07/2021 05:48, Rich wrote:
>
> One possible explanation could be the two different compilers [1]
> utilizing two different windows "get high-resolution timer" API's that
> have different 'clicks' resolution. Given the differences, it would
> appear that the Linux compiler is using an API that 'ticks' faster than
> the API that ActiveState's compiler used.
>

I did a cursory inspection of the C sources regarding "clock clicks" to see whether I could quickly
identify compiler-dependent switches (like preprocessor directives of the kind #ifdef _MSC_VER).

I didn't find any that I believe to explain what I observe.

However, as I said, the inspection is cursory, and I've reached a level where the effort is going to
exceed the need for understanding.

Erik.

>
>
>
>
> [1] I'm assuming here that the ActiveState binaries were likely not
> compiled with the same compiler revision you used on Linux. This seems
> like a safe assumption to make.
>


Rich

unread,
Jul 18, 2021, 9:15:44 AMJul 18
to
Erik Leunissen <lo...@the.footer.invalid> wrote:
> On 18/07/2021 05:48, Rich wrote:
>>
>> One possible explanation could be the two different compilers [1]
>> utilizing two different windows "get high-resolution timer" API's
>> that have different 'clicks' resolution. Given the differences, it
>> would appear that the Linux compiler is using an API that 'ticks'
>> faster than the API that ActiveState's compiler used.
>
> I did a cursory inspection of the C sources regarding "clock clicks"
> to see whether I could quickly identify compiler-dependent switches
> (like preprocessor directives of the kind #ifdef _MSC_VER).
>
> I didn't find any that I believe to explain what I observe.

The difference does not have to be explosed as a define at the C level.
The C code could be calling a single function named
Windows_get_hires_time() but the libc used by MSVC implements
"Windows_get_hires_time()" by using a different low level kernel call
than the implementation in the libc used by your cross compiler.

The C code would be identical, but the results of compiling, and
linking to the compiler's respective libc's, would call different low
level windows kernel entry points.

Remember the disclaimer in the manpage, the value returned by 'clicks'
does not have any relationship to 'wall time', and the value returned
is "system-dependent". "System-dependent" here would also include
"which low level kernel call to use to get this value is our choice as
well".

Christian Gollwitzer

unread,
Jul 18, 2021, 2:23:39 PMJul 18
to
Am 18.07.21 um 11:31 schrieb Erik Leunissen:
> On 18/07/2021 00:28, Christian Gollwitzer wrote:
>>
>> Also check out TIP 7: https://core.tcl-lang.org/tips/doc/trunk/tip/7.md
>> It explains how the timing resolution on Window was improved by the
>> High Performance Counter. This counter runs at CPU clock speed and is
>> usually used to benchmark tight loops in high performance code down to
>> the cache level.
>
> Thanks, highly interesting in this respect.
>
>>
>> As pointed out by others, the tick speed of "clock clicks" is not
>> system-defined
>
> You mean the opposite: "is system-specific" ?

yes of course

> - in contrast,
>> "clock milliseconds" and "clock microseconds" are guaranteed to return
>> the result in wallclock time. So I wouldn't use "clock clicks", it is
>> not that useful, unless you want to debug the clock code or suspect
>> rounding of the time to some imprecise base.
>
> This is not about a selection of use cases, based on a usefulness, not
> even conditionally ("unless ...").

Maybe I was a bit harsh with the wording that "clock clicks" is not that
useful. I was trying to say that the tick speed of "clock clicks" is
unspecified, that it is known and not a bug. If you need to know the
tick speed of the clock, there are alternatives invented exactly for
this purpose. See also TIP 209 and TIP 124

https://core.tcl-lang.org/tips/doc/trunk/tip/124.md
https://core.tcl-lang.org/tips/doc/trunk/tip/209.md


> I'm simply observing something that questions the correct functioning of
> [clock clicks] per se, under the circumstances reported.

I wouldn't have expected that the compiler has an influence on the tick
speed myself; however I do not agree with your conclusion that this
questions the functioning of clock clicks. It merely shows that, as
documented in multiple sources, you can't use clock clicks to measure
time in seconds directly. Which is no problem in the end, since there
are simple alternatives.

Christian


Christian

Erik Leunissen

unread,
Jul 19, 2021, 3:36:04 AMJul 19
to
On 18/07/2021 15:15, Rich wrote:
>
> The difference does not have to be explosed as a define at the C level.
> The C code could be calling a single function named
> Windows_get_hires_time() but the libc used by MSVC implements
> "Windows_get_hires_time()" by using a different low level kernel call
> than the implementation in the libc used by your cross compiler.
>
> The C code would be identical, but the results of compiling, and
> linking to the compiler's respective libc's, would call different low
> level windows kernel entry points.
>

Thanks for pointing this out.
Erik.


> Remember the disclaimer in the manpage, the value returned by 'clicks'
> does not have any relationship to 'wall time', and the value returned
> is "system-dependent". "System-dependent" here would also include
> "which low level kernel call to use to get this value is our choice as
> well".
>


Erik Leunissen

unread,
Jul 19, 2021, 3:49:26 AMJul 19
to
On 18/07/2021 20:23, Christian Gollwitzer wrote:
>
> I wouldn't have expected that the compiler has an influence on the tick speed myself; however I do
> not agree with your conclusion that this questions the functioning of clock clicks.

Well it made me question whether something was wrong (with my cross-compiled copy of tclsh) when
doing [clock clicks], because there was no ready explanation for the observation.

I'm now convinced that that needn't be the case, and that the difference may be caused by a
different libc, like Rich explained in another post, something which is included in the reservation
made by "system-dependent".

So I stop questioning now.

Thanks for your contribution.
Erik.

It merely shows
> that, as documented in multiple sources, you can't use clock clicks to measure time in seconds
> directly. Which is no problem in the end, since there are simple alternatives.
>
>     Christian
>
>
>     Christian


Reply all
Reply to author
Forward
0 new messages