[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSSound Reimplementation
Re: NSSound Reimplementation
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
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.
Re: NSSound Reimplementation, Richard Frith-Macdonald, 2009/07/16