February 03, 2014
04-Feb-2014 00:21, Adam Wilson пишет:
> On Mon, 03 Feb 2014 12:02:29 -0800, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 2/3/14, 6:57 AM, Frank Bauer wrote:
>>> Anyone asking for the addition of ARC or owning pointers to D, gets
>>> pretty much ignored. The topic is "Smart pointers instead of GC?",
>>> remember? People here seem to be more interested in diverting to
>>> nullable, scope and GC optimization. Telling, indeed.
>>
>> I thought I made it clear that GC avoidance (which includes
>> considering built-in reference counting) is a major focus of 2014.
>>
>> Andrei
>>
>
...
> Sadly, although written as hyperbole, I feel that the above is fairly
> close to the actual position of the ARC crowd.
>

I won't be surprised that half of current GC problems are because it's simply too stupid as an allocator. I had some numbers that I'd need to dig up were GC.malloc was ~2x slower then malloc even with garbage collection disabled.

With that said I'd focus on ref-counting somehow coexisting with tracing GC. It doesn't go well at the moment - try creating dynamic arrays of std.stdio.File (that is ref-counted).

-- 
Dmitry Olshansky
February 03, 2014
On Monday, 3 February 2014 at 20:02:30 UTC, Andrei Alexandrescu wrote:
> I thought I made it clear that GC avoidance (which includes considering built-in reference counting) is a major focus of 2014.

Please make it so that you can easily write thread-level allocator agnostic code without passing the allocator around. E.g. so that you can start writing code with GC, but properly release memory, then when you are certain that your model does not introduce cycles replace it with a cheaper allocation model with no additional code changes.
February 03, 2014
On 2/3/14, 12:21 PM, Adam Wilson wrote:
> On Mon, 03 Feb 2014 12:02:29 -0800, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 2/3/14, 6:57 AM, Frank Bauer wrote:
>>> Anyone asking for the addition of ARC or owning pointers to D, gets
>>> pretty much ignored. The topic is "Smart pointers instead of GC?",
>>> remember? People here seem to be more interested in diverting to
>>> nullable, scope and GC optimization. Telling, indeed.
>>
>> I thought I made it clear that GC avoidance (which includes
>> considering built-in reference counting) is a major focus of 2014.
>>
>> Andrei
>>
>
> Andrei, I am sorry to report that anything other than complete removal
> of the GC and replacement with compiler generated ARC will be
> unacceptable to a certain, highly vocal, subset of D users.

Why would you be sorry? "It is what it is", "customer is always right" etc. If we deem that important then we should look into supporting that scenario.

> No arguments
> can be made to otherwise, regardless of validity. As far as they are
> concerned the discussion of ARC vs. GC is closed and decided. ARC is the
> only path forward to the bright and glorious future of D. ARC most
> efficiently solves all memory management problems ever encountered.
> Peer-Reviewed Research and the Scientific Method be damned! ALL HAIL ARC!
>
> Sadly, although written as hyperbole, I feel that the above is fairly
> close to the actual position of the ARC crowd.

I'm going on a limb here, but it seems you're not convinced :o).


Andrei


February 03, 2014
On Mon, 03 Feb 2014 12:40:20 -0800, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

> 04-Feb-2014 00:21, Adam Wilson пишет:
>> On Mon, 03 Feb 2014 12:02:29 -0800, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> On 2/3/14, 6:57 AM, Frank Bauer wrote:
>>>> Anyone asking for the addition of ARC or owning pointers to D, gets
>>>> pretty much ignored. The topic is "Smart pointers instead of GC?",
>>>> remember? People here seem to be more interested in diverting to
>>>> nullable, scope and GC optimization. Telling, indeed.
>>>
>>> I thought I made it clear that GC avoidance (which includes
>>> considering built-in reference counting) is a major focus of 2014.
>>>
>>> Andrei
>>>
>>
> ...
>> Sadly, although written as hyperbole, I feel that the above is fairly
>> close to the actual position of the ARC crowd.
>>
>
> I won't be surprised that half of current GC problems are because it's simply too stupid as an allocator. I had some numbers that I'd need to dig up were GC.malloc was ~2x slower then malloc even with garbage collection disabled.
>
> With that said I'd focus on ref-counting somehow coexisting with tracing GC. It doesn't go well at the moment - try creating dynamic arrays of std.stdio.File (that is ref-counted).
>

