GetTickCount has been deprecated in favor of GetTickCount64, which gives a qword result and so it "solves" the wrap-arount to 0 of the tick after 49.7 days, so one doesn't have to worry that the expression

GetTickCount64-PreviousTick

will ever give a negative result, and

   if GetTickCount64-PreviousTick>WaitTime then

is guaranteed to work for the next ~500 millions years.

However GetTickCount64 isn't available in windows XP, so the rtl simulates it by using.....GetTickCount, with the result that the above "if" condition could fail after 49.7 days.
For that I still have to use DWORDs instead of qwords and cast the subtraction to DWORD (so that the rollback doesn't matter as long as the WaitTime above is less than $ffffffff)

BEFORE (with gettickcount):

----------------------------------------------------------------------
var PreviousTick:DWORD;

...

   PreviousTick:=GetTickCount;

...
... if DWORD(GetTickCount-PreviousTick)>WaitTime then.... ----------------------------------------------------------------------

NOW (with gettickcount64)

---------------------------------------------------------------------- var PreviousTick:QWORD;
...

   PreviousTick:=GetTickCount64;

...
... if GetTickCount64-PreviousTick>WaitTime then.... ----------------------------------------------------------------------

Which seems cleaner but isn't really guaranteed to work, so I have to:

---------------------------------------------------------------------- var PreviousTick:DWORD;
...

   PreviousTick:=DWORD(GetTickCount64);

...
... if DWORD(DWORD(GetTickCount64)-PreviousTick)>WaitTime then.... ----------------------------------------------------------------------

wouldn't have been better to just leave GetTickCount alone, without deprecation (and maybe give a warning that GetTickCount64 doesn't give a usable result on all platforms)?

Bye

El 11/04/18 a les 10:06, Luca Olivetti ha escrit:

BTW, the DWORD typecast is only necessary with fpc, the following program gives 4 and 4 if compiled with delphi 2, 4 and -4294967292 if compiled with fpc 3.0.4

program project1;
uses
   windows;
var t1,t2,t3:dword;
begin
   t1:=$fffffffe;
   t2:=2;
   t3:=t2-t1;
   writeln(t3);
   writeln(t2-t1);
end.

Hello,

personally I use this 64 bit emulation:

var CurrentIncrement:Int64=0;
      LastTickCount:Int64=0;
function TGGetTickCount64:Int64;
begin
  {$ifdef CPUX64}
  Result:=GetTickCount64;
  {$else}
  Result:=GetTickCount+CurrentIncrement;
  if Result<LastTickCount then begin
     Inc(Result,Int64($100000000));
     Inc(CurrentIncrement,Int64($100000000)); // only 99.999999% thread safe but good enough for me
     end;
  {$endif}
  LastTickCount:=Result;
  end;

Kind Regards,

Tobias Giesen

----

Kind Regards,
Tobias Giesen

Super Flexible Software Ltd. & Co. KG
Buddenstr. 29-31
48143 Münster, Germany
www.superflexible.com
www.tgtools.com

----------------------------------------------------------- Registered at register court Münster as HRA 9716
Liability / general partner: TGTools Ltd.
Company No. 05513299
Registered in England and Wales
Directors: Tobias Giesen and Claudia Giesen

Unfortunate is the obscure wording you find on the documentation:

https://www.freepascal.org/docs-html/rtl/sysutils/gettickcount.html

"Description
GetTickCount returns an increasing clock tick count. It is useful for time measurements, but no assumtions should be made as to the interval between the ticks. This function is provided for Delphi compatibility, use GetTickCount64 instead."

One would think that GetTickCount64 would clarify things about the interval between the ticks (just to be useful for time measurements) but: https://www.freepascal.org/docs-html/rtl/sysutils/gettickcount64.html

"Description
GetTickCount64 returns an increasing clock tick count. It is useful for time measurements, but no assumtions should be made as to the interval between the ticks."

How can it be useful for time measurements if we don't know the units?

Contrast to the Microsoft Documentation:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724408(v=vs.85).aspx

"Return value
The return value is the number of milliseconds that have elapsed since the system was started."

Of course, it is followed by some remarks about the real limitations but at least we have some idea on what to expect.

I know that, by being cross platform, GetTickCount64 can behave in different ways on other environments but, just because of that, the user should not be kept in the dark when using it.

