Re: [fpc-devel] About GetTickCount
On 3 November 2011 15:55, wrote: PLEASE NEVER MENTION EPIKTIMER AGAIN. it returns Now() on all platforms except i386. Not sure if my version of EpikTimer is the same as yours. Last time we had this (similar) conversation, your EpikTimer code was out of date (you still had code which required LCL to use EpikTimer). EpikTimer can use RDTSC under i386, because that is where it was still reliable. With todays multi-cpu, multi-core, power saving modes and hyper-boost features the TSC is not reliable any more. So EpikTimer also uses the Windows APIs QueryPerformanceCounter and QueryPerformanceFrequency under Windows (x86 x86_64). Under Linux it was suggested, to get similar functionality as the Windows API calls, by reading the value of CLOCK_MONOTONIC clock using POSIX clock_gettime function [1]. My version of EpikTimer use the fpgettimeofday() call under Linux for clock ticks. I haven't investigated in detail what that call translates too under Linux - I hope it's not Now(). [1] http://en.wikipedia.org/wiki/Time_Stamp_Counter So I really don't know why you are so harsh on EpikTimer, it is not nearly as bad as you paint it to be. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About GetTickCount
On Fri, 4 Nov 2011, Graeme Geldenhuys wrote: On 3 November 2011 15:55, wrote: PLEASE NEVER MENTION EPIKTIMER AGAIN. it returns Now() on all platforms except i386. Not sure if my version of EpikTimer is the same as yours. Last time we had this (similar) conversation, your EpikTimer code was out of date (you still had code which required LCL to use EpikTimer). Exactly, so seeing code like that, - dependency on LCL - Now() used on non-i386 my trust in such a component instantly went below zero. Someone who writes code like that clearly has no clue. And as far as I remember, I sent you a corrected version ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About GetTickCount
Please stop spreading FUD! - dependency on LCL I have fixed this well over a year or two ago. The only LCL dependency was the registration of the EpikTimer component on the Lazarus component palette. I simply split the original lazarus package into two packages (runtime and design-time) - that was all that was required. Hardly a LCL dependency! - Now() used on non-i386 my trust in such a component instantly went below zero. Someone who writes code like that clearly has no clue. I just did a grep search for Now() calls, and found a whopping ONE result - used as a wall clock feature, giving the current time of day. This function is NOT used for any of the timing functionality at all! As I said before: EpikTimer under Windows using the Multimedia API for high precision timing: QueryPerformanceCounter(). Under ALL other platforms, it uses the fpgettimeofday() call implemented in FPC And as far as I remember, I sent you a corrected version ? I remember this the other way round, but that's not important. I'll gladly send you my version of EpikTimer if you want to double check, but really, stop spreading FUD about this component. The mailing lists are full of your badmouth comments every time EpikTimer is mentioned. Just for for clarity, I checked out the latest EpikTimer from Lazarus CCR's subversion repository (I believe this to be the official home for EpikTimer). There are very few differences compared to my copy. My copy has the following change: - 3 line of code changed in the TEpikTimer.SystemSleep() for 32-bit non-Windows systems. Basicaly just using the Sleep() call as defined in FPC. So in fact the whole lot of IFDEF's in TEpikTimer.SystemSleep() can be removed because all platforms now use the same code. So please checkout the following code to make sure you use the latest EpikTimer. svn co https://lazarus-ccr.svn.sourceforge.net/svnroot/lazarus-ccr/components/epiktimer/ -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About GetTickCount
Sven Barth schrieb: It's basically a 64-bit type now. Here's ReactOS' implementation of GetTickCount64 (which is called by GetTickCount): [...] You notice the loop regarding SharedUserData again? ;) (though this time it also contains a call to YieldProcessor and a comment regarding the loop) Thanks, this makes it more clear: the implementation avoids a critical section or other more expensive synchronization. Nonetheless this implementation gives no clue on the MS Windows implementation, including variations (32/64 bit, WinCE...). We only can assume that GetTickCount is fast, and thus may be the base for other get-time functions. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About GetTickCount
On Fri, 4 Nov 2011, Graeme Geldenhuys wrote: So please checkout the following code to make sure you use the latest EpikTimer. svn co https://lazarus-ccr.svn.sourceforge.net/svnroot/lazarus-ccr/components/epiktimer/ I already did this before mailing my reply. The reply was just meant to explain why I was so negative in my original mail. So, I retract my warning, seeing that things have been properly fixed meanwhile. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About GetTickCount
On 4 November 2011 12:39, Sven Barth pascaldragon@g. wrote: fpgettimeofday itself simply calls the syscall gettimeofday of the kernel. I have another experimental version of epiktimer that uses the posix clock_gettime() (instead of fpgettimeofday), which I had to implement myself, because FPC doesn't include a fpXXX call in the unix or baseunix units. clock_gettime() is apparently equivalent to the timing calls of the Windows multi-media timing API's (many references on the internet of this). I just implemented this yesterday, so still need to put it through its paces. But from Michael's first comment in the below bug report, it seems that kernel calls clock_gettime() and gettimeofday() returns the same information - yet the latter is deprecated. So is using fpgettimeofday() at the moment really bad? Based on all this information - no. http://bugs.freepascal.org/view.php?id=20604 -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About GetTickCount
On Friday 04 of November 2011 11:54:16 Graeme Geldenhuys wrote: On 4 November 2011 12:39, Sven Barth pascaldragon@g. wrote: fpgettimeofday itself simply calls the syscall gettimeofday of the kernel. I have another experimental version of epiktimer that uses the posix clock_gettime() (instead of fpgettimeofday), which I had to implement myself, because FPC doesn't include a fpXXX call in the unix or baseunix units. clock_gettime() is apparently equivalent to the timing calls of the Windows multi-media timing API's (many references on the internet of this). No, it's not equivalent for kernels 2.6.28. CLOCK_MONOTONIC_RAW is included in = 2.6.28 and that kind of clock isn't disturbed by ntpd changes and other related timer changes. But from Michael's first comment in the below bug report, it seems that kernel calls clock_gettime() and gettimeofday() returns the same information - yet the latter is deprecated. So is using fpgettimeofday() at the moment really bad? Based on all this information - no. It is deprecated and at some point it will be removed from kernel, till then gettimeofday() returns same as clock_gettime(CLOCK_REALTIME), when it's removed from kernel fpc should be updated and that's it. Problem is that older versions of fpc won't work with such kernel. zeljko ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About GetTickCount
On Thursday 03 of November 2011 09:41:05 zeljko wrote: I guess that there's no GetTickCount in RTL. Is it possible to add it there ? Why ? Because current GetTickCount in lazarus uses Now() which is movable backward/forward by ntpd under unixes, and that could be a huge problem. This is what MSDN says about GetTickCount: Retrieves the number of milliseconds that have elapsed since the system was started, up to 49.7 days (what they do after 49.7 days ? ). So, according to POSIX clock_gettime(CLOCK_MONOTONIC) is supported on linux, bsd and others, and in that case we can have exact GetTickCount. If there's no support for monotonic clock on some platform , now() can be returned anytime. Forget all about this, only CLOCK_MONOTONIC_RAW is something we need but it's supported as of 2.6.28 kernel ... so no way. zeljko zeljko ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About GetTickCount
In our previous episode, zeljko said: So, according to POSIX clock_gettime(CLOCK_MONOTONIC) is supported on linux, bsd and others, and in that case we can have exact GetTickCount. If there's no support for monotonic clock on some platform , now() can be returned anytime. Forget all about this, only CLOCK_MONOTONIC_RAW is something we need but it's supported as of 2.6.28 kernel ... so no way. (and afaik POSIX doesn't specify the granularity, you need to do a separate call for that. It could be seconds) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About GetTickCount
Withdrawn. It is only partially true. Still it can not be expanded and can overflow easily. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About GetTickCount
Al 03/11/2011 9:41, En/na zeljko ha escrit: Retrieves the number of milliseconds that have elapsed since the system was started, up to 49.7 days (what they do after 49.7 days ? ). It starts again from 0. If you're using it to time events (i.e. ElapsedTime:=GetTickCount-StartTime), it's not a problem, as long as you don't need to time events that last longer than 49 days *and* you don't enable overflow check (-Co) Bye -- Luca ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About GetTickCount
On Thu, November 3, 2011 09:41, zeljko wrote: I guess that there's no GetTickCount in RTL. Is it possible to add it there ? Why ? Because current GetTickCount in lazarus uses Now() which is movable backward/forward by ntpd under unixes, and that could be a huge problem. This is what MSDN says about GetTickCount: Retrieves the number of milliseconds that have elapsed since the system was started, up to 49.7 days (what they do after 49.7 days ? ). So, according to POSIX clock_gettime(CLOCK_MONOTONIC) is supported on linux, bsd and others, and in that case we can have exact GetTickCount. If there's no support for monotonic clock on some platform , now() can be returned anytime. There is already GetMsCount in unit Dos. It should be possible to add it to sysutils too. This does not guarantee to be monotonic, but the primary goal is a simple and fast call which should allow checking time difference between two consecutive calls. It uses GetTickCount on Win32 and similar calls on other platforms. As implemented now, it doesn't protect you from time changes on all platforms though (but that is a limitation of implementation for those platforms). Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About GetTickCount
If you want to do timing, you can also take a look at EpikTimer. I believe it doesn't work on all platforms that FPC supports, but it works on the big three (Windows, Linux, Mac). -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About GetTickCount
On Thu, Nov 3, 2011 at 9:41 AM, zeljko zel...@holobit.net wrote: I guess that there's no GetTickCount in RTL. Is it possible to add it there ? If we are going to add this I would prefer to get the result in microseconds. If the platform doesnt support, then just multiply the result, but still allow the possibility. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About GetTickCount
On Thu, 3 Nov 2011, Graeme Geldenhuys wrote: If you want to do timing, you can also take a look at EpikTimer. I believe it doesn't work on all platforms that FPC supports, but it works on the big three (Windows, Linux, Mac). PLEASE NEVER MENTION EPIKTIMER AGAIN. it returns Now() on all platforms except i386. It should be abandoned. epiktimer is one of the worst written components ever, for some reason surrounded by unfounded myths. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About GetTickCount
zeljko schrieb: This is what MSDN says about GetTickCount: Retrieves the number of milliseconds that have elapsed since the system was started, up to 49.7 days (what they do after 49.7 days ? ). When the DWORD overflows, Win9x stops to work properly. NT uses an bigger data type, at least internally. IMO every OS supports an basic time counter, incremented by interrupts (BIOS, DOS) or in hardware, and starting at system boot time. A resolution of 10ns, as currently available, requires hardware support of course - and such support depends on the machine architecture. The determination of the current time adjusts the counter value, according to the clock frequency, and adds the absolute starting (boot) time. Afterwards the timzone shift can be added to that value, when local time is required. Then comes the hairy part, the conversion of that time into days, years etc., for display purposes. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About GetTickCount
Am 03.11.2011 18:15, schrieb Hans-Peter Diettrich:
zeljko schrieb:
This is what MSDN says about GetTickCount:
Retrieves the number of milliseconds that have elapsed since the
system was started, up to 49.7 days (what they do after 49.7 days ? ).
When the DWORD overflows, Win9x stops to work properly. NT uses an
bigger data type, at least internally.
It's basically a 64-bit type now. Here's ReactOS' implementation of
GetTickCount64 (which is called by GetTickCount):
=== source begin ===
ULONGLONG
WINAPI
GetTickCount64(VOID)
{
ULONG Multiplier;
LARGE_INTEGER TickCount;
/* Loop until we get a perfect match */
for (;;)
{
/* Read the tick count value */
TickCount.HighPart = SharedUserData-TickCount.High1Time;
TickCount.LowPart = SharedUserData-TickCount.LowPart;
if (TickCount.HighPart == SharedUserData-TickCount.High2Time)
break;
YieldProcessor();
}
/* Get the multiplier */
Multiplier = SharedUserData-TickCountMultiplier;
/* Convert to milliseconds and return */
return (Int64ShrlMod32(UInt32x32To64(Multiplier,
TickCount.LowPart), 24) +
(Multiplier * (TickCount.HighPart 8)));
}
=== source end ===
You notice the loop regarding SharedUserData again? ;) (though this time
it also contains a call to YieldProcessor and a comment regarding the
loop)
By the way: the TickCount field (and also the SystemTime one) is a
KSYSTEM_TIME struct which is defined like the following (copied from my
port):
=== source begin ===
//
// System Time Structure
//
_KSYSTEM_TIME = packed record
LowPart: ULONG;
High1Time: LONG;
High2Time: LONG;
end;
KSYSTEM_TIME = _KSYSTEM_TIME;
PKSYSTEM_TIME = ^KSYSTEM_TIME;
=== source end ===
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
