Tcl Source Code

Hello out there,
I think that 'clock microseconds' is broken under Windows.

There was recently a thread on clt
    clock microseconds with resolution in milliseconds
which stated that you only ever get a millisecond resolution - that is you get values like 1273904070156000 or 1273904072243000 but never any value other than '000' in the 3 low order digits.

I could verify this on my Intel Core 2 Duo machine - and it really surprised me, because in the past I had been using 'clock microseconds' to get detailed timing information - just not on this machine. Why did Tcl lose the useful capability?

I had a look at the sources and I am near to certain to have found the culprit: NativeGetTime (tclWinTime.c) is broken.

Analysis:
On its first invocation NativeGetTime checks via QueryPerformanceFrequency whether a performance counter exists - so far, so good.
However, if its frequency is > 15 MHz (and on my machine it is 2.5 GHz) it enters a complex test which can result in declaring the performance counter as 'not available', and this test is "out of date":
a) In its first part it only accepts 'GenuineIntel' - very bad for AMD chips.
b) In its second part it seems to not be 'up to date': Apparently Intel has defined different values for newer cores which this test does not check - hence the failure on newer machines.

Possible solutions:
a) Get rid of this second test.
What is the scenario where it makes sense to declare the performance counter to not be available, even if Windows has just told us the opposite?
b) If we need to keep it, it needs to be brought up to date:
- Accept other CPUs than Intel only, and
- for each core of the different vendors get the tests right

I attach a C file which which is self-contained and which shows the relevant information (frequency and register values) - this may make it easier to get or verify the details for different cores.
If there is a reason to go route (b) I could put this file on the wiki and we could ask people on clt to support this issue by running it on all possible cores (that's the reason it is self-contained and does not need Tcl's sources to compile - hopefully makes it a bit easier).

Still, the easiest way would be to just drop the second test.
Best regards
Helmut Giese

Well,
sorry for raising a non-issue.
Maybe one could add a comment on clock's man page like:
- Where it says
      "See HIGH RESOLUTION TIMERS"
   (in 'clock clicks/millisecond/microsecond') extend it to read 
       "See HIGH RESOLUTION TIMERS - potential LIMITATION on Windows"
- and in the actual section for "HIGH RESOLUTION TIMERS" append something like
  On multi-core machines running Windows it may be necessary to relinquish the use of the high-resultion timer. In this case the aforementioned commands are limited to millisecond resolution.

Sorry for the noise and best regards
Helmut Giese

The scenario that causes the problem is that QueryPerformanceCounter returns different values on different cores. And that scenario is still with us. Microsoft warns that "bugs in the HAL" may cause such behaviour and suggests that any code that uses QueryPerformanceCounter set a thread affinitiy mask to run single-core. What they don't say is that the "bug" is universal - I have yet to find multichip systems where QueryPerformanceCounter returns consistent results, and even some single-chip multicore systems seem to get out of sync.

I'm really at a loss what to do with this one. We seem to be faced with a choice between restricting a Tcl process to a single core in order to get robust timing, or else giving up on submillisecond resolution. The manufacturers of Windows machines simply do not care about this problem.

File Added - 373971: perfcounter.c