On 10/13/2014 04:14 PM, hinsta...@yandex.ru wrote:
Maybe; however I am asking about reference counted objects feature.
Sorry for the fuzz. (Your contribution was a direct reply to my mail
about parallel loops.)
-Michael
___
fpc-devel maillist -
On 10/13/2014 04:14 PM, hinsta...@yandex.ru wrote:
I thought Svan Barth said that he considered implementing it
Regarding this, Maybe, Success in implementing should be preceded by a
decision if and how this feature does make sense regarding the possible
addition danger it offers (see the
Am 14.10.2014 09:09 schrieb Michael Schnell mschn...@lumino.de:
On 10/13/2014 04:14 PM, hinsta...@yandex.ru wrote:
I thought Svan Barth said that he considered implementing it
Regarding this, Maybe, Success in implementing should be preceded by a
decision if and how this feature does make
On 10/14/2014 11:50 AM, Sven Barth wrote:
It's a proof of concept implementation to have real code to work with
instead of just theories. Also it's in a separate branch, so it
doesn't interrupt any existing code except one explicitly uses that
branch.
Sounds good.
-Michael (curious...)
Any success yet? Any chance this feature will be in FreePascal 3.0 ?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On 10/13/2014 02:37 PM, hinsta...@yandex.ru wrote:
Any success yet?
Any chance this feature will be in FreePascal 3.0 ?
I don't suppose anybody is working on a parallel loop language feature.
-Michael
___
fpc-devel maillist -
Maybe; however I am asking about reference counted objects feature. I thought
Svan Barth said that he considered implementing it
13.10.2014, 18:11, Michael Schnell mschn...@lumino.de:
On 10/13/2014 02:37 PM, hinsta...@yandex.ru wrote:
Any success yet?
Any chance this feature will be in
Am 13.10.2014 16:17 schrieb hinsta...@yandex.ru:
Maybe; however I am asking about reference counted objects feature. I
thought Svan Barth said that he considered implementing it
I have a working proof of concept implementation of my RFC and am
currently' commiting it to branches/svenbarth/arc.
Great!Sorry for misspelling your name btw13.10.2014, 20:44, "Sven Barth" pascaldra...@googlemail.com: Am 13.10.2014 16:17 schrieb hinsta...@yandex.ru: Maybe; however I am asking about reference counted objects feature. I thought Svan Barth said that he considered implementing it I have a working
On Mon, Oct 13, 2014 at 2:23 PM, hinsta...@yandex.ru hinsta...@yandex.ru
wrote:
Great!
Sorry for misspelling your name btw
13.10.2014, 20:44, Sven Barth pascaldra...@googlemail.com:
Am 13.10.2014 16:17 schrieb hinsta...@yandex.ru:
Maybe; however I am asking about reference counted
On 13.10.2014 19:23, hinsta...@yandex.ru wrote:
Great!
Sorry for misspelling your name btw
I had worse already. Swen for example. Or a common one at uni was Svn ;)
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 10/13/2014 10:58 PM, Sven Barth wrote:
On 13.10.2014 19:23, hinsta...@yandex.ru wrote:
Great!
Sorry for misspelling your name btw
I had worse already. Swen for example. Or a common one at uni was
Svn ;)
Better than git ;-)
Nikolay
___
On 14.10.2014 00:01, Nikolay Nikolov wrote:
On 10/13/2014 10:58 PM, Sven Barth wrote:
On 13.10.2014 19:23, hinsta...@yandex.ru wrote:
Great!
Sorry for misspelling your name btw
I had worse already. Swen for example. Or a common one at uni was
Svn ;)
Better than git ;-)
Well... it's
On 09/26/2014 06:06 PM, Mark Morgan Lloyd wrote:
Different implementations could potentially use either local threads
or OpenMPI.
Yep.
With Local Thread you supposedly mean user land threads. Same would
need to be implemented together with an appropriate set of synchronizing
functions. Seems
On 09/26/2014 10:05 PM, Boian Mitov wrote:
If ARC is missing you need to call free. No Critical section is
involved with that.
Incorrect the pointer on which you call free needs to be guarded.
Only if it is used in a way that asks for this. Whether or not it is
done is up to the user.
IMHO it usually is better to first decide if you want to drink tea or
bear before you run to the fridge or to the cupboard.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Michael Schnell wrote:
IMHO it usually is better to first decide if you want to drink tea or
bear before you run to the fridge or to the cupboard.
That could be a fatal error, even if permitted by the parser :-)
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the
Michael Schnell wrote:
Something like this to do a matrix multiplication
At the moment the only point I am making is this. Assuming a thread pool
which can be applied to a parallel activity, it might be desirable to
only use that from a single app-level thread. Hence (using your syntax
On 09/29/2014 10:55 AM, Mark Morgan Lloyd wrote:
to ensure that the inner loop is parallelised to the greatest possible
extent, but that the outer loop is protected from reentry.
Of course you are right.
I did this example to show that the compiler magic should be able to
handle nested
Hi Sven,
On Sat, Sep 27, 2014 at 7:33 PM, Sven Barth pascaldra...@googlemail.com
wrote:
Huh? Delphi really prohibits such things inside the destructor? Would you
mind to share an example (possibly including error messages), please?
Sorry, I wasn't clear enough.
With prohibits I didn't
On 28.09.2014 21:00, Constantine Yannakopoulos wrote:
Hi Sven,
On Sat, Sep 27, 2014 at 7:33 PM, Sven Barth pascaldra...@googlemail.com
mailto:pascaldra...@googlemail.com wrote:
Huh? Delphi really prohibits such things inside the destructor?
Would you mind to share an example
Mark Morgan Lloyd schrieb:
Boian Mitov wrote:
I think parallel processing belongs in library implementations.
I have reservations, based in part on the fact that other language
implementations are prepared to assume responsibility for
parallelisation, in part on experience with e.g. APL
If the time spent in this thread had been spent in coding, FPC would have
already ARC. The list has
approx. 600 members, 200 message were written. If each of the 600 members spent
on average 1 min
reading this thread, this is 2000 man-hour, i. e. approx. 1 MY :)
I strongly agree!
On 27 Sep 2014 12:23, Florian Klämpfl flor...@freepascal.org wrote:
If the time spent in this thread had been spent in coding, FPC would have
already ARC. The list has
approx. 600 members, 200 message were written. If each of the 600 members
spent on average 1 min
reading
Hans-Peter Diettrich wrote:
Mark Morgan Lloyd schrieb:
Boian Mitov wrote:
I think parallel processing belongs in library implementations.
I have reservations, based in part on the fact that other language
implementations are prepared to assume responsibility for
parallelisation, in part
On 26.09.2014 22:36, Boian Mitov wrote:
See... this is the point. In order to properly implement parallel loops
etc. even in their limited form the compiler needs specific RTL support.
So we break one of the basic principles that the compiler is the root,
and the RTL is a library compiled in it.
On 25.09.2014 20:13, Chriss Kalogeropoulos wrote:
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
On 27.09.2014 12:22, Florian Klämpfl wrote:
If the time spent in this thread had been spent in coding, FPC would have
already ARC. The list has
approx. 600 members, 200 message were written. If each of the 600 members spent
on average 1 min
reading this thread, this is 2000 man-hour, i. e.
Florian Klämpfl schrieb:
If the time spent in this thread had been spent in coding, FPC would have
already ARC. The list has
approx. 600 members, 200 message were written. If each of the 600 members spent
on average 1 min
reading this thread, this is 2000 man-hour, i. e. approx. 1 MY :)
Sven Barth schrieb:
There are however some nasty problems inside constructors and
destructors, because Self is reference counted as well (and should be
after all as we don't want the instance to be destroyed behind our backs
suddenly).
IMO before the end of a constructor, and before the
On 27.09.2014 16:06, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
There are however some nasty problems inside constructors and
destructors, because Self is reference counted as well (and should
be after all as we don't want the instance to be destroyed behind our
backs suddenly).
IMO
On Sat, Sep 27, 2014 at 4:36 PM, Sven Barth pascaldra...@googlemail.com
wrote:
There are however some nasty problems inside constructors and destructors,
because Self is reference counted as well (and should be after all as we
don't want the instance to be destroyed behind our backs suddenly).
On 27.09.2014 17:00, Constantine Yannakopoulos wrote:
On Sat, Sep 27, 2014 at 4:36 PM, Sven Barth pascaldra...@googlemail.com
mailto:pascaldra...@googlemail.com wrote:
There are however some nasty problems inside constructors and
destructors, because Self is reference counted as well
In our previous episode, Sven Barth said:
It looks to me like inside methods Self doesn't deserve refcounting,
because a method can be invoked only with an existing instance, which
will stay alive at least until the call returns.
That's the thing I'm not yet entirely sure about. Though
Marco van de Voort schrieb:
In our previous episode, Sven Barth said:
It looks to me like inside methods Self doesn't deserve refcounting,
because a method can be invoked only with an existing instance, which
will stay alive at least until the call returns.
That's the thing I'm not yet entirely
On 27.09.2014 21:22, Hans-Peter Diettrich wrote:
Marco van de Voort schrieb:
In our previous episode, Sven Barth said:
It looks to me like inside methods Self doesn't deserve refcounting,
because a method can be invoked only with an existing instance, which
will stay alive at least until the
On 09/25/2014 05:11 PM, Sven Barth wrote:
Of course the user can see it.
But he does not _need_ to. :-)
Namely to introduce refcounting to classes where he/she can't
influence the parent class (simple example: a TStrings descendant)
Sounds like a great concept.
-Michael
On 09/25/2014 07:27 PM, Boian Mitov wrote:
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.
Of course I did understand that.
What I was saying that
On 09/25/2014 07:30 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.
As compare to the cost of other locking methods such as critical
sections that have to be implemented instead if the
On 09/25/2014 05:14 PM, Sven Barth wrote:
ARC objects will only be destroyed when the last reference to them has
gone out of scope. If there is still a reference, then there's still
the object.
I understood, the example showed that the object might survive even if
there is no reference any
Michael Schnell wrote:
On 09/25/2014 07:27 PM, Boian Mitov wrote:
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.
Of course I did understand that.
What I
On 09/26/2014 05:31 PM, Mark Morgan Lloyd wrote:
.
A parallel loop syntax is very attractive, but the practical
difficulty is that it would probably have to sit on top of threads and
getting code distributed promptly over multiple worker threads, i.e.
starting up within 10s of nSec rather
Michael Schnell wrote:
On 09/26/2014 05:31 PM, Mark Morgan Lloyd wrote:
.
A parallel loop syntax is very attractive, but the practical
difficulty is that it would probably have to sit on top of threads and
getting code distributed promptly over multiple worker threads, i.e.
starting up
---
-Original Message-
From: Michael Schnell
Sent: Friday, September 26, 2014 12:42 AM
To: fpc-devel@lists.freepascal.org
Subject: Re: [fpc-devel] Suggestion: reference counted objects
On 09/25/2014 07:30 PM, Boian Mitov wrote:
Strongly disagree...
You can't deny it. Please read some technical docs
---
-Original Message-
From: Michael Schnell
Sent: Friday, September 26, 2014 8:48 AM
To: fpc-devel@lists.freepascal.org
Subject: Re: [fpc-devel] Suggestion: reference counted objects
On 09/26/2014 05:31 PM, Mark Morgan Lloyd wrote:
.
A parallel loop syntax is very attractive
Boian Mitov wrote:
See... this is the point. In order to properly implement parallel loops
etc. even in their limited form the compiler needs specific RTL support.
So we break one of the basic principles that the compiler is the root,
and the RTL is a library compiled in it. Once you start
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
www.mitov.com
---
-Original Message-
From: Michael Schnell
Sent: Thursday, September 25, 2014 2:14 AM
To: fpc-devel@lists.freepascal.org
Subject: Re: [fpc-devel] Suggestion: reference counted objects
On 09/22/2014 08:51 PM, Boian Mitov wrote
---
Mitov Software
www.mitov.com
---
-Original Message-
From: Michael Schnell
Sent: Thursday, September 25, 2014 2:48 AM
To: fpc-devel@lists.freepascal.org
Subject: Re: [fpc-devel] Suggestion: reference counted objects
On 09/22/2014 08:34 PM
---
Mitov Software
www.mitov.com
---
-Original Message-
From: Michael Schnell
Sent: Thursday, September 25, 2014 2:59 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Suggestion
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
On Tue, Sep 23, 2014 at 10:47 PM, Boian Mitov mi...@mitov.com wrote:
Hmm... I have serious doubt the anonymous methods (actually referenced
objects as previously discussed) will be discouraged.
If anything they are more and more used across the majority of the
languages, as they have huge
: Wednesday, September 24, 2014 5:26 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Suggestion: reference counted objects
How about the maintenance cost?
Is it now easier-faster-safer to bring changes into the code without
introducing regressions?
thanks,
Dmitry
www.mitov.com
---
*From:* August Oktobar mailto:augustokto...@gmail.com
*Sent:* Tuesday, September 23, 2014 10:35 AM
*To:* FPC developers' list mailto:fpc-devel@lists.freepascal.org
*Subject:* Re: [fpc-devel] Suggestion: reference counted objects
: [fpc-devel] Suggestion: reference counted objects
On 09/23/2014 08:47 PM, Boian Mitov wrote:
This is a valid point.
The only downside is that the object will every time do a deep copy versus a
shallow (pointer only) copy. Deep copy is very, very expensive operation.
Adding ref. counting
In our previous episode, Boian Mitov said:
As I already stated, those are the same arguments that I have heard 30
years ago when people ware asking me why I would use C instead of doing it
like them in Assembler.
OTOH the more radical people in then that said we would all be doing LISP by
now
In our previous episode, Boian Mitov said:
You have a data object that needs to be processed by 600 threads, and when
they all have consumed(finished with it) it, it needs to be disposed.
I do this all the time, but I don't recognize that at all.
Usually one in such case has 600 objects with
Il 22/09/2014 23:04, Boian Mitov ha scritto:
If you are experienced in parallel processing, you should know the
answer.
This is a huge topic, and I have done number of sessions on some
aspects of it, but here will give you a small example (again this is
just a small example).
You have a data
Am 23.09.2014 11:11 schrieb Giuliano Colla giuliano.co...@fastwebnet.it:
You have a number of threads creating thousands of data objects, which
should be processed by consumer threads. Creating threads are unaware of
how data will be used (it may depend on active options, and it follows the
Message-
From: Sven Barth
Sent: Monday, September 22, 2014 10:49 PM
To: fpc-devel@lists.freepascal.org
Subject: Re: [fpc-devel] Suggestion: reference counted objects
They are however only accessed through the implicitely generated
interface and not through some object instance and thus the class
---
Mitov Software
www.mitov.com
---
-Original Message-
From: Giuliano Colla
Sent: Tuesday, September 23, 2014 2:11 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Suggestion: reference counted
---
From: Sven Barth
Sent: Tuesday, September 23, 2014 6:06 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Suggestion: reference counted objects
Am 23.09.2014 11:11 schrieb Giuliano Colla giuliano.co...@fastwebnet.it:
You have a number of threads creating thousands
On Tue, Sep 23, 2014 at 1:11 PM, Boian Mitov mi...@mitov.com wrote:
Hi Sven,
There is no one list.
We have N number o data sources of many different types. The data from
each source is processed in a pipeline of threads that cane be reconfigured
at any time.
New sources and new data
On Tue, Sep 23, 2014 at 1:22 PM, silvioprog silviop...@gmail.com wrote:
On Tue, Sep 23, 2014 at 1:11 PM, Boian Mitov mi...@mitov.com wrote:
Hi Sven,
There is no one list.
We have N number o data sources of many different types. The data from
each source is processed in a pipeline of
developers' list
Subject: Re: [fpc-devel] Suggestion: reference counted objects
Is OpenWire compatible with FPC?
--
Silvio Clécio
My public projects - github.com/silvioprog
---
From: silvioprog
Sent: Tuesday, September 23, 2014 9:37 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Suggestion: reference counted objects
On Tue, Sep 23, 2014 at 1:22 PM, silvioprog silviop...@gmail.com wrote:
Is OpenWire compatible with FPC
Am 23.09.2014 18:11 schrieb Boian Mitov mi...@mitov.com:
There is no one list.
I was solely referring to Guiliano's example, not yours. ;)
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
,
Boian Mitov
---
Mitov Software
www.mitov.com
---
From: Sven Barth
Sent: Tuesday, September 23, 2014 10:04 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Suggestion: reference counted
Il 23/09/2014 18:00, Boian Mitov ha scritto:
Hi Giuliano,
I was not talking hypothetical example.
All of our products use this technology. Again, what you are telling
me is some suggestion for probable solution, but even when you do it,
you immediately add additional code and containers
To somebody (probably Sven):
In FPC there is concept of stack based objects (object) that behave like
classes (with inheritance)?
Why not just extend this object with support for constructors and
destructors, and there is no need for the ARC?
On Mon, Sep 22, 2014 at 2:05 PM, Hans-Peter Diettrich
---
-Original Message-
From: Giuliano Colla
Sent: Tuesday, September 23, 2014 10:26 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Suggestion: reference counted objects
Il 23/09/2014 18:00, Boian Mitov ha scritto:
Maybe I'm simple minded but I
---
Mitov Software
www.mitov.com
---
From: August Oktobar
Sent: Tuesday, September 23, 2014 10:35 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Suggestion: reference counted objects
On Tue, Sep 23, 2014 at 1:53 PM, Boian Mitov mi...@mitov.com wrote:
It used to be compatible, however since we rewrote it to use anonymous
methods, and attributes (And reduced the code to 1/4 of the original size
in the process) ~2 years ago, the new versions are not any more Lazarus
On Tue, Sep 23, 2014 at 1:55 PM, Boian Mitov mi...@mitov.com wrote:
If you read the history:
June 12, 2013 | 6.0 | Dropped Lazarus support due to lack of language
features.
It is not compatible any more :-( . Hope this will change.
With best regards,
Boian Mitov
---
-Original Message- From: Giuliano Colla
Sent: Tuesday, September 23, 2014 10:26 AM
To: FPC developers' list
Subject: Re: [fpc-devel] Suggestion: reference counted objects
Il 23/09/2014 18:00, Boian Mitov ha scritto:
Maybe I'm simple minded but I still have some pain understanding how a
producer thread
' list
Subject: Re: [fpc-devel] Suggestion: reference counted objects
Boian,
since you keep on repeating the false argument that reference counting
will somehow speed up parallel performance, I will restate the obvious:
using reference counting will decrease parallel performance for the
following
Am 23.09.2014 21:52 schrieb Peter Popov ppopo...@gmail.com:
4. ARC operations will likely involve virtual functions, which have
overhead and do cause pointer running.
There's no need for virtual methods for ARC. At least not in the design I
envisioned for my RFC.
Regards,
Sven
To: FPC developers' list
Subject: Re: [fpc-devel] Suggestion: reference counted objects
Am 23.09.2014 21:52 schrieb Peter Popov ppopo...@gmail.com:
4. ARC operations will likely involve virtual functions, which have
overhead and do cause pointer running.
There's no need for virtual methods for ARC
On the other hand without this you already mentioned that you will need
to create a list containing all the buffers. What is the performance
impact on adding, removing from the list? What about the support code?
What buffers? I destroy objects explicitly. The objects that need work
create
' list
Subject: Re: [fpc-devel] Suggestion: reference counted objects
Please, explain. The fundamental problem with virtual functions is pointer
running. If your VMT reference is in the cache, sure, calling is fast. If
object 1 execs a virtual to get object 2 who executes a virtual to get
object 3
On Tue, Sep 23, 2014 at 1:51 PM, silvioprog silviop...@gmail.com wrote:
On Tue, Sep 23, 2014 at 1:53 PM, Boian Mitov mi...@mitov.com wrote:
It used to be compatible, however since we rewrote it to use anonymous
methods, and attributes (And reduced the code to 1/4 of the original size
in
Maybe would be best to activate reference count only for specific classes
through a compiler directive. This way we can see this new feature in
production without breaking the existing code base and give the programmer
the flexibility to choose which classes must be freed automatically.
Best
1 - 100 of 234 matches
Mail list logo
