On 09/23/2014 09:51 PM, Peter Popov wrote:
, I will restate the obvious:
using reference counting will decrease parallel performance
You are perfectly right.
So you should try to avoid heavy ref counting (i.e focusing / defocusing
ref counted stuff, including Strings) in multithreaded code.
On 09/23/2014 11:09 PM, Boian Mitov wrote:
Correct you will lose ~3 assembly instructions (Interlocked
increment/decrement-exchange, and conditional)
With modern x86 archs, interlocked instructions are very expensive in
themselves and can take thousands of clock cycles due to cache
On 09/22/2014 02:34 PM, Sven Barth wrote:
I already suggested the addition of a TARCObject as a general
reference counted base class in my RFC ;)
Sounds nice, but is it (easily) possible to implement that the compiler
magic for doing the ref-counting is issued exactly whenever the
On 09/22/2014 08:51 PM, Boian Mitov wrote:
I am not big fan of the compiler handling parallel loops, as it will
limit any flexibility in implementation.
A library based functionality with shared executors is a better
design, and it allows not only for parallel loops but also for easy
parallel
On 09/22/2014 10:07 PM, Boian Mitov wrote:
Adding simple parallel loop lacks any of this power, and only serves
very specific cases.
As the parallel loop syntax would be nothing but syntax candy to easily
make use of a thread pool library, nobody would prevent the user from
directly use
On 09/22/2014 10:17 PM, hinstance wrote:
If it is a game, even 200 ms freeze would be annoying.
We do lots of embedded applications using Pascal. unavoidable Stop of
World would be End of World.
-Michael
___
fpc-devel maillist -
On 09/22/2014 11:25 PM, Sven Barth wrote:
Considering that those are two different features that don't have
anything to do with each other their development doesn't need to be
serialized, but can happen in parallel ;)
Will the destructor of a reference counted object not be a kind of
On 09/22/2014 08:34 PM, Boian Mitov wrote:
Strongly disagree...
You can't deny it. Please read some technical docs about the cost of
interlocked operation in multicore systems.
Doing parallel processing without ARC is practically suicidal IMHO.
That might well be, but it does not deny the
Am 25.09.2014 11:04 schrieb Michael Schnell mschn...@lumino.de:
On 09/22/2014 02:34 PM, Sven Barth wrote:
I already suggested the addition of a TARCObject as a general reference
counted base class in my RFC ;)
Sounds nice, but is it (easily) possible to implement that the compiler
magic
Am 25.09.2014 11:39 schrieb Michael Schnell mschn...@lumino.de:
On 09/22/2014 11:25 PM, Sven Barth wrote:
Considering that those are two different features that don't have
anything to do with each other their development doesn't need to be
serialized, but can happen in parallel ;)
Will the
On 09/23/2014 01:58 AM, Hans-Peter Diettrich wrote:
Why inherit when you can't override virtual methods?
Easily adding field.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 09/22/2014 08:37 PM, Boian Mitov wrote:
Honestly if you don’t know what you are doing when using ARC, I doubt
a bit, you really know what you are doing otherwise either ;-) .
Ref counted strings are no problem with any (normal) use of same.
In this thread you find an example describing how
On 09/25/2014 11:52 AM, Sven Barth wrote:
TARCObject would just be provided for convenience reasons. The real
magic is a keyword that can be used for any class to enable ARC for
that class and all it's descendant.
I see. Hence, technically, there would be a kind of attribute syntax,
but
On 09/25/2014 11:55 AM, Sven Barth wrote:
Why should it? When the reference count is decreased to zero (and thus
the final reference on the instance is gone) the destructor method is
executed (which is just a obj.Destroy;), simple as that (in reality
it's a bit more complex, but that's an
In our previous episode, Michael Schnell said:
You can't deny it. Please read some technical docs about the cost of
interlocked operation in multicore systems.
(I assume you mean multiPROCESSOR systems here?)
___
fpc-devel maillist -
Am 25.09.2014 12:08 schrieb Michael Schnell mschn...@lumino.de:
On 09/25/2014 11:52 AM, Sven Barth wrote:
TARCObject would just be provided for convenience reasons. The real
magic is a keyword that can be used for any class to enable ARC for that
class and all it's descendant.
I see. Hence,
Am 25.09.2014 11:59 schrieb Michael Schnell mschn...@lumino.de:
On 09/22/2014 08:37 PM, Boian Mitov wrote:
Honestly if you don’t know what you are doing when using ARC, I doubt a
bit, you really know what you are doing otherwise either ;-) .
Ref counted strings are no problem with any
Hi Sven,
Can you comment on how are you going to handle the case of
TInterfacedObject and descendants? Are you going to use the same Addref
Release method ? How can you guarantee that the same counter will be
updated in case of IUnknown implementations that introduce their own
refcount variable
On 22/09/14 19:21, Sven Barth wrote:
Am 22.09.2014 17:11 schrieb Jonas Maebe jonas.ma...@elis.ugent.be
mailto:jonas.ma...@elis.ugent.be:
On 22 Sep 2014, at 16:44, Peter Popov wrote:
TRefObject = referenced class(TWhateverBase)
end;
I would strongly recommend against that. Referenced and
What I am saying is that the parallel loop handles only one specific case of
parallelization, and with limited options.
A library implementation on the other hand offers full flexibility.
With best regards,
Boian Mitov
---
Mitov Software
Strongly disagree...
You can't deny it. Please read some technical docs about the cost of
interlocked operation in multicore systems.
As compare to the cost of other locking methods such as critical sections
that have to be implemented instead if the ARC is missing?
Doing parallel processing
Strings do not contain pioneers themselves.
Any standard tree design however usually contains circular reverences, and
pose the thread of leak if Weak pointers are not used usually for the Parent
pointer in the children.
Double linked list is another example.
With best regards,
Boian Mitov
On 25.09.2014 17:23, Chriss Kalogeropoulos wrote:
Hi Sven,
Can you comment on how are you going to handle the case of
TInterfacedObject and descendants? Are you going to use the same Addref
Release method ? How can you guarantee that the same counter will be
updated in case of IUnknown
Hi again,
How would you handle the case of a user adding an interface on a class
marked as reference counted (like a tstringlist descendant, TArcStringList)
and then inherits from that and implements the IUnknown TFooStringlist
=class (TArcStringlist, IInterface).
Will he be able to hook on the
24 matches
Mail list logo
