On 4/18/2014 2:46 AM, Manu via Digitalmars-d wrote:
> Consensus is that there's no performant GC available to D either.

Switching from one non-performant system to another won't help matters.


> Can you show that Obj-C suffers serious performance penalty from it's ARC
> system? Have there been comparisons?

O-C doesn't use ARC for all pointers, nor is it memory safe.


> Java is designed to be GC compatible from the ground up. D is practically
> incompatible with GC in the same way as C, but it was shoe-horned in there anyway.

This isn't quite correct. I implemented a GC for Java back in the 90's. D has semantics that are conducive to GC that C doesn't have, and this was done based on my experience with GC's. To wit, objects can't have internal references, so that a moving collector can be implemented.


> Everyone that talks about fantasy 'awesome-GC's admits it would be impossible to
> implement in D for various reasons.

The same goes for fantasy ARC :-)


>     inc/dec isn't as cheap as you imply. The dec usually requires the creation
>     of an exception handling unwinder to do it.
> Why do you need to do that?

Because if a function exits via a thrown exception, the dec's need to happen.


> Why do you have such a strong opposition if this is the case?

Because I know what kind of code will have to be generated for it.


> But you're always talking about how D creates way less garbage than other
> languages, which seems to be generally true. It needs to be tested before you
> can make presumptions about performance.

ARC, in order to be memory safe, would have to be there for ALL pointers, not just allocated objects.


> Well, I'd like to see it measured in practise. But most common scenarios I
> imagine appear like they'd eliminate nicely.
> pure, and perhaps proper escape analysis (planned?) offer great opportunity for
> better elimination than other implementations like Obj-C.

If you're not aware of the exception handler issue, then I think those assumptions about performance are unwarranted. Furthermore, if we implement ARC, then it is way too slow, then D simply loses its appeal. We could then spend the next 5 years attempting to produce a "sufficiently smart compiler" to buy that performance back, and by then it will be far too late.


>     First off, now pointers are 24 bytes in size. Secondly, every pointer
>     dereference becomes two dereferences (not so good for cache performance).
> That's not necessarily true. What length is the compiler typically able to
> eliminate inc/dec pairs? How many remain in practise? We don't know.

Yes, we don't know. We do know that we don't have an optimizer that will do that, and we know that GDC and LDC won't do it either, because those optimizers are designed for C++, not ARC.


> The performance is to be proven. Under this approach, you'd bunch references up
> close together, so there's a higher than usual probability the rc will be in
> cache already.
> I agree, it's theoretically a problem, but I have no evidence to show that it's
> a deal breaker. In lieu of any other options, it's worth exploring.

I'm just stunned you don't find the double indirection of rc a problem, given your adamant (and correct) issues with virtual function call dispatch.


> Well the alternative is to distinguish them in the type system.

There's a dramatic redesign of D.


> I don't feel like you've given me any evidence that ARC in not feasible. Just
> that you're not interested in trying it out.
> Please, kill it technically. Not just with dismissal and FUD.

I've given you technical reasons. You don't agree with them, that's ok, but doesn't mean I have not considered your arguments, all of which have come up before. See the thread for the previous discussion on this. It's not like I haven't tried.

http://forum.dlang.org/thread/l34lei$255v$1@digitalmars.com

Walter Bright:

> dmd could do a better job of escape analysis, and do this automatically.

Timon has kindly fixed the wrong part I wrote in the DIP60. But if we introduce some basic escape analysis required by all conformant D compilers, then the @nogc attribute can be applied to some functions that define array literals or more (so my comment becomes true in some specified cases). Thankfully this is something that can be done later, as such improvements just relax the strictness of @nogc.

Bye,
bearophile

On Fri, 18 Apr 2014 16:40:06 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> This isn't quite correct. I implemented a GC for Java back in the 90's. D has semantics that are conducive to GC that C doesn't have, and this was done based on my experience with GC's. To wit, objects can't have internal references, so that a moving collector can be implemented.

This isn't correct. Only structs cannot have internal references. Objects don't move or copy so easily.

Not only that, but internal pointers would not prevent a moving GC.

>> I don't feel like you've given me any evidence that ARC in not feasible. Just
>> that you're not interested in trying it out.
>> Please, kill it technically. Not just with dismissal and FUD.
>
> I've given you technical reasons. You don't agree with them, that's ok, but doesn't mean I have not considered your arguments, all of which have come up before. See the thread for the previous discussion on this. It's not like I haven't tried.
>
> http://forum.dlang.org/thread/l34lei$255v$1@digitalmars.com
>

Note, there are much more practical reasons to enable reference counting -- interoperating natively with Objective-C and iOS/MacOS.

-Steve

On 2014-04-18 20:40:06 +0000, Walter Bright <newshound2@digitalmars.com> said:

> O-C doesn't use ARC for all pointers, nor is it memory safe.

@safe would be very easy to implement in Objective-C now that ARC is there.

This has got me thinking. Ever heard "C is the new assembly"? I think this describes very well the relation between C and Objective-C in most Objective-C programs today.

Objective-C enables ARC by default for all pointers to Objective-C objects. Since virtually all Objective-C APIs deal with Objective-C objects (or integral values), if you limit yourself to Objective-C APIs you're pretty much memory-safe.

