On 05/28/2014 06:09 PM, Henry Vermaak wrote:
an ifdef to call QueryPerformanceCounter/()clock_gettime() based on OS.
Things like this is why I'd rather use dVSO.
Calling the vDSO will certainly make things faster.
For me, the point is, that with vDSO, the Linux infrastructure will
handle the
On 05/28/2014 05:41 PM, Marco van de Voort wrote:
. But that means you need to use OS timing functions, and not ASM.
Meaning either syscalls or vDSO.
As in Linux syscalls do a usermode-Kernelmode-usermode switch, they
introduce a huger overhead.
In Windows I suppose syscalls usually are
On 05/28/2014 06:03 PM, Henry Vermaak wrote:
Blindly making assumptions about TSC stability can get you into
trouble. Microsoft advises against this, too:
http://msdn.microsoft.com/en-gb/library/windows/desktop/ee417693%28v=vs.85%29.aspx
As my Target is Linux, this does not help with the
On 05/29/2014 01:17 AM, Graeme Geldenhuys wrote:
Then fork it on Github and start publishing your changes. I'll gladly
review the suggestions and merge it what works.
OK. (Of course only after I did as much testing as possible - in fact I
can't do by far enough.)
This discussion shows that
Am 02.06.2014 10:38 schrieb Michael Schnell mschn...@lumino.de:
In Windows I suppose syscalls usually are not done directly by the rtl,
but functions calls to a Kernel dll are done, so that that Windows.provide
dll might decide to stay in usermode if possible.
On Windows the
Am 02.06.2014 10:38 schrieb Michael Schnell mschn...@lumino.de:
In Windows I suppose syscalls usually are not done directly by the rtl,
but functions calls to a Kernel dll are done, so that that Windows.provide
dll might decide to stay in usermode if possible.
Addendum: yes, the RTL calls the
On 06/02/2014 11:06 AM, Sven Barth wrote:
Addendum: yes, the RTL calls the core DLLs of the Win32 subsystem like
kernel32.dll, but they are just that: the core DLLs of the Win32
subsystem. They don't implement any core OS functionality like
hardware/device management, because that is done
In our previous episode, Michael Schnell said:
On 05/28/2014 05:41 PM, Marco van de Voort wrote:
. But that means you need to use OS timing functions, and not ASM.
Meaning either syscalls or vDSO.
As in Linux syscalls do a usermode-Kernelmode-usermode switch, they
introduce a huger
On 06/02/2014 11:49 AM, Marco van de Voort wrote:
Maybe, but is that relevant? We were talking about precision, not speed.
I have been talking about overhead (speed) all the time. This is my
intention to discuss the issue. Bus regarding time measurement of course
speed and precision is highly
On 06/02/2014 11:49 AM, Marco van de Voort wrote:
In Windows I suppose syscalls usually are not done directly by the rtl,
No. Windows calls kernel32/user32, which then mostly calls nt.dll functions
I feel free to translate this to: In Windows, the fpc rtl calls
kernel32/user32, ...
Which
On 28/05/14 09:32, Michael Schnell wrote:
In fact I do want the best possible stuff and not a fork. I am just
trying to help (as I would like to use it in the said current project).
Then fork it on Github and start publishing your changes. I'll gladly
review the suggestions and merge it what
On 05/26/2014 08:17 PM, Sven Barth wrote:
The former is already required out of Delphi compatibility while
TEpikTimer is not.
(For the record: I do hate this argument. Especially regarding the
latest moves of Delphi getting more and more incompatible to itself. fpc
can easily be both more
On 05/27/2014 06:45 AM, Graeme Geldenhuys wrote:
I also told Michael S. that if he does submit a patch to the FPC team (I
can't stop him), make sure it has a different name, so as not to
conflict with the official EpikTimer component.
In fact I do want the best possible stuff and not a fork. I
On Wed, 28 May 2014, Michael Schnell wrote:
On 05/26/2014 08:17 PM, Sven Barth wrote:
The former is already required out of Delphi compatibility while
TEpikTimer is not.
(For the record: I do hate this argument. Especially regarding the latest
moves of Delphi getting more and more
On 05/26/2014 01:29 PM, Graeme Geldenhuys wrote:
Plus EpikTimer (as a project) contains more than just a single .pas
unit. It has Lazarus package files, demos etc - those don't belong in
the FPC repository, and will only fragment tho EpikTimer codebase.
Which is really great !
But how to
On Wed, 28 May 2014 10:35:47 +0200
Michael Schnell mschn...@lumino.de wrote:
But how to decently provide a fully released version of EpikTimer to not
Lazarus enabled users of fpc ?
https://github.com/graemeg/epiktimer/releases
Download. Extract. Copy needed file(s). Profit.
Where is the
In fact I do want the best possible stuff and not a fork. I am just
trying to help (as I would like to use it in the said current project).
In that case some attention points:
- help implementing and testing fine grained timings on *nix. Now it only has a
special
case for linux.
- Seems
On 05/28/2014 01:47 PM, Reimar Grabowski wrote:
Where is the f** problem?
Supposedly none (as I already stated in the Lazarus list).
Thanks !
-Michael
(What I'd like to prevent is that here again the award for the best way
to avoid ubiquitous usage of community based code is close at
On 05/28/2014 02:00 PM, Marco van de Voort wrote:
In that case some attention points:
- help implementing and testing fine grained timings on *nix. Now it only has a
special
case for linux.
- Seems high precision is not used on anything but x86.
- Is rdtsc safe for CPUs that can vary clock
On Wed, May 28, 2014 at 02:00:06PM +0200, Marco van de Voort wrote:
In fact I do want the best possible stuff and not a fork. I am just
trying to help (as I would like to use it in the said current project).
In that case some attention points:
- help implementing and testing fine grained
On 05/28/2014 04:26 PM, Henry Vermaak wrote:
- The rdtsc instruction needs to be protected from out of order
execution. Some people use cpuid, which is expensive. It looks like
the linux kernel uses mfence or lfence/mfence depending on CPU type.
... meaning the current version of
On Wed, May 28, 2014 at 02:00:06PM +0200, Marco van de Voort wrote:
- Is rdtsc safe for CPUs that can vary clock of cores independently like
Core Mono? What if the process changed CPU to a different clocked core?
I've read that on recent CPUs, the TSC is unaffected by the actual clock
rate
In our previous episode, Henry Vermaak said:
On Wed, May 28, 2014 at 02:00:06PM +0200, Marco van de Voort wrote:
- Is rdtsc safe for CPUs that can vary clock of cores independently like
Core Mono? What if the process changed CPU to a different clocked core?
I've read that on recent
On Wed, May 28, 2014 at 05:41:08PM +0200, Marco van de Voort wrote:
In our previous episode, Henry Vermaak said:
On linux, The TSC gets calibrated and the synchronisation is tested, which
may result in the TSC clock source being marked as unstable and disabled.
In this case, it will fall
On Wed, May 28, 2014 at 04:31:53PM +0200, Michael Schnell wrote:
On 05/28/2014 04:26 PM, Henry Vermaak wrote:
- The rdtsc instruction needs to be protected from out of order
execution. Some people use cpuid, which is expensive. It looks like
the linux kernel uses mfence or
In our previous episode, Marco van de Voort said:
still to new a requirement to assume for general purpose code like RTL and
FCL, if you agree to clip real old stuff.
_EVEN_ if you agree to clip real old stuff (read: anything Pre core2 intel
like Pentium D and Core duo)
On 26/05/14 10:14, Michael Schnell wrote:
file epiktimer.pas that is independent of Lazarus and makes sense to
be use in not Lazarus based projects in the fpc RTL svn.
As I mentioned in the Lazarus mailing list. I don't believe everything
should always be dumped in the FPC repository. It adds
Hi Sven,
You raised all the points which I already mentioned to Michael Schnell -
why I think EpikTimer should NOT be in the FCL.
* FPC has too a slow release cycle
* No need to burden the FPC team with supporting yet another component
* It will reduce the possibility for experimentation and
On 05/24/2014 01:55 PM, Graeme Geldenhuys wrote:
I've spoken to Tom and he agreed. We moved the EpikTimer repository to
Github. The Lazarus-CCR version will be deleted by Tom in due time.
While I am happy about your move to do an official release of
EpikTimer. I'd like to add that IMHO it
On 26/05/2014 11:14, Michael Schnell wrote:
While I am happy about your move to do an official release of
EpikTimer. I'd like to add that IMHO it would be appropriate to have the
file epiktimer.pas that is independent of Lazarus and makes sense to
be use in not Lazarus based projects in the
On 05/26/2014 11:55 AM, Reinier Olislagers wrote:
I don't understand exactly what you are trying to say. Is this:
- a request to Graeme
- a promise that you are going to provide a patch to the FPC RTL
- a remark
- something else
Sorry for being unclear.
I meant this as a general request to
On 26/05/2014 12:12, Michael Schnell wrote:
On 05/26/2014 11:55 AM, Reinier Olislagers wrote:
I meant this as a general request to the powers of the fpc (rtl)
project with svn write access to allow Greame, Tom (or maybe myself) to
include the TEpikTimer class in the next release of the
On 05/26/2014 12:42 PM, Reinier Olislagers wrote:
Well, the normal procedure for doing this is to submit a patch if you
want something to be added to FPC.
Thanks for your hints.
As I locally do use svn, I suppose I will be able to do a patch for a
not yet existing file :)
I can't do a
On 05/26/2014 12:42 PM, Reinier Olislagers wrote:
Well, the normal procedure for doing this is to submit a patch if you
want something to be added to FPC.
Thanks for your hints.
As I locally do use svn, I suppose I will be able to do a patch for a
not yet existing file :)
I can't do a
On Mon, May 26, 2014 13:12, Michael Schnell wrote:
.
.
A big problem with EpikTimer is that is _should_ be decently useful with
all archs and OSes.
This might be a nightmare to test.
You don't need to do that - the new addition may be enabled selectively
for the CPU+OS combinations for
Am 26.05.2014 12:12 schrieb Michael Schnell mschn...@lumino.de:
On 05/26/2014 11:55 AM, Reinier Olislagers wrote:
I don't understand exactly what you are trying to say. Is this:
- a request to Graeme
- a promise that you are going to provide a patch to the FPC RTL
- a remark
- something
On 05/26/2014 02:06 PM, Tomas Hajny wrote:
You don't need to do that - the new addition may be enabled
selectively for the CPU+OS combinations for which it has been already
tested successfully (and this approach is preferred over enabling it
for everything after testing just a small subset of
On 05/26/2014 02:23 PM, Sven Barth wrote:
I don't see a need for this in the FCL yet. At least not until the
dust that you are whirling up has settled down as FPC has a quite slow
release cycle.
I absolutely agree.
Nonetheless I feel that (a decently multi-arch enabled version) of
On 26.05.2014 15:07, Michael Schnell wrote:
On 05/26/2014 02:23 PM, Sven Barth wrote:
I don't see a need for this in the FCL yet. At least not until the
dust that you are whirling up has settled down as FPC has a quite slow
release cycle.
I absolutely agree.
Nonetheless I feel that (a
Hi,
I've spoken to Tom and he agreed. We moved the EpikTimer repository to
Github. The Lazarus-CCR version will be deleted by Tom in due time.
I applied some of my changes to code in Github (more changes recently
discussed in this mailing list will follow soon), fixed the etdemo
project to be
40 matches
Mail list logo