I will not defend the current GC, it is about as stupid as you can make one and still have a functioning memory management system. It implements exactly none of the optimizations recommended for Mark-Sweep GC's in the GC Handbook.

That said, I firmly believe that wholesale replacement of the GC is throwing the baby out with the bathwater. Effectively, the poor D GC implementation has become an excuse to launch a crusade against all GC's everywhere, never mind that Java and the .NET GC's are consistent examples of just how good GC's can actually be.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
February 03, 2014
Adam Wilson:

> I will not defend the current GC, it is about as stupid as you can make one and still have a functioning memory management system. It implements exactly none of the optimizations recommended for Mark-Sweep GC's in the GC Handbook.

Why don't you open an enhancement request for each of those recommended optimizations (explaining as well as possible what to do and how and what to expect from them)? I have opened several "obvious" enhancement requests, and I have seen them fixed in some time.

Bye,
bearophile
February 03, 2014
On Mon, 03 Feb 2014 12:51:20 -0800, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 2/3/14, 12:21 PM, Adam Wilson wrote:
>> On Mon, 03 Feb 2014 12:02:29 -0800, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> On 2/3/14, 6:57 AM, Frank Bauer wrote:
>>>> Anyone asking for the addition of ARC or owning pointers to D, gets
>>>> pretty much ignored. The topic is "Smart pointers instead of GC?",
>>>> remember? People here seem to be more interested in diverting to
>>>> nullable, scope and GC optimization. Telling, indeed.
>>>
>>> I thought I made it clear that GC avoidance (which includes
>>> considering built-in reference counting) is a major focus of 2014.
>>>
>>> Andrei
>>>
>>
>> Andrei, I am sorry to report that anything other than complete removal
>> of the GC and replacement with compiler generated ARC will be
>> unacceptable to a certain, highly vocal, subset of D users.
>
> Why would you be sorry? "It is what it is", "customer is always right" etc. If we deem that important then we should look into supporting that scenario.
>

There is a big difference between supporting a scenario, and forcing it down everyone's throats as The One True Path. I would actually get out an pull for supporting both, equally. Let me choose, I know more about the memory usage patterns of my cloud-based service than a game developer does. In some cases ARC is more efficient, in other cases, the extra effort required is more than I care to pay my programmers for. In fact, for all of our projects, the efficiency cost of the GC is microscopic compared to having to pay the developer/time cost of ARC or Manual management. There is a reason we are an exclusively C# shop right now. And Apple/Obj-C has consistently proved that all the hype about ARC being more efficient for free is untrue. There are plenty of complaints in that camp about having to hunt down heisenleaks based on ARC leaking because somebody forgot to mark something as weak.

>> No arguments
>> can be made to otherwise, regardless of validity. As far as they are
>> concerned the discussion of ARC vs. GC is closed and decided. ARC is the
>> only path forward to the bright and glorious future of D. ARC most
>> efficiently solves all memory management problems ever encountered.
>> Peer-Reviewed Research and the Scientific Method be damned! ALL HAIL ARC!
>>
>> Sadly, although written as hyperbole, I feel that the above is fairly
>> close to the actual position of the ARC crowd.
>
> I'm going on a limb here, but it seems you're not convinced :o).
>
>
> Andrei
>
>

Hehe, you might say that. I did buy the GC Handbook to learn more about GC's after all, not replace them with something that has demonstrable drawbacks. :-)

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
February 03, 2014
On Mon, Feb 03, 2014 at 12:52:53PM -0800, Adam Wilson wrote:
> On Mon, 03 Feb 2014 12:40:20 -0800, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
[...]
> >I won't be surprised that half of current GC problems are because it's simply too stupid as an allocator. I had some numbers that I'd need to dig up were GC.malloc was ~2x slower then malloc even with garbage collection disabled.
> >
> >With that said I'd focus on ref-counting somehow coexisting with tracing GC. It doesn't go well at the moment - try creating dynamic arrays of std.stdio.File (that is ref-counted).
> >
> 
> I will not defend the current GC, it is about as stupid as you can make one and still have a functioning memory management system. It implements exactly none of the optimizations recommended for Mark-Sweep GC's in the GC Handbook.
> 
> That said, I firmly believe that wholesale replacement of the GC is throwing the baby out with the bathwater. Effectively, the poor D GC implementation has become an excuse to launch a crusade against all GC's everywhere, never mind that Java and the .NET GC's are consistent examples of just how good GC's can actually be.
[...]

