Would you pay for GC? (page 5)

On Friday, 28 January 2022 at 10:18:32 UTC, IGotD- wrote: > On Wednesday, 26 January 2022 at 06:20:06 UTC, Elronnd wrote: >> >> Thread-local gc is a thing. Good for false sharing too (w/real threads); can move contended objects away from owned ones. But I see no reason why fibre-local heaps should need to be much different from thread-local heaps. >> > > I would like to challenge the idea that thread aware GC would do much for performance. Pegging memory to one thread is unusual and doesn't often correspond to the reality. > > For example a computer game with large amount of vertex data where you decide to split up the workload on several threads. You don't make a thread local copy of that data but keep the original vertex data global and even destination buffer would be global. > > What I can think of is a server with one thread per client with data that no other reason thread works on. Perhaps there thread local GC could be benefitial. My experience is that this thread model isn't good programming and servers should instead be completely async meaning any thread might handle the next partial work. > > As I see it thread aware GC doesn't do much for performance but complicates it for the programmer. You can have your cake and eat it too, using something like Pony capabilities. The memory isn't copied in practice, just logically and just one owner at a time. https://tutorial.ponylang.io/reference-capabilities/reference-capabilities.html#the-list-of-reference-capabilities That is something that would be impossible to put into D's typesystem, without turning it into something else. Also most key developers on Pony have moved into either Verona (https://www.microsoft.com/en-us/research/project/project-verona), which carries on these ideas, or Rust (https://www.wallaroo.ai/blog/wallaroo-move-to-rust), so mostly likely Pony will have a hard time to improve itself.

January 28, 2022

Re: Would you pay for GC?

Posted by Ola Fosheim Grøstad
in reply to IGotD-

Permalink

Ola Fosheim Grøstad

Posted in reply to IGotD-

Permalink

On Friday, 28 January 2022 at 10:18:32 UTC, IGotD- wrote:

On Wednesday, 26 January 2022 at 06:20:06 UTC, Elronnd wrote:

Thread-local gc is a thing. Good for false sharing too (w/real threads); can move contended objects away from owned ones. But I see no reason why fibre-local heaps should need to be much different from thread-local heaps.

I would like to challenge the idea that thread aware GC would do much for performance. Pegging memory to one thread is unusual and doesn't often correspond to the reality.

For example a computer game with large amount of vertex data where you decide to split up the workload on several threads. You don't make a thread local copy of that data but keep the original vertex data global and even destination buffer would be global.

Which is why you would want ARC for shared objects and a local GC for tasks/actors.

Then what you need for more flexibility and optimization is static analysis that determines if local objects can be turned into shared objects. If that is possible you could put them in a separate region of the GC heap with space for a RC field at negative offset.

What I can think of is a server with one thread per client with data that no other reason thread works on.

It shouldn't be per thread, but per actor/task/fiber.

My experience is that this thread model isn't good programming and servers should instead be completely async meaning any thread might handle the next partial work.

You have experience with this model? From where?

Actually, it could be massively beneficial if you have short lived actors and most objects have trivial destructors. Then you can simply release the entire local heap with no scanning.

You basically get to configure the system to use arena-allocators with GC-fallback for out-of-memory situations. Useful for actors where most of the memory it holds are released towards the end of the actor's life time.

As I see it thread aware GC doesn't do much for performance but complicates it for the programmer.

You cannot discuss performance without selecting a particular realistic application. Which is why system level programming requires multiple choices and configurations if you want automatic memory management. There is simply no model that works well with all scenarios.

What is needed for D is to find a combinations that works both for current high level programming D-users and also makes automatic memory management more useful in more system level programming scenarios.

Perfect should be considered as out-of-scope.

On Friday, 28 January 2022 at 11:11:54 UTC, Paulo Pinto wrote: > [snip] > > That is something that would be impossible to put into D's typesystem, without turning it into something else. > > [snip] Well D would do it in a D way rather than in a pony way...for instance pony's val is similar to D's immutable but not the same. The question would be what from pony's reference capabilities would it make sense to add to D. I think the one with the most obvious benefit would be iso. Some people have talked about wanting something like that in the language. It's somewhat different from Rust's borrow checker in that it only allows one mutable alias, whereas Rust allows that or as many const aliases as you want (but not both).

On Friday, 28 January 2022 at 15:34:49 UTC, jmh530 wrote: > On Friday, 28 January 2022 at 11:11:54 UTC, Paulo Pinto wrote: >> [snip] >> >> That is something that would be impossible to put into D's typesystem, without turning it into something else. >> >> [snip] > > Well D would do it in a D way rather than in a pony way...for instance pony's val is similar to D's immutable but not the same. The question would be what from pony's reference capabilities would it make sense to add to D. I think the one with the most obvious benefit would be iso. Some people have talked about wanting something like that in the language. It's somewhat different from Rust's borrow checker in that it only allows one mutable alias, whereas Rust allows that or as many const aliases as you want (but not both). Yeah, maybe that would be possible then. Still better stabilize D's approach to lifetimes first.

Forums