Hi Pieter,
I think I explained very clear.
1. Each reference assignment involves an atomic operation which, if used
often enough will cause threads to wait and waste cycles.
Correct you will lose ~3 assembly instructions (Interlocked
increment/decrement-exchange, and conditional)
It will happen only when you create a new reference which happens rather
rarely. The impact will be less that 0.0001% of performance and probably
many orders smaller
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?
I think your arguments are turning against you here.
2. Each reference assignment involves pulling the value referenced by a
pointer and incrementing/decrementing it. In the process you will mess up
with the cache of the current thread: data which was supposed to be in the
cache for real work will be invalidated because of the ARC operation.
The cache is a cache, the counter is part of the object you access, as long
as you will be accessing the object (trough the pointer) it will need to be
loaded into the cache, so I don't see any impact.
3. Already explained in 2.
4. Arc does not require virtual functions, however here is another
misconception. Contrary to popular belief, on most processors virtual
functions are executed faster than traditional functions.
I can explain you the reasons for that on assembly, and cache level, but I
think you can do your own research.
Now, it is good that you managed to reduce your code by a factor of 4.
Clearly this is not due to availability of ARC. Clearly what you do is not
the only thing that programming languages are used for. So, the
implication that we will all somehow benefit likewise if ARC is introduced
is simply ludicrous.
Everyone is entitled to their opinion. I share mine, and I share my
experience, and I even share some of my code as open source.
Others seem to prefer to just throw some imaginary arguments, not based on
real experimental work.
If you have done some benchmarks between ARC and non ARC based threading as
we have done, you can share them, and you can have something to back up some
of the claims you make.
I have a lot of code and products to back my claims, so I am not just
talking hot air, but a real concrete code, products and expertise.
With best regards,
Boian Mitov
-------------------------------------------------------
Mitov Software
www.mitov.com
-------------------------------------------------------
-----Original Message-----
From: Peter Popov
Sent: Tuesday, September 23, 2014 12:51 PM
To: FPC developers' 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 obvious reasons:
1. Each reference assignment involves an atomic operation which, if used
often enough will cause threads to wait and waste cycles.
2. Each reference assignment involves pulling the value referenced by a
pointer and incrementing/decrementing it. In the process you will mess up
with the cache of the current thread: data which was supposed to be in the
cache for real work will be invalidated because of the ARC operation.
3. The cache of other threads will be similarly affected, even if the
atomic operation does not involve other threads
4. ARC operations will likely involve virtual functions, which have
overhead and do cause pointer running.
In summary, in memory intensive code, where the bus bandwidth is fully
utilized, ARC is a serious problem because of 2-4. In CPU intensive code 1
is a problem.
Now, it is good that you managed to reduce your code by a factor of 4.
Clearly this is not due to availability of ARC. Clearly what you do is not
the only thing that programming languages are used for. So, the
implication that we will all somehow benefit likewise if ARC is introduced
is simply ludicrous.
Peter
On Tue, 23 Sep 2014 20:43:28 +0300, Boian Mitov <mi...@mitov.com> wrote:
Yes, our solutions are among the most advanced that currently exist, and
are on the cutting edge by any mean.
Most of the technologies are developed by us to solve problems
traditionally considered unsolvable ;-) .
This is what keeps us in business ;-) .
Most people do not understand how we can do what we do, but there is no
magic. It is all very well developed (I dear to say), and at the end very
simple code (Took many years to get it that simple :-D ).
With best regards,
Boian Mitov
-------------------------------------------------------
Mitov Software
www.mitov.com
-------------------------------------------------------
-----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 may manage to send an object to a one or more consumer
threads which a) are unknown to it, and b) may not yet exist. Again not
an hypothetical case. Just a different application frame.
Giuliano
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
