[fpc-devel] Suggestion: reference counted objects

[Boian Mitov]

  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 <mitov at 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 at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at 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 at lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel