Re: [fpc-pascal] Very vague gettickcount64 description?
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 - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Very vague gettickcount64 description?
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 - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Very vague gettickcount64 description?
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 - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Very vague gettickcount64 description?
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 - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Very vague gettickcount64 description?
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 - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Very vague gettickcount64 description?
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 Grotewohlhttp://dcclost.comOn Sep 7, 2019 7:41 PM, Martin Frb 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 - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Very vague gettickcount64 description?
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 - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Very vague gettickcount64 description?
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 - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Very vague gettickcount64 description?
> 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. -- Zoë Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