When most people write Objective-C programs, they use exclusively Objective-C APIs (that deal with Objective-C objects and integrals, thus memory-safe), except for the few places where performance is important (tight loops, specialized data structures) or where Objective-C APIs are not available.

You can mix and match C and Objective-C code, so no clear boundary separates the two, but that doesn't mean there couldn't be one. Adding a @safe function attribute to Objective-C that'd prevent you from touching a non-managed pointer is clearly something I'd like to see in Objective-C. Most Objective-C code I know could already be labeled @safe with no change. Only a small fraction would have to be updated or left unsafe.

Silly me, here I am discussing a improvement proposal for Objective-C in a D forum!

The point being, D could have managed and unmanaged pointers (like Objective-C with ARC has), make managed pointers the default, and let people escape pointer management if they want to inside @system/@trusted functions. One way it could be done is by tagging specific pointers with some attribute to make them explicitly not managed (what __unsafe_unretained is for in Objective-C). Perhaps the whole function could be tagged too. But you won't need this in general, only when optimizing a tight loop or something similar where performance really counts.

Whether that's the path D should take, I don't know.


-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On Friday, 18 April 2014 at 20:24:51 UTC, Walter Bright wrote:
> On 4/18/2014 10:54 AM, John Colvin wrote:
>> My understanding is that a more sophisticated GC will also not coexist quite so
>> peacefully with pointers of all types. Is it not the conservativeness* of the GC
>> that enables this coexistence?
>
> Yes. Which is one reason why D doesn't emit write gates for indirect assignment.

Which, if any, of the more sophisticated GC designs out there - in your opinion - would work well with D? Perhaps more importantly, which do you see as *not* working well with D.

On 4/18/2014 1:58 PM, Steven Schveighoffer wrote:
> This isn't correct. Only structs cannot have internal references. Objects don't
> move or copy so easily.

Objects can't have internal references either, for the same reason.


> Not only that, but internal pointers would not prevent a moving GC.

They would just make it much more costly, as one would have to detect them at runtime.


> Note, there are much more practical reasons to enable reference counting --
> interoperating natively with Objective-C and iOS/MacOS.

Right, but that isn't pervasive ARC.

On 4/18/2014 3:02 PM, Michel Fortin wrote:
> Objective-C enables ARC by default for all pointers to Objective-C objects.
> Since virtually all Objective-C APIs deal with Objective-C objects (or integral
> values), if you limit yourself to Objective-C APIs you're pretty much memory-safe.

"pretty much" isn't really what we're trying to achieve with @safe.


> The point being, D could have managed and unmanaged pointers (like Objective-C
> with ARC has), make managed pointers the default, and let people escape pointer
> management if they want to inside @system/@trusted functions.

Yeah, it could, and the design of D has tried really hard to avoid such. "Managed C++" was a colossal failure.

I've dealt with systems with multiple pointer types before (16 bit X86) and I was really, really happy to leave that **** behind.

On Fri, 18 Apr 2014 16:48:43 -0700, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/18/2014 3:02 PM, Michel Fortin wrote:
>> Objective-C enables ARC by default for all pointers to Objective-C objects.
>> Since virtually all Objective-C APIs deal with Objective-C objects (or integral
>> values), if you limit yourself to Objective-C APIs you're pretty much memory-safe.
>
> "pretty much" isn't really what we're trying to achieve with @safe.
>
>
>> The point being, D could have managed and unmanaged pointers (like Objective-C
>> with ARC has), make managed pointers the default, and let people escape pointer
>> management if they want to inside @system/@trusted functions.
>
> Yeah, it could, and the design of D has tried really hard to avoid such. "Managed C++" was a colossal failure.
>
> I've dealt with systems with multiple pointer types before (16 bit X86) and I was really, really happy to leave that **** behind.
>

Managed C++ was a colossal failure due to it's extreme verbosity. C++/CLI and C++/CX are much tighter and more importantly NOT failures. I use C++/CLI in production code, and yes, you have to be careful, it's easy to get wrong, but it does work.

Note: that I am not advocating this for D and I think that avoiding it is the correct approach. But it wasn't a failure once the more obvious design flaws got worked out.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

On 4/18/2014 3:10 PM, John Colvin wrote:
> On Friday, 18 April 2014 at 20:24:51 UTC, Walter Bright wrote:
>> On 4/18/2014 10:54 AM, John Colvin wrote:
>>> My understanding is that a more sophisticated GC will also not coexist quite so
>>> peacefully with pointers of all types. Is it not the conservativeness* of the GC
>>> that enables this coexistence?
>>
>> Yes. Which is one reason why D doesn't emit write gates for indirect assignment.
>
> Which, if any, of the more sophisticated GC designs out there - in your opinion
> - would work well with D? Perhaps more importantly, which do you see as *not*
> working well with D.

Ones that imply intrusive code gen changes won't work well with D. D is not Java, and does not have Java's every-pointer-is-a-gc-pointer semantics, not even remotely.

On 4/18/2014 4:58 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> TLS sucks, as you get extra indirections if it isn't implemented using a MMU
> (typically not because the extra page tables would cost too much?).

You shouldn't be using global data anyway. Most TLS references will be to the heap or stack, which has no extra cost.