NSSound Reimplementation

[David Chisnall]

On 16 Jul 2009, at 09:30, Richard Frith-Macdonald wrote:

> But ... going back to the issue of avoiding changes to ivars  
> breaking ABI in future releases ... the approach I currently favor  
> is having a *single* ivar in the public class.  This is a private id  
> variable referring to an instance of a private class which is used  
> to hold the real ivars.

I really don't like this approach.  It makes the code difficult to  
read, destroys locality of reference, and hurts performance.

Please, please, please, can other people test my non-fragile ivars  
patch so that we can get rid of ugly hacks like this and just not  
declare any ivars in the headers.  I posted it months ago and have had  
absolutely no reports of testing yet.

David


_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[Jamie Ramone]

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

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

The use here of encapsulation and abstraction are precisely (among
other reasons) why the object oriented paradigm exists. Leveraging
these concepts allow one to concentrate on a specific problem by
hiding away the details of the rest behind an API, that of the other
objects you're using from within whichever one you're working on. If
the code is hard to read then that api is not well defined, so the
real problem would be to redefine it so as to make it understandable
(read: actually usable). Depending on being able to see all (or most)
of the details at once is not a good idea. Another thing I might add
is that readability is something rather subjective (though there are
generalities like statistics to allow it to be an objective
measurement), so it shouldn't be used to choose or dismiss a program
writing method.

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.

The performance hurting one I like. This is something that CAN
actually be measured, so it's perfect for considering this approach.
Now, why exactly does it hurt performance? Is the amount lost so much
greater than the amount achieved by the overall algorithm used that it
performs slower than if that algorithm wasn't used? How fast does the
code need to be, minimally? These are the questions one should ask
(and answer) in order to move ahead here.

So I agree with Richard here. However, if no one else changes the code
and you do, and submit a patch as you did, and it does solve the
problems you're looking to solve, then I don't see why your patch
wouldn't be accepted.

--
Besos, abrazos, confeti y aplausos.
Jamie Ramone
"El Vikingo"


_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[David Chisnall]

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


_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[Richard Frith-Macdonald-2]

On 16 Jul 2009, at 11:24, David Chisnall wrote:

> On 16 Jul 2009, at 09:30, Richard Frith-Macdonald wrote:
>
>> But ... going back to the issue of avoiding changes to ivars  
>> breaking ABI in future releases ... the approach I currently favor  
>> is having a *single* ivar in the public class.  This is a private  
>> id variable referring to an instance of a private class which is  
>> used to hold the real ivars.
>
> I really don't like this approach.  It makes the code difficult to  
> read, destroys locality of reference, and hurts performance.
>
> Please, please, please, can other people test my non-fragile ivars  
> patch so that we can get rid of ugly hacks like this and just not  
> declare any ivars in the headers.  I posted it months ago and have  
> had absolutely no reports of testing yet.

Sorry, I just haven't had a chance to look at installing a new/
different compiler and working with that yet, though it really IS  
something I'd like to be playing with.

However, it doesn't really have any bearing on this issue because we  
have to develop code for the existing compiler and will need to do so  
as long as we continue to support it (gcc).

I honestly can't see gcc being dropped any time soon (in the first  
place we would want all GNUstep to have been working flawlessly with  
clang for a good long time... perhaps a year) before we could  
reasonably think of making Clang the preferred compiler, let alone  
deprecating or removing support for gcc, and in the second place there  
may be political considerations preventing it (though I think most of  
the core developers are less likely to be bothered about that than in  
many free software projects ).

I think we have to live within the limitations of gcc as long as we  
haven't deprecated it.

The nice thing about this particular scheme (a single instance  
variable in the public class pointing to another class containing the  
actual variables) is that it's clean and simple enough to make it  
*very* easy to change if/when we change compilers at a later date.



_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[Richard Frith-Macdonald-2]

On 16 Jul 2009, at 14:37, David Chisnall 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.

No ... people subclassing NEVER reference any variables of the  
superclass, because the superclass only contains a single instance  
variable, and that's declared @private.  Because the superclass only  
ever contains the single instance variable, it never changes with  
impementation details, and the ABI doesn't change.

>> 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)

Actually it's

#define private ((PrivateClass*)_private)