I know that the documentation effort is hard and many times we don't appreciate the effort as we should, but please don't be so vague on this entry.

Paulo Costa

El 11/04/18 a les 13:59, Tobias Giesen ha escrit:

Hello, personally I use this 64 bit emulation:

For my purpose I'm perfectly happy with GetTickCount. I'd understand the deprecation if GetTickCount64 would be a reliable substitute. It isn't.

Bye

El 11/04/18 a les 15:40, Paulo Costa ha escrit:

Unfortunate is the obscure wording you find on the documentation: https://www.freepascal.org/docs-html/rtl/sysutils/gettickcount.html

Yes, you're right, but that's another issue.
When the documentation is vague and I need details I look at the implementation for the platforms I'm interested in. That's how I discovered that the GetTickCount64 emulation under Windows before version 6 should *not* be used (or used by limiting it to DWORD values, but then it's better to just use GetTickCount).

Bye

The documentation seems fine. I can use it to approximate that a minute has elapsed, or to keep track of frames per second for a game, but I'm not going to use it to control complex machinery.

The GetTickCount documentation offers that most system timers are within the 10 to 16 millisecond range. So if windows (internally) updates GetTickCount every millisecond, it's count might look like this from boot:

0000
0000
0000
0000
- 10 more times
0014
0014
0014
0014
0014
- maybe 9 more times
0027
0027
0027
0027
0027
- maybe 8 or 9 more times
0042

So in this example, if you want to time something to happen EXACTLY every 10 milliseconds, you'd miss 10ms by 4, 20ms by 7, and you'd skip 30ms.

This is why you do stuff like:

if (gettickcount - previous) > 10 then /* do something here */

A solution for the gettickcount overflow I liked was something like:

current:=gettickcount;
if (current >= previous) then
	elapsed:=current - previous
else
	elapsed:=(high(dword) - previous) + current;
previous:=current;
if (elapsed > ...)

Alex

Only on XP. On all other platforms, it is the better solution.

Michael.

This is related to something I meant to propose a while ago related to a cross platform timing and alarm API. I do not think GetTickCount should ever be used; instead, QueryPerformanceCounter makes more sense. It is higher resolution and still portable. The Linux function `clock_gettime` called with `CLOCK_REALTIME_HR` is more or less a direct equivalent.

Cheers,
R0b0t1

El 11/04/18 a les 18:42, Michael Van Canneyt ha escrit:

It depends. If you just want to keep track of intervals less than 49 days, GetTickCount is perfectly good (provided you cast the difference between the current tick and the previous one to dword) *and* it works on XP (which, unfortunately, I still have to support). I see no reason to deprecate it.

BTW, advancedipc.pp uses

   until (GetTickCount64-xStart > aTimeOut);

so it could hang if used in windows XP.

Bye

On Wed, April 11, 2018 18:44, R0b0t1 wrote:

.
.

No, it isn't portable (neither is GetTickCount, BTW) - there are many more targets supported by FPC than MS Windows and Linuxm

Tomas

Hi,

Actually... I kinda disklike this depreciation too. Better is just such a bad word for software engineering. (Almost) everything has its purpose.

GetTickCount is clearly a Windows API function, does not directly exist in Delphi itself, so this is an FPC addition to the Sysutils unit for Delphi-compatible platform idependence - and to my knowledge, Microsoft did not deprecate the 32bit variant, instead it documented that it rolls over after 49.7 days, which we could also do just fine.

Especially because extending the result to 64bit is *NOT* the only way to get around the 32bit overflow problem of a timer, and for a lot of purposes it's perfectly fine, especially on 32bit systems, which are still numerous.

Which means, the workaround for the deprecation message on Windows is actually using the GetTickCount from Windows unit directly, which is supported everywhere and even Delphi compatible (no GetTickCount/64 in sysutils there, according to the docs I can find, but fix me?).

BTW, for additional fun, the Windows RTL system unit itself still uses the 32bit Windows API GetTickCount to initialize its RandSeed...

Charlie

It's deprecated by Microsoft. If I had to guess, it's likely not going anywhere until 32bit binary support in Windows is long gone.

Should you use GetTickCount on any Windows system that supports (natively) GetTickCount64? NO, not in new code.

That's exactly what deprecated means.

IMO compiling code targeting Windows >= Vista that has GetTickCount in it is no good.

Alex

My apologies, I meant portable between Windows versions. Various high resolution timing facilities on Windows that are not QueryPerformanceCounter give wildly varying results based on many factors, usually hardware.

`clock_gettime` is supported by Linux and FreeBSD, which now includes recent macOS versions. If it is not supported, `gettimeofday` can be used instead at a lower resolution. There are also timing facilities based on events that are fairly uniform in interface construction. Keep in mind that newer timing functions tend to have a noticeable decrease in resource usage compared to newer ones. The event based timers are very nice because constant switches into libc are not necessary.

Cheers,
R0b0t1

Just to be clear, the 64 in GetTickCount64 has nothing to do with whether a machine is 32bit or 64bit.

Alex

El 11/04/18 a les 19:27, Alexander Grotewohl ha escrit:

It's deprecated by Microsoft.

It doesn't say anything about deprecation here

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724408(v=vs.85).aspx

Bye

Hi,

Alexander Grotewohl wrote

Just to be clear, the 64 in GetTickCount64 has nothing to do with whether a machine is 32bit or 64bit.

The call itself, doesn't. Except, on a 32bit machine, when you have to do 64bit arithmetic/value handling, it's usually less optimal/more instructions. In this case it's really minor, but still, on some platforms we support, it still counts.

Charlie

R0b0t1 wrote

This is related to something I meant to propose a while ago related to a cross platform timing and alarm API.

That already exists in the form of EpikTimer
(https://github.com/graemeg/epiktimer). That is the latest implementation with the permission of the original author.

It uses the highest resolution timer it can find on each platform, and GetTickCount/GetTickCount64 as a fall-back in case no higher resolution timer exists. High resolution timers exists for Windows, Linux and FreeBSD - that I know of. OSX might also be implemented.

Regards,
Graeme

Ah, finally !
I was waiting for epiktimer to pop up in the discussion...

Thank you, Graeme :-)

It uses the highest resolution timer it can find on each platform, and GetTickCount/GetTickCount64 as a fall-back

No, it doesn't. I just checked.

It uses clock_gettime if available on linux, otherwise it uses gettimeofday.

Maybe it used it at one point, but changed to a custom implementation to be able to switch to clock_time ahead of FPC.

Also, it uses a cardinal in the linux version, so it will also have the wrap-around problem:

// Build a 64 bit microsecond tick from the seconds and microsecond longints
Result := (TickType(t.tv_sec) * NanoPerMilli) + t.tv_usec;

"Build a 64-bit microsecond tick" when result is a Cardinal ? I don't think that can be right...

Note that TickType is a int64 (line 90 of the unit).

So, no use of systutils gettickcount, and a wrong implementation to boot...

I suggest fixing at least the bug.

Michael.

Michael Van Canneyt wrote

Ah, finally ! I was waiting for epiktimer to pop up in the discussion... Thank you, Graeme :-)

