Re: 'clock microseconds' broken on Windows



Hi Helmut,

perhaps the solution we introduced in a non-tcl application for our
timing measurements is acceptable for tcl applications, too.

In the case, that we want our application to do profiling, the
application binds itself to one CPU core via ...

SetProcessAffinityMask(GetCurrentProcess(), 1)

Perhaps, the tcl core could be able to switch to one CPU core usage,
if "clock microseconds" is used the first time, to assure the
correctness of the returned times.

Best regards,

Martin

On 16 Mai, 21:10, Helmut Giese <hgi...@xxxxxxxxxxxxx> wrote:
I would like to correct the subject: It's not broken, it's by 'design
out of necessity'.
Background (for those interested in technical details): Each core has
a fast running 'performance counter' (aka 'high resolution timer'),
which is at the base of every attempt to get sub-millisecond
resolution.
The problem is that on multicore machines those timers can (and
apparently will) get out of sync. Since one cannot rely on always
executing on the same core getting the counter value introduces an
element of random: A value you get may (appear to) lie in the past -
or in a distant future.
It is for this reason that Tcl deliberately relinquishes use of this
timer if a 'safe environment' cannot be determined. So far nobody
seems to have found a satisfying solution.

A word of WARNING: If anybody wants to use the "work around" I posted:
Please be aware, that it is subject to the same problem: Sukzessive
calls need not be executed on the same core - hence may report values
from different timers - hence may produce surprising results.
Sigh, sorry for the bad news.
Helmut Giese

.