Very vague gettickcount64 description?

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

Very vague gettickcount64 description?

Paulo Costa-3
Hi,

While consulting the online reference about gettickcount
https://www.freepascal.org/docs-html/rtl/sysutils/gettickcount64.html
I could not know anything about the units involved.

It says "It is useful for time measurements, but no assumtions should be
made as to the interval between the ticks."

I understand that in some cases the measure may deviate from the real
value but perhaps, at least the units, should be stated.


Greetings,

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

Re: Very vague gettickcount64 description?

Tomas Hajny-2
On 2019-09-03 15:27, Paulo Costa wrote:


Hi,

> While consulting the online reference about gettickcount
> https://www.freepascal.org/docs-html/rtl/sysutils/gettickcount64.html
> I could not know anything about the units involved.
>
> It says "It is useful for time measurements, but no assumtions should
> be made as to the interval between the ticks."
>
> I understand that in some cases the measure may deviate from the real
> value but perhaps, at least the units, should be stated.

The documentation is vague on purpose - due to the variety of platforms
supported by FPC and the low-level nature of GetTickCount, we do not
want to guarantee specific units (GetTickCount is supposed to be
supported directly by the platform rather than having an additional RTL
layer possibly unifying differences in platform behaviour on top of it).

BTW, it may be better to mention that you're not subscribed to the list
unless you use different way for accessing the messages (like the list
archive) because otherwise the responses may not reach you.

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

Re: Very vague gettickcount64 description?

Michael Van Canneyt
In reply to this post by Paulo Costa-3


On Tue, 3 Sep 2019, Paulo Costa wrote:

> Hi,
>
> While consulting the online reference about gettickcount
> https://www.freepascal.org/docs-html/rtl/sysutils/gettickcount64.html
> I could not know anything about the units involved.
>
> It says "It is useful for time measurements, but no assumtions should be
> made as to the interval between the ticks."
>
> I understand that in some cases the measure may deviate from the real
> value but perhaps, at least the units, should be stated.

As a physicist by education, normally I'd agree with you about units,
but not in this case.

In this case I will not put it because it can/will depend on the system.

You should only use it for relative measurements, in that case the unit does
not matter.

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

Re: Very vague gettickcount64 description?

DougC
In reply to this post by Tomas Hajny-2
If intentionally vague then that fact should be included in the description along with the reason!


---- On Fri, 06 Sep 2019 10:06:24 -0400 Tomas Hajny <[hidden email]> wrote ----

On 2019-09-03 15:27, Paulo Costa wrote:
> While consulting the online reference about gettickcount
> https://www.freepascal.org/docs-html/rtl/sysutils/gettickcount64.html
> I could not know anything about the units involved.
>
> It says "It is useful for time measurements, but no assumtions should
> be made as to the interval between the ticks."
>
> I understand that in some cases the measure may deviate from the real
> value but perhaps, at least the units, should be stated.

The documentation is vague on purpose - due to the variety of platforms
supported by FPC and the low-level nature of GetTickCount, we do not
want to guarantee specific units (GetTickCount is supposed to be
supported directly by the platform rather than having an additional RTL
layer possibly unifying differences in platform behaviour on top of it).



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

Re: Very vague gettickcount64 description?

Tomas Hajny-2
On 2019-09-06 16:15, DougC wrote:
> If intentionally vague then that fact should be included in the
> description along with the reason!

That's a fair comment. I suggest that you raise it in a bug report.

Tomas



> ---- On Fri, 06 Sep 2019 10:06:24 -0400 Tomas Hajny
> <[hidden email]> wrote ----
>
>
> On 2019-09-03 15:27, Paulo Costa wrote:
>> While consulting the online reference about gettickcount
>> https://www.freepascal.org/docs-html/rtl/sysutils/gettickcount64.html
>> I could not know anything about the units involved.
>>
>> It says "It is useful for time measurements, but no assumtions should
>> be made as to the interval between the ticks."
>>
>> I understand that in some cases the measure may deviate from the real
>> value but perhaps, at least the units, should be stated.
>
> The documentation is vague on purpose - due to the variety of platforms
> supported by FPC and the low-level nature of GetTickCount, we do not
> want to guarantee specific units (GetTickCount is supposed to be
> supported directly by the platform rather than having an additional RTL
> layer possibly unifying differences in platform behaviour on top of
> it).
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Very vague gettickcount64 description?

Yuriy Sydorov
In reply to this post by Tomas Hajny-2
On 06.09.2019 17:06, Tomas Hajny wrote:
> The documentation is vague on purpose - due to the variety of platforms supported by FPC and the low-level nature of
> GetTickCount, we do not want to guarantee specific units (GetTickCount is supposed to be supported directly by the
> platform rather than having an additional RTL layer possibly unifying differences in platform behaviour on top of it).

IMO the result of GetTickCount without defined measure units is useless. Historically the result of GetTickCount is
milliseconds (as in the corresponding winapi function). Implementations of GetTickCount for all major platforms also
return milliseconds. If there are platform implementations which return different units for GetTickCount, they should be
fixed. There is no real use for GetTickCount without knowing its units.

So the units of GetTickCount must be milliseconds for all platforms. The only variables - how often the result of
GetTickCount is changed and its starting value.

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

Re: Very vague gettickcount64 description?

Marco van de Voort-2
In reply to this post by Michael Van Canneyt

Op 2019-09-06 om 16:07 schreef Michael Van Canneyt:

>
>>
>> While consulting the online reference about gettickcount
>> https://www.freepascal.org/docs-html/rtl/sysutils/gettickcount64.html
>> I could not know anything about the units involved.
>>
>> It says "It is useful for time measurements, but no assumtions should
>> be made as to the interval between the ticks."
>>
>> I understand that in some cases the measure may deviate from the real
>> value but perhaps, at least the units, should be stated.
>
> As a physicist by education, normally I'd agree with you about units,
> but not in this case.
>
> In this case I will not put it because it can/will depend on the system.
>
> You should only use it for relative measurements, in that case the
> unit does
> not matter.
>
If so, why doesn't the *nix implementation return the full precision
rather than dividing to get in the ms range ?

I happened to run into this a few weeks ago, and considered it a mistake
(meaning the unit was fixed ms, and the remark refering to the update
granularity rather than unit).


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

Re: Very vague gettickcount64 description?

Michael Van Canneyt
In reply to this post by Yuriy Sydorov


On Fri, 6 Sep 2019, Yuriy Sydorov wrote:

> On 06.09.2019 17:06, Tomas Hajny wrote:
>> The documentation is vague on purpose - due to the variety of platforms
> supported by FPC and the low-level nature of
>> GetTickCount, we do not want to guarantee specific units (GetTickCount is
> supposed to be supported directly by the
>> platform rather than having an additional RTL layer possibly unifying
> differences in platform behaviour on top of it).
>
> IMO the result of GetTickCount without defined measure units is useless.

Each his opinion.

For example, I think GetTickCount is utterly useless.

I have never used it, never will and I have nevertheless already done
plenty of time measurements.

Depending on the platform, gettickcount falls back on Now(). This does not have a
millisecond precision. This call can take a time of up to 90 ms.
So saying that gettickcount has millisecond precision would be simply
incorrect.

What I will do is explain in the documentation why the units are not
mentioned.

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

Re: Very vague gettickcount64 description?

Marco van de Voort-2

Op 2019-09-06 om 20:02 schreef Michael Van Canneyt:


>
> What I will do is explain in the documentation why the units are not
> mentioned.
>
Can we remove the division in *nix also ? If ms resolution is not
supported, then why divide the us/ns ? It serves no purpose, if rollover
and unit size are not guaranteed.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Very vague gettickcount64 description?

Michael Van Canneyt


On Sat, 7 Sep 2019, Marco van de Voort wrote:

>
> Op 2019-09-06 om 20:02 schreef Michael Van Canneyt:
>
>
>>
>> What I will do is explain in the documentation why the units are not
>> mentioned.
>>
> Can we remove the division in *nix also ? If ms resolution is not
> supported, then why divide the us/ns ? It serves no purpose, if rollover
> and unit size are not guaranteed.

I think it should be removed.

If you look at clock_time documentation no guarantees about resolution are given.
there is a call to get resolution, so in the best case you'd need to use
that to get a 'correct' time. It would mean 2 system calls every time, since there
is also no guarantee that the call to get the resolution will give the same
result every time.

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

Re: Very vague gettickcount64 description?

Luca Olivetti-2
El 7/9/19 a les 13:38, Michael Van Canneyt ha escrit:

>
>
> On Sat, 7 Sep 2019, Marco van de Voort wrote:
>
>>
>> Op 2019-09-06 om 20:02 schreef Michael Van Canneyt:
>>
>>
>>>
>>> What I will do is explain in the documentation why the units are not
>>> mentioned.
>>>
>> Can we remove the division in *nix also ? If ms resolution is not
>> supported, then why divide the us/ns ? It serves no purpose, if
>> rollover and unit size are not guaranteed.
>
> I think it should be removed.

GetTickCount is a windosism.
It should give the result in ms or not be provided at all.

https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-gettickcount

If you want more resolution/precision use something else (if available).
For what I do GetTickCount is perfectly fine (as long as it gives the
result in ms and it has a resolution around 10ms).
What is a travesty is the "emulation" of GetTickCount64 with
GetTickCount for the windows versions where GetTickCount64 isn't
available. *That* will produce problems with the unexpected rollover to
0 after 49 days.
It doesn't help that GetTickCount has been marked as deprecated (and
there the rollover isn't a problem because it is expected and you know
you cannot time events longer than 49 days).

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

Re: Very vague gettickcount64 description?

Zoë Peterson
In reply to this post by Michael Van Canneyt
GetTickCount and GetTickCount64 are Windows API functions that are
explicitly documented as returning milliseconds, and FPC on Unix up to
now is has matched that. Why in the world would you think that
changing that behavior would be a good idea, *especially* if you keep
the function name the same?!?

As an FPC user, this seems like an astoundingly bad decision to even
be considering.

--  
Zoë Peterson
Scooter Software


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

Re: Very vague gettickcount64 description?

Martok
Am 07.09.2019 um 21:42 schrieb Zoe Peterson:
> GetTickCount and GetTickCount64 are Windows API functions that are
> explicitly documented as returning milliseconds, [...]
> As an FPC user, this seems like an astoundingly bad decision to even
> be considering.
But it perfectly fits the "recent" trend to invisibly break Delphi compatibility
wherever possible.


--
Regards,
Martok


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

Re: Very vague gettickcount64 description?

Martin Frb
In reply to this post by Zoë Peterson
On 07/09/2019 21:42, Zoe Peterson wrote:
> GetTickCount and GetTickCount64 are Windows API functions that are
> explicitly documented as returning milliseconds, and FPC on Unix up to
> now is has matched that. Why in the world would you think that
> changing that behavior would be a good idea, *especially* if you keep
> the function name the same?!?
>
> As an FPC user, this seems like an astoundingly bad decision to even
> be considering.
>

I do back that.

vague-ness or "the absence of documenting" is  not the same as (from the
beginning on) documenting that "the unit is not given, *because* it may
*vary*"

I would suggest to amend the documentation to the current state.
Something like:
----

The length of a tick depends on the platform/OS/...
Therefore a tick can be a different amount of time on different targets.

For the following targets, the ticks are specified as follows. For other
targets they may change, until documented.
Windows: tick = millisecond
Linux: tick = millisecond
OSx/Mac/Darwin: tick = ?

The minimum resolution may vary, and may be more than one tick.
The function itself may also take a varying amount of ticks, and the
returned result may on top of resolution issues be outdated by any
amount of ticks.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Very vague gettickcount64 description?

Alexander Grotewohl
but the resolution is not a ms at all. every call to gettickcount is something like 10-15ms or so off. you'd be lucky to call it a ms after it was updated by the os. do we document that too?

--
Alexander Grotewohl
http://dcclost.com

On Sep 7, 2019 7:41 PM, Martin Frb <[hidden email]> wrote:

On 07/09/2019 21:42, Zoe Peterson wrote:
> GetTickCount and GetTickCount64 are Windows API functions that are
> explicitly documented as returning milliseconds, and FPC on Unix up to
> now is has matched that. Why in the world would you think that
> changing that behavior would be a good idea, *especially* if you keep
> the function name the same?!?
>
> As an FPC user, this seems like an astoundingly bad decision to even
> be considering.
>

I do back that.

vague-ness or "the absence of documenting" is  not the same as (from the
beginning on) documenting that "the unit is not given, *because* it may
*vary*"

I would suggest to amend the documentation to the current state.
Something like:
----

The length of a tick depends on the platform/OS/...
Therefore a tick can be a different amount of time on different targets.

For the following targets, the ticks are specified as follows. For other
targets they may change, until documented.
Windows: tick = millisecond
Linux: tick = millisecond
OSx/Mac/Darwin: tick = ?

The minimum resolution may vary, and may be more than one tick.
The function itself may also take a varying amount of ticks, and the
returned result may on top of resolution issues be outdated by any
amount of ticks.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



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

Re: Very vague gettickcount64 description?

Martin Frb
On 08/09/2019 02:07, Alexander Grotewohl wrote:
> but the resolution is not a ms at all. every call to gettickcount is
> something like 10-15ms or so off. you'd be lucky to call it a ms after
> it was updated by the os. do we document that too?
As I said: "The minimum resolution may vary, and may be more than one tick."

I have no crystal ball, but I would guess, that when it was first
introduced, it aimed to mimic the windows function.
The point is, it is not very exact. And it may on some platform already
have completely different units.

But that does not mean, it needs to be changed on existing targets. And
if it is not going to be changed, then it can be documented.

While I can only speak from my experience, a typical usage would be a
"timeout" (or timer) in a calculation loop. The loop would utilize the
CPU all the time. So a TTimer  would not be all that practical.
But every about 100ms you want to call ProcessMessages that is likely
more expensive than GetTickCount. (ok move it to a thread, but that is
not the point).
So you check the diff between to GetTickCount. A diff of 100 means
around 100ms +/- something (in that case +/- 50% would even be ok).
But make GetTickCount = 0.0001ms, and it matters (too much time in
ProcessMessages / slowdown of calculation).

In some unit test, I use it for timeouts of 5 or 10 seconds. It does not
matter if that is 4 or 6 (8 to 12) seconds..., just approx.



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

Re: Very vague gettickcount64 description?

Zoë Peterson
> From: Martin Frb <[hidden email]>
> But that does not mean, it needs to be changed on existing targets.
> And if it is not going to be changed, then it can be documented.

I agree with everything Martin has said, though IMO GetTickCount must
return values in ms on every single platform and any that can't should
have it removed. It's not a precision timer and it should not be an
intrinsic for whatever random RDTSC-like instruction the current
platform has. It's used for checking (rough) elapsed times. I honestly
can't think of a single use for the current function as defined, especially
in a cross-platform app. Precision and accuracy can vary, but
unspecified units with no way to query them is ridiculous.

--
Zoë Peterson
Scooter Software


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

Re: Very vague gettickcount64 description?

Michael Van Canneyt


On Sat, 7 Sep 2019, Zoe Peterson wrote:

>> From: Martin Frb <[hidden email]>
>> But that does not mean, it needs to be changed on existing targets.
>> And if it is not going to be changed, then it can be documented.
>
> I agree with everything Martin has said, though IMO GetTickCount must
> return values in ms on every single platform and any that can't should
> have it removed. It's not a precision timer and it should not be an
> intrinsic for whatever random RDTSC-like instruction the current
> platform has. It's used for checking (rough) elapsed times. I honestly
> can't think of a single use for the current function as defined, especially
> in a cross-platform app. Precision and accuracy can vary, but
> unspecified units with no way to query them is ridiculous.

For relative measurements, units are not needed. A ratio has no units, the
only thing that is required is that the units for both measurements are the
same (which should be the case on a single platform).

But I have re-checked the Microsoft documentation, the implementation, and
have added millisecond units to documentation of gettickcount(64).

Note that the FPC implementation gives an increasing time, not the number of
milliseconds elapsed since system boot. Which is what, strictly speaking,
it should return to comply to the Microsoft implementation.

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

Re: Very vague gettickcount64 description?

Yuriy Sydorov
On 08.09.2019 10:09, Michael Van Canneyt wrote:

>
>
> On Sat, 7 Sep 2019, Zoe Peterson wrote:
>
>>> From: Martin Frb <[hidden email]>
>>> But that does not mean, it needs to be changed on existing targets.
>>> And if it is not going to be changed, then it can be documented.
>>
>> I agree with everything Martin has said, though IMO GetTickCount must return values in ms on every single platform and
>> any that can't should have it removed. It's not a precision timer and it should not be an intrinsic for whatever
>> random RDTSC-like instruction the current platform has. It's used for checking (rough) elapsed times. I honestly can't
>> think of a single use for the current function as defined, especially in a cross-platform app. Precision and accuracy
>> can vary, but unspecified units with no way to query them is ridiculous.
>
> For relative measurements, units are not needed. A ratio has no units, the
> only thing that is required is that the units for both measurements are the
> same (which should be the case on a single platform).

Strictly defined measurement units are important for cross-platform (and Delphi) compatibility. So GetTickCount_2 -
GetTickCount_1 must return how many milliseconds have elapsed between calls of GetTickCount regardless of the platform
where the program is running.

> But I have re-checked the Microsoft documentation, the implementation, and
> have added millisecond units to documentation of gettickcount(64).

Thanks.

> Note that the FPC implementation gives an increasing time, not the number of
> milliseconds elapsed since system boot. Which is what, strictly speaking,
> it should return to comply to the Microsoft implementation.

Yes. Implementing this for every platform would be overkill. GetTickCount in FPC should be documented just as a
millisecond counter without defined starting point and without guaranteed precision.

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

Re: Very vague gettickcount64 description?

Michael Van Canneyt


On Sun, 8 Sep 2019, Yuriy Sydorov wrote:

> On 08.09.2019 10:09, Michael Van Canneyt wrote:
>>
>>
>> On Sat, 7 Sep 2019, Zoe Peterson wrote:
>>
>>>> From: Martin Frb <[hidden email]>
>>>> But that does not mean, it needs to be changed on existing targets.
>>>> And if it is not going to be changed, then it can be documented.
>>>
>>> I agree with everything Martin has said, though IMO GetTickCount must
> return values in ms on every single platform and
>>> any that can't should have it removed. It's not a precision timer and it
> should not be an intrinsic for whatever
>>> random RDTSC-like instruction the current platform has. It's used for
> checking (rough) elapsed times. I honestly can't
>>> think of a single use for the current function as defined, especially in a
> cross-platform app. Precision and accuracy
>>> can vary, but unspecified units with no way to query them is ridiculous.
>>
>> For relative measurements, units are not needed. A ratio has no units, the
>> only thing that is required is that the units for both measurements are the
>> same (which should be the case on a single platform).
>
> Strictly defined measurement units are important for cross-platform (and
> Delphi) compatibility. So GetTickCount_2 -
> GetTickCount_1 must return how many milliseconds have elapsed between calls
> of GetTickCount regardless of the platform
> where the program is running.

I understand, but I remain with my point of view that this is a worthless measurement
if you simply do gettick; operation; gettick;

Since gettick itself takes time (definitely the fallback to fpgettimeofday)
the measurement itself influences the resulting time (a bit like quantum theory).
So for small times, I would distrust anything measured like that.

For good measurements, you need to repeat the operation say 100x or 1000x
and average out. And then you can just use now().

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12