[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSSound Reimplementation

From: David Chisnall
Subject: Re: NSSound Reimplementation
Date: Thu, 16 Jul 2009 14:37:24 +0100

On 16 Jul 2009, at 14:23, Jamie Ramone wrote:

I'd like to chime in here and say that this approach IS actually a
good idea as :

1 ) it does solve the ABI change breakdown problem and

Except that it doesn't, it just hides it. Now people subclassing and referencing variables in the superclass need to explicitly cast a pointer to a structure. If this structure changes, they need to manually update their private copy of the ivars and if they don't thing break in exciting ways.

2 ) it is actually much easier to read because it's a prime example of
encapsulation and abstraction, so complexity is hidden.

It is not easier to read, because now you need a separate structure definition, every ivar access has to go via a macro which will look something like this:

#define ivar (((struct private_ivars*)_private)->ivar)

In no possible way is that clearer code.

So locality of reference is gone. It gets replaced by messaging an
object. OK. So what? Why depend on locality? Again, I'm hard pressed
to find an objective way to choose one over the other. If the API of
the messaged object is well defined then I find both forms of the code
to be equally understandable. But that's my opinion, some may agree
and others disagree. So this reasoning is also a bad one for judging
the approach.

Clearly you have no idea what locality of reference means.  See here:

In summary, for good performance you want data that is accessed together to be close together in memory. Both CPUs (via their cache architecture) and operating systems (via their paging strategy) optimise heavily for this case.

Having ivars dangled off on a separate structure means that we now need two cache lines per object instead of one. Actually, it's worse if you also factor in subclasses doing this because you need one cache line for the object and one for each of the subclass structures. This will increase cache churn considerably. This is very difficult to identify in a microbenchmark, but it affect performance in larger programs quite noticeably. These structures, being separately allocated and of different sizes, may well be on different pages meaning that you will end up with a lot of more swapping when you are low on memory, which completely cripples performance.

The correct solution is to declare no ivars other than ones you are willing to commit to maintaining in the future in the header, declare them all in the implementation file, and use non-fragile ivar support in the runtime, but this requires people to actually test my patch which adds this.

At the very least, we should just add an unused pointer for future expansion so that we can add new ivars later and not use this for ivars that are likely to remain stable for several releases.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]