The unfortunate deprecation of GetTickCount

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

The unfortunate deprecation of GetTickCount

Luca Olivetti-2
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
--
Luca
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

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

>
> BEFORE (with gettickcount):
>
> ----------------------------------------------------------------------
> var PreviousTick:DWORD;
>
> ...
>    PreviousTick:=GetTickCount;
> ...
> ... if DWORD(GetTickCount-PreviousTick)>WaitTime then....


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.


--
Luca
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

tobiasgiesen
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

----

On Wed, 11 Apr 2018 12:25:16 +0200
Luca Olivetti <[hidden email]> wrote:

> El 11/04/18 a les 10:06, Luca Olivetti ha escrit:
> >
> > BEFORE (with gettickcount):
> >
> > ----------------------------------------------------------------------
> > var PreviousTick:DWORD;
> >
> > ...
> >    PreviousTick:=GetTickCount;
> > ...
> > ... if DWORD(GetTickCount-PreviousTick)>WaitTime then....
>
>
> 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.
>
>
> --
> Luca
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

Paulo Costa-2
In reply to this post by Luca Olivetti-2
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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

Luca Olivetti-2
In reply to this post by tobiasgiesen
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
--
Luca
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

Luca Olivetti-2
In reply to this post by Paulo Costa-2
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
--
Luca
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

Alexander Grotewohl
In reply to this post by Paulo Costa-2
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


On 04/11/2018 09:40 AM, Paulo Costa wrote:

> 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
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

Michael Van Canneyt
In reply to this post by Luca Olivetti-2


On Wed, 11 Apr 2018, Luca Olivetti wrote:

> 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.

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

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

R0b0t1
In reply to this post by Alexander Grotewohl
On Wed, Apr 11, 2018 at 11:26 AM, Alexander Grotewohl <[hidden email]> wrote:
> 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:
>

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

> 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
>
>
>
> On 04/11/2018 09:40 AM, Paulo Costa wrote:
>>
>> 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
>> _______________________________________________
>> fpc-pascal maillist  -  [hidden email]
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

Luca Olivetti-2
In reply to this post by Michael Van Canneyt
El 11/04/18 a les 18:42, Michael Van Canneyt ha escrit:

>
>
> On Wed, 11 Apr 2018, Luca Olivetti wrote:
>
>> 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.
>
> Only on XP. On all other platforms, it is the better solution.

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
--
Luca
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

Tomas Hajny-2
In reply to this post by R0b0t1
On Wed, April 11, 2018 18:44, R0b0t1 wrote:

 .
 .
> 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.

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

Tomas


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

Karoly Balogh (Charlie/SGR)
In reply to this post by Michael Van Canneyt
Hi,

On Wed, 11 Apr 2018, Michael Van Canneyt wrote:

> >> 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.
>
> Only on XP. On all other platforms, it is the better solution.

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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

Alexander Grotewohl
In reply to this post by Luca Olivetti-2
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


On 04/11/2018 12:57 PM, Luca Olivetti wrote:

> El 11/04/18 a les 18:42, Michael Van Canneyt ha escrit:
>>
>>
>> On Wed, 11 Apr 2018, Luca Olivetti wrote:
>>
>>> 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.
>>
>> Only on XP. On all other platforms, it is the better solution.
>
> 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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

R0b0t1
In reply to this post by Tomas Hajny-2
On Wed, Apr 11, 2018 at 12:11 PM, Tomas Hajny <[hidden email]> wrote:

> On Wed, April 11, 2018 18:44, R0b0t1 wrote:
>
>  .
>  .
>> 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.
>
> No, it isn't portable (neither is GetTickCount, BTW) - there are many more
> targets supported by FPC than MS Windows and Linuxm
>

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

> Tomas
>
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

Alexander Grotewohl
In reply to this post by Karoly Balogh (Charlie/SGR)
Just to be clear, the 64 in GetTickCount64 has nothing to do with
whether a machine is 32bit or 64bit.

Alex


On 04/11/2018 01:23 PM, Karoly Balogh (Charlie/SGR) wrote:

> Hi,
>
> On Wed, 11 Apr 2018, Michael Van Canneyt wrote:
>
>>>> 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.
>> Only on XP. On all other platforms, it is the better solution.
> 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
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

Luca Olivetti-2
In reply to this post by Alexander Grotewohl
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
--
Luca
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

Karoly Balogh (Charlie/SGR)
In reply to this post by Alexander Grotewohl
Hi,

On Wed, 11 Apr 2018, 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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

Graeme Geldenhuys-6
In reply to this post by R0b0t1
On 2018-04-11 17:44, 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

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

Michael Van Canneyt


On Thu, 12 Apr 2018, Graeme Geldenhuys wrote:

> On 2018-04-11 17:44, 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.

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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The unfortunate deprecation of GetTickCount

Graeme Geldenhuys-6
On 2018-04-12 07:39, 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

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12