On 10/8/13 8:45 PM, Walter Bright wrote:
> On 10/8/2013 8:38 PM, Andrei Alexandrescu wrote:
>> Only Levenshtein distance produces garbage in std.algorithm.
>
> Perhaps the documentation should reflect that:
>
> http://dlang.org/phobos/std_algorithm.html#levenshteinDistance

I'll need to fix the function to use RefCounted.

Andrei

On Tue, 08 Oct 2013 19:22:34 -0700
Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
> It's clear that the perception of GC will not change soon, however good or not the arguments may be as applied to various situations and projects. It is also a reality that our GC is slow.
> 
> So we need to attack this problem from multiple angles:
> 
> * Make RefCounted work as immutable data. There will be a casting away of immutability in there, but since it's under the aegis of the standard library, it is admissible. All implementations must ensure RefCounted works.
> 
> * Add reference counted slice and associative array types that are as close as humanly possible to the built-in ones.
> 
> * Advertise all of the above in a top module such as std.refcounted. It's amazing how many D programmers have no idea RefCounted even exists.
> 
> * Review all of Phobos for hidden allocations and make appropriate decisions on how to give the user more control over allocation. I have some idea on how that can be done, at various disruption costs.
> 
> * Get Robert Schadek's precise GC in. Walter and I have become 101% convinced a precise GC is the one way to go about GC.
> 
> I'm up to my neck in D work for Facebook so my time is well spent. We must definitely up the ante in terms of development speed, and pronto.
> 