I vote for the wholesale replacement of the GC... with a better GC. :-P Preferably one that is on par with modern Java GC's.

I agree that the GC phobia of some people is a little overboard. It's what they need for their specific use case, but that doesn't really apply in other use cases for D. (And I'm not convinced that ARC is the be-all and end-all of memory management issues -- I've seen real-life examples of ARCs gone horribly, horribly wrong, whereas had a GC been used in the first place things wouldn't have gone down that route.)

Nevertheless, supporting both can't be a bad thing; after all, D is all about choice (it's a breath of fresh air to *not* have to shoehorn every square peg into the OO round hole, like you have to in Java), so having the choice to *not* use the GC is a net improvement IMO, even if most D users wouldn't care about the difference.


T

-- 
Маленькие детки - маленькие бедки.
February 03, 2014
On Monday, 3 February 2014 at 20:21:14 UTC, Adam Wilson wrote:
> On Mon, 03 Feb 2014 12:02:29 -0800, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 2/3/14, 6:57 AM, Frank Bauer wrote:
>>> Anyone asking for the addition of ARC or owning pointers to D, gets
>>> pretty much ignored. The topic is "Smart pointers instead of GC?",
>>> remember? People here seem to be more interested in diverting to
>>> nullable, scope and GC optimization. Telling, indeed.
>>
>> I thought I made it clear that GC avoidance (which includes considering built-in reference counting) is a major focus of 2014.
>>
>> Andrei
>>
>
> Andrei, I am sorry to report that anything other than complete removal of the GC and replacement with compiler generated ARC will be unacceptable to a certain, highly vocal, subset of D users. No arguments can be made to otherwise, regardless of validity. As far as they are concerned the discussion of ARC vs. GC is closed and decided. ARC is the only path forward to the bright and glorious future of D. ARC most efficiently solves all memory management problems ever encountered. Peer-Reviewed Research and the Scientific Method be damned! ALL HAIL ARC!
>
> Sadly, although written as hyperbole, I feel that the above is fairly close to the actual position of the ARC crowd.

No!! That seems quite arrogant! No one is trying to take your
toys away from you! We just ask that you allow us to play with
ours as we have done the same for you. It should be a two way
street. Just because you drive down it doesn't mean you own it.

Of course no one is demanding it be done, Anyone can choose to do
what they want. But many love D and what it does but are forced
to take the good with the bad... and there is no great reason for
that.

D has the potential to be one of those languages that have it
all. It can't when you keep it from growing. Removing the AGC
dependence that D has will be like giving water to a seed... and
we all want D to be successful, don't you?

After all, what's the harm in us both being able to play with our
toys? Or are you just the jealous time that doesn't like to see
anyone else happy?
February 03, 2014
On 2014-02-01 07:35:44 +0000, Manu said:

> On 1 February 2014 16:26, Adam Wilson <flyboynw@gmail.com> wrote:
> On Fri, 31 Jan 2014 21:29:04 -0800, Manu <turkeyman@gmail.com> wrote:
> 
> On 26 December 2012 00:48, Sven Over <dlang@svenover.de> wrote:
> 
>  std.typecons.RefCounted!T
> 
> core.memory.GC.disable();
> 
> 
> Wow. That was easy.
> 
> I see, D's claim of being a multi-paradigm language is not false.
> 
> 
> It's not a realistic suggestion. Everything you want to link uses the GC, and the language its self also uses the GC. Unless you write software in complete isolation and forego many valuable features, it's not a solution.
> 
> 
>  Phobos does rely on the GC to some extent. Most algorithms and ranges do not though.
> 
> 
> Running (library) code that was written with GC in mind and turning GC off
> doesn't sound ideal.
> 
> But maybe this allows me to familiarise myself more with D. Who knows, maybe I can learn to stop worrying and love garbage collection.
> 
> Thanks for your help!
> 
> 
> I've been trying to learn to love the GC for as long as I've been around
> here. I really wanted to break that mental barrier, but it hasn't happened.
> In fact, I am more than ever convinced that the GC won't do. My current #1
> wishlist item for D is the ability to use a reference counted collector in
> place of the built-in GC.
> You're not alone :)
> 
> I write realtime and memory-constrained software (console games), and for
> me, I think the biggest issue that can never be solved is the
> non-deterministic nature of the collect cycles, and the unknowable memory
> footprint of the application. You can't make any guarantees or predictions
> about the GC, which is fundamentally incompatible with realtime software.
> Language-level ARC would probably do quite nicely for the miscellaneous
> allocations. Obviously, bulk allocations are still usually best handled in
> a context sensitive manner; ie, regions/pools/freelists/whatever, but the
> convenience of the GC paradigm does offer some interesting and massively
> time-saving features to D.
> Everyone will always refer you to RefCounted, which mangles your types and
> pollutes your code, but aside from that, for ARC to be useful, it needs to
> be supported at the language-level, such that the language/optimiser is
> able to optimise out redundant incref/decref calls, and also that it is
> compatible with immutable (you can't manage a refcount if the object is
> immutable).
> 
> The problem isn't GC's per se. But D's horribly naive implementation, games are written on GC languages now all the time (Unity/.NET). And let's be honest, games are kind of a speciality, games do things most programs will never do.
> 
> You might want to read the GC Handbook. GC's aren't bad, but most, like the D GC, are just to simplistic for common usage today.
> 
> Maybe a sufficiently advanced GC could address the performance
> non-determinism to an acceptable level, but you're still left with the
> memory non-determinism, and the conundrum that when your heap
> approaches full (which is _always_ on a games console), the GC has to
> work harder and harder, and more often to try and keep the tiny little
> bit of overhead available.
> A GC heap by nature expects you to have lots of memory, and also lots
> of FREE memory.
> 
> No serious console game I'm aware of has ever been written in a language with a GC. Casual games, or games that don't attempt to raise the bar may get away with it, but that's not the industry I work in.

You can always force the GC to run between cycles in your game, and turn off automatic sweeps.  This is how most games operate nowadays. It's also probably possible to create a drop-in replacement for the GC to do something else.   I could see if being *VERY* useful to make the GC take a compile-time parameter to select which GC engine is used.


February 03, 2014
Andrei Alexandrescu wrote:

> 2. Work on Phobos to see what can be done about avoiding unnecessary allocation. Most likely we'll need to also add a @nogc flag.
>
> ...
>
> 4. Work on the core language and druntime to see how to seamlessly accommodate alternate GC mechanisms such as reference counting.
>
> ...
>
> I thought I made it clear that GC avoidance (which includes considering built-in reference counting) is a major focus of 2014.
>
> Andrei

My apologies then. Not apologizing for stressing this point over and over again, though :)

Just to steal some people's thunder: I want the GC to remain in D as it is. This is not hyperbole or cynicism. I mean it. Having the GC around to clean up after me for noncritical apps is a blessing. Adding ARC and owning pointers would make my (and others) day though.

BTW: Why is most everybody who doesn't like GC obsessed with ARC pointers? I like them for where they are appropriate. But what about a simpler owning pointer that frees automatically when it goes out of scope. It comes at exactly zero runtime cost, just as a "dumb" pointer. You don't have to drag a reference count around with you. It is just a pointer in memory. All its semantics are enforced at compile time. Throw borrowed pointers in the mix, i.e. references to owning pointers that become "frozen" while there are outstanding references to them, and you're all set.

I think this would really be necessary (and sufficient!) to get Rust off your back and whatever half baked language stuff MS is intentionally leaking these days. At least IMHO and others from the *vocal minority*.

I'm not quite sure that I understand what you mean by GC avoidance being a major focus of 2014 though. In the long term, can I look forward to writing an absolutely, like in 100 %, like in guaranteed, GC free D app with all of current D's and Phobos' features if I choose to? Or does it mean: well for the most part it will avoid the GC, but if you're unlucky the GC might still kick in if you don't pay attention and when you least expect it?