Would you pay for GC?

Paulo Pinto pjmlp at progtools.org
Fri Jan 28 11:11:54 UTC 2022


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.


More information about the Digitalmars-d mailing list