Then

    private->ivar = ...

Which can easily be converted to 'self->ivar' or just 'ivar' by a  
global replace when we want to change because we have non-fragile  
ivars available.



_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[Lars Sonchocky-Helldorf]

Am 16.07.2009 um 12:24 schrieb David Chisnall:

> On 16 Jul 2009, at 09:30, Richard Frith-Macdonald wrote:
>
>> But ... going back to the issue of avoiding changes to ivars  
>> breaking ABI in future releases ... the approach I currently favor  
>> is having a *single* ivar in the public class.  This is a private  
>> id variable referring to an instance of a private class which is  
>> used to hold the real ivars.
>
> I really don't like this approach.  It makes the code difficult to  
> read, destroys locality of reference, and hurts performance.
>
> Please, please, please, can other people test my non-fragile ivars  
> patch so that we can get rid of ugly hacks like this and just not  
> declare any ivars in the headers.  I posted it months ago and have  
> had absolutely no reports of testing yet.

Maybe it's not clear to everybody what benefits your patch  
introduces. So maybe it would be a good idea to give a short  
enumeration of all the gains to the broader public (I know you're  
good at writing technical articles since I read quite a few off  
them :-)).

>
> David

thanks,

        Lars


_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[Richard Frith-Macdonald-2]

On 16 Jul 2009, at 14:53, Richard Frith-Macdonald wrote:

>
> On 16 Jul 2009, at 14:37, David Chisnall 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.
>
> No ... people subclassing NEVER reference any variables of the  
> superclass, because the superclass only contains a single instance  
> variable, and that's declared @private.  Because the superclass only  
> ever contains the single instance variable, it never changes with  
> impementation details, and the ABI doesn't change.
>
>>> 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)
>
> Actually it's
>
> #define private ((PrivateClass*)_private)
>
> Then
>
>   private->ivar = ...
>
> Which can easily be converted to 'self->ivar' or just 'ivar' by a  
> global replace when we want to change because we have non-fragile  
> ivars available.

Thinking about it, this is actually very short/easy to do with the  
preprocessor to support both gcc and clang (though I think we'd need  
to comment it well) ...

eg.

#if clang
#define private self
@interface MyClass
{
#else
#define private ((MyClassPrivate*)_private)
@interface MyClassPrivate : NSObject
{
   @public
#endif
   // instance variables here
}
@end

#if !clang
@implementation MyClassPrivate
@end
#endif

@implementation MyClass
- (id) init
{
#if !clang
   _private = [MyPrivateClass new];
#endif
   // ivar initialisation here
   return self;
}
...
@end

So if we are building with clang then we use non-fragile ivars, but if  
we are building with gcc then we use the private class instance to  
store our ivars.
To make it even simpler when using the same model repeatedly, we could  
use macros and end up writing code like this:

GSBEGINPRIVATEIVARS(MyClass)
int var1;
char var2;
GSENDPRIVATEIVARS(MyClass)

@implementation MyClass
- (id) init
{
   GSCREATEPRIVATEIVARS(MyClass)
  ...
   return self;
}





_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[David Chisnall]

On 16 Jul 2009, at 17:41, Richard Frith-Macdonald wrote:

>
> On 16 Jul 2009, at 14:53, Richard Frith-Macdonald wrote:
>
>>
>> On 16 Jul 2009, at 14:37, David Chisnall 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.
>>
>> No ... people subclassing NEVER reference any variables of the  
>> superclass, because the superclass only contains a single instance  
>> variable, and that's declared @private.  Because the superclass  
>> only ever contains the single instance variable, it never changes  
>> with impementation details, and the ABI doesn't change.
>>
>>>> 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)
>>
>> Actually it's
>>
>> #define private ((PrivateClass*)_private)
>>
>> Then
>>
>>  private->ivar = ...
>>
>> Which can easily be converted to 'self->ivar' or just 'ivar' by a  
>> global replace when we want to change because we have non-fragile  
>> ivars available.
>
> Thinking about it, this is actually very short/easy to do with the  
> preprocessor to support both gcc and clang (though I think we'd need  
> to comment it well) ...
>
> eg.
>
> #if clang
> #define private self
> @interface MyClass
> {
> #else
> #define private ((MyClassPrivate*)_private)
> @interface MyClassPrivate : NSObject
> {
>  @public
> #endif
>  // instance variables here
> }
> @end
>
> #if !clang
> @implementation MyClassPrivate
> @end
> #endif
>
> @implementation MyClass
> - (id) init
> {
> #if !clang
>  _private = [MyPrivateClass new];
> #endif
>  // ivar initialisation here
>  return self;
> }
> ...
> @end
>
> So if we are building with clang then we use non-fragile ivars, but  
> if we are building with gcc then we use the private class instance  
> to store our ivars.
> To make it even simpler when using the same model repeatedly, we  
> could use macros and end up writing code like this:
>
> GSBEGINPRIVATEIVARS(MyClass)
> int var1;
> char var2;
> GSENDPRIVATEIVARS(MyClass)
>
> @implementation MyClass
> - (id) init
> {
>  GSCREATEPRIVATEIVARS(MyClass)
> ...
>  return self;
> }

Looks sensible.  Is anyone interested in adding non-fragile ABI  
support to GCC?  The initial implementation is in clang because GCC  
code hurts my brain, but I'd like to see both compilers support this.

David



_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[David Chisnall]

On 16 Jul 2009, at 17:26, Lars Sonchocky-Helldorf wrote:

> Maybe it's not clear to everybody what benefits your patch  
> introduces. So maybe it would be a good idea to give a short  
> enumeration of all the gains to the broader public (I know you're  
> good at writing technical articles since I read quite a few off  
> them :-)).

As I wrote in my first email, it provides the same benefits as Apple's  
non-fragile ABI:

You can add or re-arrange instance variables in a class without  
breaking the ABI.  You can also remove private instance variables.  
Instance variable offsets are now stored in a global variable, rather  
than being hard-coded, and are set when the class is loaded by the  
runtime.  This needs a small amount of compiler and runtime support.  
The runtime support was in the diff I sent to this list, the compiler  
support is in clang (and hopefully someone will add equivalent support  
to GCC).

Unlike the Apple implementation, it does not require the superclass to  
be compiled with the non-fragile ABI, so you can still compile GNUstep  
with the old ABI and then create subclasses of GNUstep classes  
compiled with the non-fragile ABI.  If you rearrange or add ivars in a  
GNUstep class, then the subclass will still work correctly, as long as  
it was compiled with -fnonfragile-abi.

David


_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[Riccardo Mottola-4]

Hey,
>
>> But ... going back to the issue of avoiding changes to ivars breaking
>> ABI in future releases ... the approach I currently favor is having a
>> *single* ivar in the public class.  This is a private id variable
>> referring to an instance of a private class which is used to hold the
>> real ivars.
>
> I really don't like this approach.  It makes the code difficult to
> read, destroys locality of reference, and hurts performance.

I don't like it either! I think it was discussed quite a bit and we did
not agree that it was the way to go! The discussion didn't come to a
conclusion (I remember we also discussed it at FOSDEM), but many agreed
that this opaque single-ivar solution was bad.

I personally would prefer just breaking the ABI if other solutions are a
too big effort. Second place of course is David's. I cannot remember now
why i didn't try it though... did your patch have some prerequisites?

Riccardo



_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[Riccardo Mottola-4]

Hi,

>
>
> 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.

Agreed.

--R



_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[Riccardo Mottola-4]

Hi,
>
> Sorry, I just haven't had a chance to look at installing a
> new/different compiler and working with that yet, though it really IS
> something I'd like to be playing with.
>
> However, it doesn't really have any bearing on this issue because we
> have to develop code for the existing compiler and will need to do so
> as long as we continue to support it (gcc).
>
Yes, I remember a caveat: that was it, no gcc support. As a GNU project
I'd be quite waey to drop gcc support.
As for testing the patch, clang is not available as a package in gentoo,
thus I was too lazy to install it in another way. This also marks the
diffusion of clang up to now though.


Riccardo


_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[Richard Frith-Macdonald-2]

On 16 Jul 2009, at 18:00, David Chisnall wrote:

> On 16 Jul 2009, at 17:26, Lars Sonchocky-Helldorf wrote:
>
>> Maybe it's not clear to everybody what benefits your patch  
>> introduces. So maybe it would be a good idea to give a short  
>> enumeration of all the gains to the broader public (I know you're  
>> good at writing technical articles since I read quite a few off  
>> them :-)).
>
> As I wrote in my first email, it provides the same benefits as  
> Apple's non-fragile ABI:
>
> You can add or re-arrange instance variables in a class without  
> breaking the ABI.  You can also remove private instance variables.  
> Instance variable offsets are now stored in a global variable,  
> rather than being hard-coded, and are set when the class is loaded  
> by the runtime.  This needs a small amount of compiler and runtime  
> support.  The runtime support was in the diff I sent to this list,  
> the compiler support is in clang (and hopefully someone will add  
> equivalent support to GCC).
>
> Unlike the Apple implementation, it does not require the superclass  
> to be compiled with the non-fragile ABI, so you can still compile  
> GNUstep with the old ABI and then create subclasses of GNUstep  
> classes compiled with the non-fragile ABI.  If you rearrange or add  
> ivars in a GNUstep class, then the subclass will still work  
> correctly, as long as it was compiled with -fnonfragile-abi.

One thing I don't understand about the whole issue of adding ivars is  
how it is supposed to work with key value coding since, in KVC you can  
get/set the value of an ivar by name, but with non-fragile ivars you  
can presumably have multiple ivars with the same name.  What does KVC  
do in that situation?


_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[David Chisnall]

On 16 Jul 2009, at 18:59, Richard Frith-Macdonald wrote:

> One thing I don't understand about the whole issue of adding ivars  
> is how it is supposed to work with key value coding since, in KVC  
> you can get/set the value of an ivar by name, but with non-fragile  
> ivars you can presumably have multiple ivars with the same name.  
> What does KVC do in that situation?

Break, probably.  It will find the first ivar with that name, which  
will be the one in the subclass.  You can, of course, avoid this  
problem by creating explicit accessors which KVC will find in  
preference to direct ivar access.

David


_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[David Chisnall]

On 16 Jul 2009, at 18:34, Riccardo Mottola wrote:

> Hi,
>>
>> Sorry, I just haven't had a chance to look at installing a new/
>> different compiler and working with that yet, though it really IS  
>> something I'd like to be playing with.
>>
>> However, it doesn't really have any bearing on this issue because  
>> we have to develop code for the existing compiler and will need to  
>> do so as long as we continue to support it (gcc).
>>
> Yes, I remember a caveat: that was it, no gcc support. As a GNU  
> project I'd be quite waey to drop gcc support.

As a GNU project, I'd hope that the GNU compiler collection would put  
some effort into supporting us!  Someone at Apple sent them patches  
for supporting declared properties over a year ago, and yet GCC still  
does not support any of the extensions added in OS X 10.5, which was  
released two years ago.

Snow Leopard is going to make heavy use of blocks and declared  
properties in the API, and if we want to remain compatible, we are  
going to need a compiler that supports these.  It would be really  
great if GCC would, but I have yet to see any evidence that anyone is  
still actively working on Objective-C support in GCC.  In the last two  
years, Clang has gone from having no Objective-C support to supporting  
most of Objective-C 2 on the GNU runtime, while GCC has not gained a  
single new Objective-C feature.

> As for testing the patch, clang is not available as a package in  
> gentoo, thus I was too lazy to install it in another way. This also  
> marks the diffusion of clang up to now though.

Building clang from source is pretty trivial.  It is the system  
compiler for FreeBSD 8 and is in packages for a number of Linux  
distributions and Free/OpenBSD.  Not sure about Solaris.  Clang 1.0 is  
being released with the next LLVM release (2.6, due in September).

David


_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[Jamie Ramone]

On Thu, Jul 16, 2009 at 10:37 AM, David Chisnall<theraven@...> 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"


_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[Stef Bidi]

The discussion seems to have settled a little, so I'll go ahead and ask the question... what approach should I be taking here?  I really do not have the know-how to chime in, and because of that will go with whatever is decided.  What Richard did with NSOperations seems easy enough, is that the direction we're going with?  I'm hearing a lot of stuff but nothing seems to be definite/written in stone.