Unless the eventual allocator stuff would make special refcounted slices/AAs redundant (which actually wouldn't be too terrible, really), then I think all that sounds great. Add in a simple way to do full closures without GC allocation and it'd be a big win.

However, even with all that, I still feel it would be in D's best interest to have a trivial[1] way to guarantee no GC allocations *at least* on a whole-program level, if not also on a finer-grained basis.

*Even if* it's successfully argued that "no GC" is rarely, if ever,
a valid requirement (which I find questionable anyway), it's *still*
an important feature for D *just because* there's so much demand for
it. When your goal is to successfully market something, there *is*
value in fulfilling a common need, even if it's just a perceived need.
(But again, I'm not claiming "no GC" to be an imaginary need. Just
saying that it really doesn't matter if it's imagined or real. The
mere demand for it makes it a legitimate concern.)

[1] "Trival" == Doesn't require the user to modify or replace anything in druntime or phobos, and all violations are automatically caught at compiletime.

On Wednesday, 9 October 2013 at 03:46:16 UTC, Andrei Alexandrescu wrote:
> On 10/8/13 8:31 PM, Walter Bright wrote:
>> On 10/8/2013 8:18 PM, deadalnix wrote:
>>> We also badly need to be able to use type qualifier. We must
>>> stop the world when collecting thread local data or immutable one.
>>> That do not
>>> make any sense.
>>
>> Making this work is fraught with difficulty. It is normal behavior in D
>> to create local data with new(), build a data structure, and then cast
>> it to shared so it can be transferred to another thread.
>
> Stop right there. NO. That is NOT normal behavior, and if we require it in order to work we have made a mistake.
>
> There should be NO casting required to get work done in client code.
>

I have to concur with Andrei on that one. The win is simply so big that we can't ignore it. I you really want to do something like that, you can allocate as shared, cast to TL build the structure and cast back to shared.

When you break the type system, all guarantee are thrown away, and breaking it twice won't make thing worse at this point.

That being said, isolated is probably something we want to add in the future.

On Tuesday, October 08, 2013 20:46:16 Andrei Alexandrescu wrote:
> On 10/8/13 8:31 PM, Walter Bright wrote:
> > On 10/8/2013 8:18 PM, deadalnix wrote:
> >> We also badly need to be able to use type qualifier. We must
> >> stop the world when collecting thread local data or immutable one.
> >> That do not
> >> make any sense.
> > 
> > Making this work is fraught with difficulty. It is normal behavior in D to create local data with new(), build a data structure, and then cast it to shared so it can be transferred to another thread.
> 
> Stop right there. NO. That is NOT normal behavior, and if we require it in order to work we have made a mistake.
> 
> There should be NO casting required to get work done in client code.

Except that for the most part, that's the only way that immutable objects can be created - particularly if you're talking about arrays or AAs. It's _very_ common to do what Walter is describing. On top of that, we're forced to cast to immutable or shared to pass anything via std.concurrency, which causes pretty much the same problem. We're not even vaguely set up at this point to have type qualifiers indicate how something was constructed or what thread it comes from.

- Jonathan M Davis

On 10/8/13 9:24 PM, Jonathan M Davis wrote:
> On Tuesday, October 08, 2013 20:46:16 Andrei Alexandrescu wrote:
>> On 10/8/13 8:31 PM, Walter Bright wrote:
>>> On 10/8/2013 8:18 PM, deadalnix wrote:
>>>> We also badly need to be able to use type qualifier. We must
>>>> stop the world when collecting thread local data or immutable one.
>>>> That do not
>>>> make any sense.
>>>
>>> Making this work is fraught with difficulty. It is normal behavior in D
>>> to create local data with new(), build a data structure, and then cast
>>> it to shared so it can be transferred to another thread.
>>
>> Stop right there. NO. That is NOT normal behavior, and if we require it
>> in order to work we have made a mistake.
>>
>> There should be NO casting required to get work done in client code.
>
> Except that for the most part, that's the only way that immutable objects can
> be created - particularly if you're talking about arrays or AAs. It's _very_
> common to do what Walter is describing. On top of that, we're forced to cast
> to immutable or shared to pass anything via std.concurrency, which causes
> pretty much the same problem. We're not even vaguely set up at this point to
> have type qualifiers indicate how something was constructed or what thread it
> comes from.
>
> - Jonathan M Davis

The way I see it we must devise a robust solution to that, NOT consider the state of the art immutable (heh, a pun).

Andrei

On Wednesday, 9 October 2013 at 04:24:23 UTC, Jonathan M Davis wrote:
> Except that for the most part, that's the only way that immutable objects can
> be created - particularly if you're talking about arrays or AAs. It's _very_
> common to do what Walter is describing. On top of that, we're forced to cast
> to immutable or shared to pass anything via std.concurrency, which causes
> pretty much the same problem. We're not even vaguely set up at this point to
> have type qualifiers indicate how something was constructed or what thread it
> comes from.
>

As said, we can update the runtime interface while having everything allocated in the same pool.

On Wednesday, 9 October 2013 at 03:46:20 UTC, Walter Bright wrote:
> On 10/8/2013 8:38 PM, Andrei Alexandrescu wrote:
>> Only Levenshtein distance produces garbage in std.algorithm.
>
> Perhaps the documentation should reflect that:
>
> http://dlang.org/phobos/std_algorithm.html#levenshteinDistance

I think it would be useful to specify what uses GC on top of every Phobos' module documentation.

On 9 October 2013 08:58, ponce <contact@gmsfrommars.fr> wrote:

> On Tuesday, 8 October 2013 at 22:45:51 UTC, Adam D. Ruppe wrote:
>
>>
>> Eh, not necessarily. If it expands to static assert(!__traits(**hasAnnotationRecursive,
>> uses_gc));, then the only ones that *need* to be marked are the lowest
>> level ones. Then it figures out the rest only on demand.
>>
>> Then, on the function you care about as a user, you say nogc and it tells you if you called anything and the static assert stacktrace tells you where it happened.
>>
>> Of course, to be convenient to use, phobos would need to offer non-allocating functions, which is indeed a fair amount of work, but they wouldn't *necessarily* have to have the specific attribute.
>>
>
> But is it even necessary? There isn't a great deal of evidence that someone interested in optimization will be blocked on this particular problem, like Peter Alexander said.
>
> GC hassle is quite common but not that big a deal:
> - Manu: "Consequently, I avoid the GC in D too, and never had any major
> problems, only inconvenience." http://www.reddit.com/r/**
> programming/comments/1nxs2i/**the_state_of_rust_08/ccnefe7<http://www.reddit.com/r/programming/comments/1nxs2i/the_state_of_rust_08/ccnefe7>
> - Dav1d: said he never had a GC problem with BRala (minecraft client)
> - Me: I had a small ~100ms GC pause in one of my games every 20 minutes,
> more often than not I don't notice it
>
> So a definitive written rebutal we can link to would perhaps be helpful.
>

I might just add, that while my experience has been that I haven't had any
significant technical problems when actively avoiding the GC, the
inconvenience is considerably more severe than I made out in that post (I
don't want to foster public negativity).
But it is actually really, really inconvenient. If that's my future with D,
then I'll pass, just as any un-biased 3rd party would.

I've been simmering on this issue ever since I took an interest in D. At
first I was apprehensive to accept the GC, then cautiously optimistic that
the GC might be okay. But I have seen exactly no movement in this area as
long as I've been following D, and I have since reverted to a position in
absolute agreement with the C++ users. I will never accept the GC in it's
current form for all of my occupational requirements; it's implicitly
non-deterministic, and offers very little control over performance
characteristics.
I've said before that until I can time-slice the GC, and it does not stop
the world, then it doesn't satisfy my requirements. I see absolutely no
motion towards that goal.
If I were one of those many C++ users evaluating D for long-term adoption
(and I am!), I'm not going to invest the future of my career and industry
in a complete question mark which given years of watching already, is
clearly going nowhere.
As far as the GC is concerned, with respect to realtime embedded software,
I'm out. I've completely lost faith. And it's going to take an awful lot
more to restore my faith again than before.

What I want is an option to replace the GC with ARC, just like Apple did.
Clearly they came to the same conclusion, probably for exactly the same
reasons.
Apple have a policy of silky smooth responsiveness throughout the OS and
the entire user experience. They consider this a sign of quality and
professionalism.
As far as I can tell, they concluded that non-deterministic GC pauses were
incompatible with their goal. I agree.
I think their experience should be taken very seriously. They have a
successful platform on weak embedded hardware, with about a million
applications deployed.

I've had a lot of conversations with a lot of experts, plenty of
conversations at dconf, and nobody could even offer me a vision for a GC
that is acceptable.
As far as I can tell, nobody I talked to really thinks a GC that doesn't
stop the world, which can be carefully scheduled/time-sliced (ie, an
incremental, thread-local GC, or whatever), is even possible.

I'll take ARC instead. It's predictable, easy for all programmers who aren't experts on resource management to understand, and I have DIRECT control over it's behaviour and timing.

But that's not enough, offering convenience while trying to avoid using the GC altogether is also very important. You should be able to write software that doesn't allocate memory. It's quite hard to do in D today. There's plenty of opportunity for improvement.

I'm still keenly awaiting a more-developed presentation of Andrei's allocators system.

On Wednesday, 9 October 2013 at 05:15:53 UTC, Manu wrote:
> On 9 October 2013 08:58, ponce <contact@gmsfrommars.fr> wrote:
>
>> On Tuesday, 8 October 2013 at 22:45:51 UTC, Adam D. Ruppe wrote:
>>
>>>
>>> Eh, not necessarily. If it expands to static assert(!__traits(**hasAnnotationRecursive,
>>> uses_gc));, then the only ones that *need* to be marked are the lowest
>>> level ones. Then it figures out the rest only on demand.
>>>
>>> Then, on the function you care about as a user, you say nogc and it tells
>>> you if you called anything and the static assert stacktrace tells you where
>>> it happened.
>>>
>>> Of course, to be convenient to use, phobos would need to offer
>>> non-allocating functions, which is indeed a fair amount of work, but they
>>> wouldn't *necessarily* have to have the specific attribute.
>>>
>>
>> But is it even necessary? There isn't a great deal of evidence that
>> someone interested in optimization will be blocked on this particular
>> problem, like Peter Alexander said.
>>
>> GC hassle is quite common but not that big a deal:
>> - Manu: "Consequently, I avoid the GC in D too, and never had any major
>> problems, only inconvenience." http://www.reddit.com/r/**
>> programming/comments/1nxs2i/**the_state_of_rust_08/ccnefe7<http://www.reddit.com/r/programming/comments/1nxs2i/the_state_of_rust_08/ccnefe7>
>> - Dav1d: said he never had a GC problem with BRala (minecraft client)
>> - Me: I had a small ~100ms GC pause in one of my games every 20 minutes,
>> more often than not I don't notice it
>>
>> So a definitive written rebutal we can link to would perhaps be helpful.
>>
>
> I might just add, that while my experience has been that I haven't had any
> significant technical problems when actively avoiding the GC, the
> inconvenience is considerably more severe than I made out in that post (I
> don't want to foster public negativity).
> But it is actually really, really inconvenient. If that's my future with D,
> then I'll pass, just as any un-biased 3rd party would.
>
> I've been simmering on this issue ever since I took an interest in D. At
> first I was apprehensive to accept the GC, then cautiously optimistic that
> the GC might be okay. But I have seen exactly no movement in this area as
> long as I've been following D, and I have since reverted to a position in
> absolute agreement with the C++ users. I will never accept the GC in it's
> current form for all of my occupational requirements; it's implicitly
> non-deterministic, and offers very little control over performance
> characteristics.
> I've said before that until I can time-slice the GC, and it does not stop
> the world, then it doesn't satisfy my requirements. I see absolutely no
> motion towards that goal.
> If I were one of those many C++ users evaluating D for long-term adoption
> (and I am!), I'm not going to invest the future of my career and industry
> in a complete question mark which given years of watching already, is
> clearly going nowhere.
> As far as the GC is concerned, with respect to realtime embedded software,
> I'm out. I've completely lost faith. And it's going to take an awful lot
> more to restore my faith again than before.
>
> What I want is an option to replace the GC with ARC, just like Apple did.
> Clearly they came to the same conclusion, probably for exactly the same
> reasons.
> Apple have a policy of silky smooth responsiveness throughout the OS and
> the entire user experience. They consider this a sign of quality and
> professionalism.
> As far as I can tell, they concluded that non-deterministic GC pauses were
> incompatible with their goal. I agree.
> I think their experience should be taken very seriously. They have a
> successful platform on weak embedded hardware, with about a million
> applications deployed.
>
> I've had a lot of conversations with a lot of experts, plenty of
> conversations at dconf, and nobody could even offer me a vision for a GC
> that is acceptable.
> As far as I can tell, nobody I talked to really thinks a GC that doesn't
> stop the world, which can be carefully scheduled/time-sliced (ie, an
> incremental, thread-local GC, or whatever), is even possible.
>
> I'll take ARC instead. It's predictable, easy for all programmers who
> aren't experts on resource management to understand, and I have DIRECT
> control over it's behaviour and timing.
>
> But that's not enough, offering convenience while trying to avoid using the
> GC altogether is also very important. You should be able to write software
> that doesn't allocate memory. It's quite hard to do in D today. There's
> plenty of opportunity for improvement.
>
> I'm still keenly awaiting a more-developed presentation of Andrei's
> allocators system.



Apple dropped the GC and went ARC instead, because they never managed to make it work properly.

It was full of corner cases, and the application could crash if those cases were not fully taken care of.

Or course the PR message is "We dropped GC because ARC is better" and not "We dropped GC because we failed".

Now having said this, of course D needs a better GC as the current one doesn't fulfill the needs of potential users of the language.

--
Paulo

On 9 October 2013 09:05, Walter Bright <newshound2@digitalmars.com> wrote:

> On 10/8/2013 12:34 PM, Jonathan M Davis wrote:
>
>> I think that it's clear that for some projects, it's critical to minimize
>> the
>> GC, and I think that it's clear that we need to do a better job of
>> supporting
>> the folks who want to minimize GC usage, but I also think that for the
>> vast
>> majority of cases, complaints about the GC are way overblown. It becomes
>> an
>> issue when you're doing a lot of heap allocations, but it's frequently
>> easy to
>> design D code so that heap allocations are relatively rare such that they
>> aren't going to be a serious problem outside of code which is performance
>> critical to the point that it would be worrying about the cost of malloc
>> (which most code isn't). Personally, the only time that I've run into
>> issues
>> with the GC is when trying to do use RedBlackTree with a lot of items.
>> That
>> has a tendancy to tank performance.
>>
>> So, yes, it's problem. Yes, we need to improve the situaton. But for most situations, I think that the concern about the GC is way overblown.
>>
>
> +1
>
> Some years ago, a colleague of mine moonlighted teaching remedial algebra at the UW. She'd write on the board:
>
>    x + 2 = 5
>
> and call on a student to "solve for x". The student would collapse in a stuttering heap of jelly, emitting sparks and smoke like a Star Trek computer. She discovered that if she wrote instead:
>
>    _ + 2 = 5
>
> and would ask the same student what goes in the blank spot, he'd say "3" without hesitation.
>
> In other words, the student would only see the words "solve", "x", and "algebra" which were a shortcut in his brain to "I can't do this" and "gee math is hard." She found she was a far more effective teacher by avoiding using those words.
>
> I realized the same thing was happening with the word "template". I talked Andrei into avoiding all use of that word in "The D Programming Language", figuring that we could get people who were terrified of "templates" to use them successfully without realizing it (and I think this was very successful).
>
> We have a similar problem with "GC". People hear that word, and they are instantly turned off. No amount of education will change that. We simply have to find a better way to deal with this issue.
>

I think there is certainly an element of this. When someone identifies
something in their code that consistently causes issues, they tend to ban
it, rather than try and understand it better.
I will admit to being absolutely guilty of this in the past myself. We
banned STL and the template keyword outright (not so uncommon in the games
industry). But the problem is not so simple as taking the time to
understand something thoroughly...
People often forget that programmers work in large teams, and typically,
about 30-40% of those programmers are junior, and a further 30-50% are just
average-joe programmers for who it's a day job, and don't really give a
shit.
The take-away is, if a couple of guys grapple with something that's a
consistent problem and find a very specific (possibly obscure) usage that
doesn't violate their criteria, they then have a communication issue with a
whole bunch of other inexperienced or apathetic programmers, which I can
assure you, is an endless up-hill battle.
It's usually easier to ban it, and offer a slightly less pleasant, but
reliable alternative instead. Unless you feel it's a good use of time and
money to have your few best senior programmers trawling through code
finding violations of standard practise and making trivial (but hard to
find/time consuming) fixes on build nights.

The (existing) GC definitely fits this description in my mind.