Not sure if that was meant as sarcastic or not. I mentioned EpikTimer, because it rolls most use cases into one easy to use class. Plus EpikTimer allows many other functionality too - like tracking multiple independent timers etc.

> It uses the highest resolution timer it can find on each platform, and > GetTickCount/GetTickCount64 as a fall-back No, it doesn't. I just checked.

Ah, I see now it has its own newGetTickCount() implementation - I guess the similar name threw me off.

Maybe it used it at one point, but changed to a custom implementation to be able to switch to clock_time ahead of FPC.

That sounds vaguely familiar, so you might be right.

I had a quick look in FPC 3.0.4 and I see FPC also uses clock_getTime(CLOCK_MONOTONIC). As you said, I guess the EpikTimer implementation predates FPC's GetTickCount64. But now that FPC has that, EpikTimer could most likely switch to using it, instead of its own implementation - at least for the relevant parts of EpikTimer.

I suggest fixing at least the bug.

I'll do that, thanks. I just noticed I have some local mods/improvements (done 1-2 years ago) and still haven't updated the Git repository either. I'll get those in promptly.

I think it would be good to delve into Java's System.nanoTime() implementation too, and see how that translates to various platforms. The nanoTime() frequency is really small - not 1 nanosecond, but still very small.

Regards,
Graeme

Ah, right - I think this is why I ultimately never did anything. Someone already completed it. Glad to hear it is still receiving updates!

Cheers,
R0b0t1