Re: NSSound Reimplementation

[Jamie Ramone]

On Thu, Jul 16, 2009 at 10:37 AM, David Chisnall<address@hidden> wrote:
> 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:
>
> http://en.wikipedia.org/wiki/Locality_of_reference
>
> 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.
>
> David
>

I see where you were going, sorry for the mix-up. I do understand what
locality means, I just thought you were talking about scope. My bad,
just an honest mistake so don't have a cow man :-P

Now, if the compiler optimized in such a way that small enough ivars
are packed together as one single piece of data, and the needed one is
accessed once loaded into a register then there would be a locality
problem by separating them. If not, the cache use increases by one
piece of data: the pointer to the object. The individual fields would
be accessed separately anyway in this case, whether whitin the object
or in two separate ones. So there is an increase it is only limited to
the ammount of different classes using the approach.

You say there's a problem if subclasses do the same, but that wouldn't
happen. The separate object for containing the ivars would only be in
the public classes of the library in question. There's no reason for a
programmer who makes use of that library to do so in any subclass,
except maby in those subclasses that are part of some other api API
and it's implementation is based on the former.

Now, one could optimize it by moving ivars up the hierarchy. But if
the superclasses are also public the ABI would break, and on the other
ones (non-public ones) the risk of having potentialy usless ivars,
thus increasing memory usage.

If the separate-object is used as proposed (not with the
non-optimization previously pointed out), the object's creation could
be delayed until one of those ivar's are needed i.e. a lazy approach.
This way the memory usage is minimal, as far as this aproach allows.

That macro puzzles me. Why would you have a macro to access and ivar
that way? Because if the code is a method then it is accessed as if it
were a global variable. If not then you should use an accessor method.
Trying to access them directly punches a hole in the OOP paradigm. If
you have to, then maybe you shouldn't use an OOP approach at all, but
rather wrap procedural code with an object layer.

Oh, one more thing, could you post a link to the documet(s) that
describe this non-fragile ivar mechanism. I haven't heard about it
until now and it sounds interesting.
-- 
Besos, abrazos, confeti y aplausos.
Jamie Ramone
"El Vikingo"