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

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

Hi,

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

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.

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

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

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.

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

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

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.

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.

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

GetTickCount is a windosism.
It should give the result in ms or not be ://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

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.

Zoe Peterson wrote

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.

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.

Alexander Grotewohl wrote

but the resolution is not a 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.

From: Martin Frb 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.

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.

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.

Sure, measurements using GetTickCount is not precise (+-20ms on Windows). Back in old days using GetTickCount was much faster than using Now which involves floating point operations. So when checking various timeouts in loops GetTickCount was preferable than Now. I have lot of old code which uses GetTickCount. Even in my current code I prefer GetTickCount for calculating small timeouts:

if GetTickCount - FStartTime > 3000 then ;

vs

if Now - FStartTime > 3/SecsPerDay then ;

Yuriy.

El 8/9/19 a les 13:17, Yuriy Sydorov ha escrit:

if GetTickCount - FStartTime > 3000 then ;

I actually use

   if DWORD(GetTickCount-FStartTime) > 3000 then

the former is affected by the rollback after 49 days, the latter isn't.

vs if Now - FStartTime > 3/SecsPerDay then ;

Besides, Now could go backwards (if system time is adjusted), while GetTickCount cannot

Bye

Yuriy Sydorov wrote

Sure, measurements using GetTickCount is not precise (+-20ms on Windows).

On any reasonably recent kernel, it has 16ms granularity and even before that was always guaranteed to be a monotonically incrementing (except for the rollover) number of milliseconds.

You would assume that `a physicist by education` is aware of the difference between precision, resolution, granularity, and the concept of units... Take a multimeter.
If I take my cheap 3 1/2 digit one and set it to the 20V range, it can display a number like '19.99'. That's 10mV granularity, probably not even that in actual resolution (depending on the ADC they used), but the precision appears high since it is too blind to see any noise. The unit is Volt. A "slightly more expensive" one from our lab could be a 4 1/2 digits Fluke, displaying '19.999' in the same setting. That's 1mV granularity, it actually has that resolution, and you start to see random noise in your signal so the precision looks worse. The unit is also Volt.

And you're saying since everybody measures with a different device, there's no point in specifying that we're talking about Volts and might as well write down a number in centiVolts or something and not tell anyone. Sure.

Oh, and difference vs absolute measurements has fuckall to do with that.

It can if the fallback is used.

Michael.

I am aware of these differences. The question was about the definition of GetTickCount. We can differ in opinion as to how it should be defined, unless we declare it to be an exact implementation of the description in the Microsoft documentation (which it explicitly is not on other platforms).

All arguments for adding a unit to the description relied on using it as a precision time measurement instrument: I merely remarked this has its limitations given the limited precision of gettickcount.

That aside:

If you're going to be insulting and personal, you might consider unsubscribing yourself from the mailing list: this is a technical discussion mailing list, not a tabloid where such things are permissible.

Likewise, words like 'fuckall' are normally not considered suitable in technical discussions. Again, this is not a tabloid.

Michael.

El 8/9/19 a les 18:23, Michael Van Canneyt ha escrit:

Well, that's a bug then.

Bye

It's the best you can do in absence of an actual timer tick call.

Michael.

El 8/9/19 a les 19:08, Michael Van Canneyt ha escrit:

At least the documentation should tell on which platform it's supposed to work. I know that it's supposed to work on windows (obviously, except for GetTickCount64 which doesn't work under xp), linux and freebsd (due to

{$IF defined(LINUX) or defined(FreeBSD)}
{$DEFINE HAVECLOCKGETTIME}
{$ENDIF}

)

Since those are the only platform I'm interested in, it's fine for me, but to know that I had to look at the implementation.

Bye

If you're going to be insulting and personal, you might consider unsubscribing yourself from the mailing list: this is a technical discussion mailing list, not a tabloid where such things are permissible.

Oh, given that I've been called various things worse than a simple "that's not how this works" on this here list already, one may have thought differently.

It's just that for all I keep saying I've given up on this *project*, I still love the *language*, and certain attempts to fix what isn't broken still tick me off more than they should. After all, someone somewhere down the line will have to undo them...

And one final thought-- since I've been persona non grata for years anyway, I'm genuinely surprised you don't have my address in a client-side killfile.

Preempting Tomas: yes, I'll shut up now.

Zoe Peterson wrote

GetTickCount and GetTickCount64 are Windows API functions that are explicitly documented as returning milliseconds,

I have to agree with you. If FPC keeps basing its implementation and API's on Win32 or Delphi, then it should adhere to their documentation and expected results. If FPC can't guarantee millisecond accuracy on all platforms, mark the API with the "platform" modifier and document that it is only for Windows or platform XYZ etc.

The inconsistencies of GetTickCount() has forced me to use EpikTimer or alternatives for many years which gives more reliable results and predictable units of measure.

If FPC really wants timing API's, then implement true cross-platform API's for timing with documented units and such. eg: Java has System.nanoTime() and System.currentTimeMillis().
With such API's there is no guesswork as to what the user expects when calling them, and it's 100% cross-platform.

Regards,
Graeme

Alexander Grotewohl wrote

every call to gettickcount is something like 10-15ms or so off.

Martin's suggested documentation "The minimum resolution may vary...." makes that very clear.

Also anybody that works with timing API's should know that each platform has different minimum resolutions. eg: I quickly found out that FreeBSD can give better minimum resolutions than Linux, and in turn Linux can give better minimum resolutions than Windows. Thats if you don't use specialized hardware and only rely and the platform's OS timing implementations.

Simply mentioning "The minimum resolution may vary" should be good enough. And if you want to go the extra mile, mention that simply calling the API twice after each other (no other lines of code in-between) and then viewing the difference should give you a good indication of the platform's minimum resolution after a few samples and avg result.

Regards,
Graeme

Michael Van Canneyt wrote

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

That's fair. GetTickCount is also the best thing for quickly checking timeouts and the like though. I can certainly agree that FPC would benefit from a function that can return platform-specific timing data as quickly as possible, but that should just be called something else.

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

Thank you :)

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.

That seems like a reasonable restriction to me. Needing the actual system uptime is going to be a much rarer than profiling or checking elapsed times, and supporting that aspect would be in conflict with making the function low overhead.