[fpc-devel] Suggestion: reference counted objects

[Boian Mitov]

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 object that needs to be processed by 600 threads, and when 
they all have consumed(finished with it) it, it needs to be disposed.
With ref counting you create the object send it to all threads, each thread 
has its own reference to the object.
When they all release the references the object is destroyed.

Even this very simple (again I don’t even involve pipelining or other 
threading nesting here) is much more difficult to implement without ref 
counting, and extremely error prone in traditional approaches.
In our case we pass objects between hundreds of threads performing variety 
of processing between them. Without Ref. Counting (in this case with 
interfaces), we would simply would not have been able to do that...
You can see our solutions here - www.mitov.com, and you can easily see the 
complexity of the parallel processing that takes place.

With best regards,
Boian Mitov

-------------------------------------------------------
Mitov Software
www.mitov.com
-------------------------------------------------------
-----Original Message----- 
From: Peter Popov
Sent: Monday, September 22, 2014 1:32 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Suggestion: reference counted objects


On Mon, 22 Sep 2014 21:34:34 +0300, Boian Mitov <mitov at mitov.com> wrote:

> Strongly disagree...
> For multithreading and parallel processing ARC is lifesaver. I have been 
> using it trough interfaces for 10 years already, and once I rewrote the 
> old code to use ARC it was a huge performance boost, and it keeps  getting 
> better.

What on earth has reference counting got to do with writing efficient
multi-threaded code? You obviously confuse parallel performance, which
reference counting will obviously degrade, with making some particular
coding style easier. And sure, if your threads don't use shared resources
they will be very parallel indeed.

If your argument is that by writing less code you have more time to
refactor code, therefore you write better algorithms, and they run better
- then this would be a valid point for your situation. However, one size
does not fit all. I am not going to re-profile code because suddenly
assignments will not only incur a (possibly virtual) function call but
also lock other threads even if for a cycle or two. Not to mention cache
misses because every time you assign a pointer its value must be fetched
from memory and incremented, therefore messing around with data which was
supposed to be in the cache. And screw other threads' caches.

To put it differently, ARC will seriously degrade applications which fill
the memory bus bandwidth, multi-threaded or otherwise. For such pieces of
code it should not be used.

Peter
_______________________________________________
fpc-devel maillist  -  fpc-devel at lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel