On 10/8/13 9:29 AM, ponce wrote:
> On Tuesday, 8 October 2013 at 16:22:25 UTC, Dicebot wrote:
>> It is not overblown. It is simply "@nogc" which is lacking but
>> absolutely mandatory. Amount of hidden language allocations makes
>> manually cleaning code of those via runtime asserts completely
>> unreasonable for real project.
>
> Hidden language allocations:
> - concatenation operator   ~
> - homogeneous arguments   void (T[]... args)
> - "real" closures that escapes
> - array literals
> - some phobos calls
>
> What else am I missing?
> I don't see the big problem, and a small fraction of projects will
> require a complete ban on GC allocation, right?

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.


Andrei

On Wednesday, 9 October 2013 at 02:22:35 UTC, Andrei Alexandrescu wrote:
> * 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.
>

std.typecons is a little treasure trove of stuff nobody can find or knows about.  I think tuple should be promoted to its own module too (which would help alleviate some of the confusion new users have with std.typetuple as well).

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

I ran Johannes Pfau's work-in-progress -vgc [1] while building Phobos back in June. Here are the now out of date results: http://goo.gl/HP78r  I'm sure plenty is missing in there (I think allocations inside templates that aren't instiated aren't included).

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

All of this sounds great.

1. https://github.com/D-Programming-Language/dmd/pull/1886

On Wednesday, 9 October 2013 at 02:22:35 UTC, Andrei Alexandrescu wrote:
> * 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.
>

This make sense. 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.

I'm pretty sure that in most application, sheared data is a small set. First step is to get the compiler to generate appropriate calls, even if they go to the same GC alloc function to begin with.

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. This will fail miserably if the data is allocated on a thread local heap.

On 10/8/13 4:22 PM, Sean Kelly wrote:
> On Oct 8, 2013, at 3:38 PM, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 10/8/2013 3:02 PM, Peter Alexander wrote:
>>> You may argue that profiling won't always catch accidental allocations due to
>>> test coverage. This is true, but then @nogc is only a partial fix to this
>>> anyway. It will catch GC allocations, but what about accidental calls to malloc,
>>> mmap, or maybe an accidental IO call due to some logging you forgot to remove.
>>> GC allocations are just one class of performance problems, there are many more
>>> and I hope we don't have to add attributes for them all.
>>
>> This, of course, is the other problem with @nogc. Having a forest of attributes on otherwise ordinary functions is awfully ugly.
>
> And we already have a forest of attributes on otherwise ordinary functions.

It's the cost of expressiveness. Exercising deduction wherever possible is the cure.

Andrei

On 10/8/13 4:29 PM, Adam D. Ruppe wrote:
> On Tuesday, 8 October 2013 at 22:58:02 UTC, ponce wrote:
>> But is it even necessary?
>
> It is nice to have stdlib functions available that can be used anywhere.
> For std.algorithm, Andrei has said if you ever implement an algorithm by
> hand, it means the library has failed. But there's two places where that
> falls short (IMO at least): using it without allocating, and using it
> without bringing in a bazillion dependencies.

Only Levenshtein distance produces garbage in std.algorithm.

Andrei

On 10/8/13 4:45 PM, Jonathan M Davis wrote:
> On Wednesday, October 09, 2013 01:04:39 Tourist wrote:
>> I thought about an alternative approach:
>> Instead of using a (yet another) annotation, how about
>> introducing a flag similar to -cov, which would output lines in
>> which the GC is used.
>> This information can be used by an IDE to highlight those lines.
>> Then you could quickly navigate through your performance-critical
>> loop and make sure it's clean of GC.
>
> That sounds like a much less invasive approach no a @nogc attribute.

Problem is with functions that have no source available.

Andrei

On Wednesday, 9 October 2013 at 03:38:56 UTC, Andrei Alexandrescu wrote:
> Only Levenshtein distance produces garbage in std.algorithm.

Yeah, I was referring more to phobos as a whole than algorithm specifically there, just using the principle on principle.

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.


Andrei

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