On Saturday, 16 October 2021 at 05:37:40 UTC, russhy wrote:

That really doesn't work in practice, as it prevent libraries from allocating at all.

On Saturday, 16 October 2021 at 04:03:29 UTC, russhy wrote:

Hence the solution is to improve the GC 😎

On Saturday, 16 October 2021 at 10:32:59 UTC, Imperatorn wrote:

No.

Well it doesn't hurt to improve the GC, but no, it isn't the solution.

On Saturday, 16 October 2021 at 12:51:26 UTC, deadalnix wrote:

I inserted the emoji there but it didn't work 😑

On Saturday, 16 October 2021 at 17:18:34 UTC, Imperatorn wrote:

Works fine here. I just think that it wasn't clear whatever you meant by it.

On Friday, 15 October 2021 at 23:58:34 UTC, deadalnix wrote:

Well, yes, malloc is only the default, when people want speed in system level programming they create their own allocators.

In order to get to a competitive advantage, D has to decide what its primary use case is. Maybe it would be better for D to position itself as a higher level language with some lower level features.

I think also GC and malloc can be combined and improved on. You could probably get better performance and less fragmentation if the allocation contained a hint of when it statistically would be released. You could also get better performance by providing information about typical allocation patterns and sizes.

But without a clear vision of what the key use cases for the language is, getting a direction on all of this is going to be difficult. (Much easier to make tough decision if you have a clear picture of what the main use scenario is.)

On Monday, 18 October 2021 at 11:08:08 UTC, Ola Fosheim Grøstad wrote:

It doesn't matter. These allocator need memory from the system and almost always use malloc do get it. Which as far as the GC is concerned, it the only thing that is needed. It doesn't matter if you malloc each object or if you malloc a large slab and then manage it manually.

On Monday, 18 October 2021 at 11:33:02 UTC, deadalnix wrote:

Yes, but often times they don't release it until program exit.

On Monday, 18 October 2021 at 11:38:46 UTC, Ola Fosheim Grøstad wrote:

That still doesn't change anything to the point made.

On Monday, 18 October 2021 at 11:33:02 UTC, deadalnix wrote:

and then you freeze all threads and must scan all allocated pointers whenever your "gc'd malloc"'s buffer needs to grow

you can't compete with highlevel languages and their sub 1ms incremental GC

that's very depressing to focus on whether or not we should use the GC

that is not the question we should ask, the question is: what problem do we want to solve

AGAIN

ASP.net team is working hard on reducing the impact of the GC in their library!!!! even thought they have a competitive GC, they are making sure they don't do useless GC allocations and are using Span/stackalloc/ValueTysk everywhere!!

Learn from them, don't be like their old-them and saying, we should use and embrace GC everywhere

That is not how you make fast and competing software......

The smart and pragmatic approach is to give tools for people to write efficient software

Allocators is one of them

And it doesn't change the way people code, if they want to use a GC, they are free to do it so

But go tell an graphics engine programmer to use a GC, he'll laugh at you

Vulkan is meant to be used with an allocator https://gpuopen.com/vulkan-memory-allocator/

That is the pragmatic way of designing portable and efficient libraries

Have we lost our mind focusing on the GC? i think yes