[fpc-devel] Suggestion: reference counted objects
Peter Popov
ppopov99 at gmail.com
Wed Sep 24 00:54:51 CEST 2014
> 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 and destroy threads, not the other way around. Think of
computational geometry algorithms, for example.
> 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.
>
You pull a lot of data continuously, stored in objects with carefully
aligned data fields. You execute a bunch of floating point instructions on
data from several related objects. You change an object's field, then
nearby fields, are invalidated from cache across threads.
> 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.
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 ... etc than you have a major problem. What are you going to do,
keep all VMTs for all objects in the cache?
More information about the fpc-devel
mailing list