On Monday, 18 October 2021 at 11:33:02 UTC, deadalnix wrote:
On Monday, 18 October 2021 at 11:08:08 UTC, Ola Fosheim Grøstad wrote:
Well, yes, malloc is only the default, when people want speed in system level programming they create their own allocators.
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.
and then you freeze all threads and must scan all allocated pointers whenever your "gc'd malloc"'s buffer needs to grow
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.)
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
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