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 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 lf
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
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 recen
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
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 inco
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 g
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 o
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
> 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 h
On Wed, 28 May 2014 10:35:47 +0200
Michael Schnell 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 f** problem?
R.
On 05/26/2014 09:47 PM, fredvs wrote:
Hum, checksynchronize(), i do not realy understand how to use in the
thread/loop...
I am working on an "ActiveNoUIi" widget type to be usable with Lazarus.
Here you can use "normal" Lazarus compatible TTimers.
This already works nicely for me (Linux X86
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 decen
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 incompat
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 am
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 "st
On 05/26/2014 06:49 PM, Dmitry Boyarintsev wrote:
My fear here is that anonymous functions will be misused dramatically
once being available.
Very valid point !
This also holds for parallel loops (my current favorite encapsulation
for OpenMP or similar libraries): Users _will_ try to do GUI
On 05/26/2014 05:02 PM, Dmitry Boyarintsev wrote:
Using a threading for GUI control is generally bad idea. Most of
standard GUI APIs (OSX, Windows, *nixes) have a note in 90% of their
functions - "do not use in multiple threads". Introducing threads to
handle GUI is potentially dangerous (due
18 matches
Mail list logo