David:
It's not that I don't want to try llvm/clang out, it's just that I don't have time!  Start in September I'll have even less time (starting grad school).  I'm trying my best to get this code out so I can at least have 1 - 1.5 months of bug hunting until I will be forced into a maintenance mode.  I'd really like to be able to try a lot of this stuff out, but I just can't, sorry.

Thanks
Stefan

_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[Gregory Casamento]

I am using this weekend to catch up on a number of patches that have
been pending.  I'll report back what I find on this.

GC

On Thursday, July 16, 2009, David Chisnall <theraven@...> wrote:

> On 16 Jul 2009, at 09:30, Richard Frith-Macdonald wrote:
>
>
> But ... going back to the issue of avoiding changes to ivars breaking ABI in future releases ... the approach I currently favor is having a *single* ivar in the public class.  This is a private id variable referring to an instance of a private class which is used to hold the real ivars.
>
>
> I really don't like this approach.  It makes the code difficult to read, destroys locality of reference, and hurts performance.
>
> Please, please, please, can other people test my non-fragile ivars patch so that we can get rid of ugly hacks like this and just not declare any ivars in the headers.  I posted it months ago and have had absolutely no reports of testing yet.
>
> David
>
>
> _______________________________________________
> Gnustep-dev mailing list
> Gnustep-dev@...
> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>

--
Gregory Casamento
Open Logic Corporation, Principal Consultant
## GNUstep Chief Maintainer
yahoo/skype: greg_casamento, aol: gjcasa
[phone] (Cell), [phone] (Home)


_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[Fred Kiefer]

David Chisnall schrieb:

> On 16 Jul 2009, at 18:34, Riccardo Mottola wrote:
>>> Sorry, I just haven't had a chance to look at installing a
>>> new/different compiler and working with that yet, though it really IS
>>> something I'd like to be playing with.
>>>
>>> However, it doesn't really have any bearing on this issue because we
>>> have to develop code for the existing compiler and will need to do so
>>> as long as we continue to support it (gcc).
>>>
>> Yes, I remember a caveat: that was it, no gcc support. As a GNU
>> project I'd be quite waey to drop gcc support.
>
> As a GNU project, I'd hope that the GNU compiler collection would put
> some effort into supporting us!  Someone at Apple sent them patches for
> supporting declared properties over a year ago, and yet GCC still does
> not support any of the extensions added in OS X 10.5, which was released
> two years ago.
>
> Snow Leopard is going to make heavy use of blocks and declared
> properties in the API, and if we want to remain compatible, we are going
> to need a compiler that supports these.  It would be really great if GCC
> would, but I have yet to see any evidence that anyone is still actively
> working on Objective-C support in GCC.  In the last two years, Clang has
> gone from having no Objective-C support to supporting most of
> Objective-C 2 on the GNU runtime, while GCC has not gained a single new
> Objective-C feature.

David,

your mail got me thinking, I wont switch to Clang and I don't hope
GNUstep as a project will. So the only option forward is to start
working on better Objective-C support in gcc. I surely wont have time
for this beside my maintainer task on GNUstep, but this seems currently
the more important task. I will have a look at the code in gcc that
supports Objective-C and if I am able to make any sense of it, I might
switch over to work on that.

Cheers
Fred


_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[David Chisnall]

Hi Fred,

On 18 Jul 2009, at 19:23, Fred Kiefer wrote:

> your mail got me thinking, I wont switch to Clang and I don't hope
> GNUstep as a project will. So the only option forward is to start
> working on better Objective-C support in gcc. I surely wont have time
> for this beside my maintainer task on GNUstep, but this seems  
> currently
> the more important task. I will have a look at the code in gcc that
> supports Objective-C and if I am able to make any sense of it, I might
> switch over to work on that.

That would be great.  It's not a task for the faint hearted though.  
You can find all of the GCC Objective-C code in this file:

http://gcc.gnu.org/viewcvs/trunk/gcc/objc/objc-act.c?revision=149722&view=markup

There seem to be two functions in this file related to ivar access /  
assignment, so it ought to be relatively easy for anyone familiar with  
GCC internals to add non-fragile ivar support.  You also need to  
modify the ivar structure initialiser to contain negative values for  
the offsets (this is the hint I give to the runtime to indicate that  
this compilation unit provides support for non-fragile ivars and needs  
the offsets updated accordingly).

David


_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev