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.

The latter is a bigger problem to me personally than the former (this is why simpledisplay.d as its own implementation of to and split, for example, doing it myself instead of importing phobos cut the compile time and exe size both in half), but a lot more people complain about the gc...

> There isn't a great deal of evidence that someone interested in optimization will be blocked on this particular problem, like Peter Alexander said.

yeah, I haven't found it to be a big deal to hunt down allocations either, and reimplementing the functions in phobos that allocate generally isn't hard anyway. But still, if we can do it, we might as well.

On Tuesday, 8 October 2013 at 23:05:37 UTC, Walter Bright wrote:
> 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.

Time to replace the Garbage Collector with a Memory Recycler.

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. We already arguably have too many attributes. We shouldn't be adding more unless we actually need to.

And if we work towards making better use of output ranges in Phobos, it should become reasonably easy to determine which functions might allocate and which won't, so anyone writing code that wants to avoid the GC will know which functions they can call and which they can't. And your proposed flag would catch the cases that they miss.

So, I'd say that this along with the --nogc flag seem like good ideas.

- Jonathan M Davis

On 10/8/13 1:41 PM, Dicebot wrote:
> On Tuesday, 8 October 2013 at 19:52:32 UTC, Brad Roberts wrote:
>> On 10/8/13 10:00 AM, Dicebot wrote:
>>>
>>> proper performance
>>
>> I apologize for picking out your post, Dicebot, as the illustrative example, but I see this pop up
>> in various discussion and I've been meaning to comment on it for a while.
>>
>> Please stop using words like 'proper', 'real', and other similar terms to describe a requirement.
>> It's a horrible specifier and adds no useful detail.
>>
>> It tends to needlessly setup the convarsation as confrontational or adversarial and implies that
>> anyone that disagrees is wrong or not working on a real system.  There's lots of cases where
>> pushing to the very edge of bleeding isn't actually required.
>>
>> Thanks,
>> Brad
>
> What wording would you suggest to use? For me "proper" is pretty much equal to "meeting requirements
> / expectations as defined by similar projects written in C". It has nothing do with "real" vs "toy"
> projects, just implies that in some domains such expectations are more restrictive.

Looking at the context you used it in, defining the performance of vibe and requiring that it never allocate during page processing to get 'proper performance'.  Would you agree that at least in this case and with that definition that it's an over-reach at least?  That there's likely to be far more applications where allocation is perfectly acceptable and quite possibly even required to achieve the goals of the applications than not?  Yes, there are some where the performance or latency requirements are so high that the allocations have to be avoided to achieve them, but that's more the exception than the rule?  For those applications 'proper performance' allows a far greater lattitude of implementation choices.

It's applying your, unspecified, requirements as the definition of valid.

The biggest place it irks me isn't actually this type of case but rather when applied to docs or the language spec.

On Tuesday, 8 October 2013 at 23:32:51 UTC, Brad Anderson wrote:
> On Tuesday, 8 October 2013 at 23:05:37 UTC, Walter Bright wrote:
>> 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.
>
> Time to replace the Garbage Collector with a Memory Recycler.

Resource Guard? Area cleaner?
Or the Graph Inspector (tm).

On 10/8/2013 4:32 PM, Brad Anderson wrote:
> Time to replace the Garbage Collector with a Memory Recycler.

"Soylent Green" ?

On Wednesday, 9 October 2013 at 00:00:09 UTC, ponce wrote:
> Resource Guard?

Actually, I've been coming to see the gc as being an implementation detail for immutability, and memory safety is a secondary piece.

With immutable though, you are guaranteeing that the contents never change. Never change means the memory must never be reused either - thus never freed.

But we want to reclaim that resource if we can. The GC lets us do that without ever breaking the guarantee of immutability.


To this end, I really, really want to see the scope parameter (and return value!) thing implemented. All mutable and const slices and pointers would be assumed to be scope (or if this breaks too much code, strongly recommended to be scope at all times). That way, you won't let the reference escape, meaning it is safe to manage those resources with destructors on the outer layer, while using them for cheap on inner layers by just passing the pointer, which can even be implicit, iff scope.

Those wouldn't need the gc.

Immutable resources, however, are always safe to store, so scope immutable would be irrelevant. This illusion is maintained with the gc.

On Wednesday, 9 October 2013 at 00:01:30 UTC, Walter Bright wrote:
> On 10/8/2013 4:32 PM, Brad Anderson wrote:
>> Time to replace the Garbage Collector with a Memory Recycler.
>
> "Soylent Green" ?

"You've got to tell them... It's bar...foo is made out of bar"

On 10/8/2013 5:49 PM, Brad Anderson wrote:
> On Wednesday, 9 October 2013 at 00:01:30 UTC, Walter Bright wrote:
>> On 10/8/2013 4:32 PM, Brad Anderson wrote:
>>> Time to replace the Garbage Collector with a Memory Recycler.
>>
>> "Soylent Green" ?
>
> "You've got to tell them... It's bar...foo is made out of bar"

That so-called "new" memory you've been promised ... it's been used before!

On 10/08/2013 11:43 AM, ponce wrote:
> At least on Internet forums, there seems to be an entire category of
> people dismissing D immediately because it has a GC.
>

I have just read an interesting blog post about GC
http://prog21.dadgum.com/15.html