Jump to page: 1 25  
Page
Thread overview
January 20

I just found out that Unity has incremental garbage collection. I didn't know that was a possibility for GCs.

https://docs.unity3d.com/Manual/performance-incremental-garbage-collection.html

I'm just curious what the D language community's thoughts are on it. The tradeoff is: For
a longer total time / lower throughput, you reduce stress on individual frames which prevents hiccups. That's pretty darn important for games and soft/hard real-time systems.

Is that an option on a hypothetical level, for D? Or does D's language design preclude that. I recall some sort of issue with using Java/C#/whatever's garbage collector because it would have to insert memory barriers into D to work or something like that.

Also, it's hard to find one specific place for "news" regarding D's garbage collector development and "omg we deleted everything GC from the standard library" projects. Are there any major updates on those fronts?

January 21

On Thursday, 20 January 2022 at 23:56:42 UTC, Chris Katko wrote:

>

I just found out that Unity has incremental garbage collection. I didn't know that was a possibility for GCs.

[...]

Oh, also, here's a blog post when they released in the end of 2018

https://blog.unity.com/technology/feature-preview-incremental-garbage-collection

January 20
On Thu, Jan 20, 2022 at 11:56:42PM +0000, Chris Katko via Digitalmars-d wrote:
> I just found out that Unity has incremental garbage collection. I didn't know that was a possibility for GCs.
[...]

AFAIK, Ruby has had it ages ago. It's not a new idea.


> Is that an option on a hypothetical level, for D? Or does D's language design preclude that. I recall some sort of issue with using Java/C#/whatever's garbage collector because it would have to insert memory barriers into D to work or something like that.

Write barriers are required for an incremental GC to work. Write barriers are unlikely to be accepted in D because they introduce synchonization overhead per pointer write. This would kill D's performance in low-level code, and I don't think Walter will ever accept this.


> Also, it's hard to find one specific place for "news" regarding D's garbage collector development and "omg we deleted everything GC from the standard library" projects. Are there any major updates on those fronts?

https://dlang.org/blog/the-gc-series/

The GC isn't going anywhere.  AFAIK there's some work to eliminate *unnecessary* GC usage in Phobos, et al, but there is no such project to remove *all* GC use from Phobos.


T

-- 
Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel
January 21
On Thursday, 20 January 2022 at 23:56:42 UTC, Chris Katko wrote:
> I'm just curious what the D language community's thoughts are on it. The tradeoff is: For
> a longer total time / lower throughput, you reduce stress on individual frames which prevents hiccups. That's pretty darn important for games and soft/hard real-time systems.

You can already avoid pauses by simply not allocating.  I would prefer to see a generational gc (much higher throughput).  Note also incremental is not a panacea; the mutator can still get ahead of the collector; go has a somewhat laughable solution to this.

On Friday, 21 January 2022 at 00:55:43 UTC, H. S. Teoh wrote:
> Write barriers are required for an incremental GC to work. Write barriers are unlikely to be accepted in D because they introduce synchonization overhead per pointer write. This would kill D's performance in low-level code, and I don't think Walter will ever accept this.

I have heard this claim before.  I don't buy it.

1. Barriers are not that slow.  It is not a 'synchronization'; it is a cheap compare-and-branch that will be correctly predicted.  (Nobody complains about bounds checking...)

2. You do not need a barrier on _every_ pointer write

3. It can be a compile-time option to disable it

4. Lack of typed pointers (gc/non-gc) can be solved conservatively with monomorphization
January 20
On 1/20/2022 5:46 PM, Elronnd via Digitalmars-d wrote:
> On Friday, 21 January 2022 at 00:55:43 UTC, H. S. Teoh wrote:

>> Write barriers are required for an incremental GC to work. Write barriers are unlikely to be accepted in D because they introduce synchronization overhead per pointer write. This would kill D's performance in low-level code, and I don't think Walter will ever accept this.
> 
> I have heard this claim before.  I don't buy it.

This is clearly an area where anecdotals like "Walter will never accept this" aren't useful.  There's ample evidence to show that he accepts when he's proven wrong.

To make any progress towards a better GC it's going to have to be demonstrated.  And the proof will justify the changes.  If they're good and the complexities required to get there aren't awful, then they'll make into the code base.  If they're not, then they wont.  The status quo is easy to get stuck in and help no one.

Someone with a good background in GC's needs to step up and be it's champion.  I expect that several people would rally to help once some basic momentum is established.  So, willing to be the rallying cry and step up?

January 21
On 21/01/2022 3:17 PM, Brad Roberts wrote:
> To make any progress towards a better GC it's going to have to be demonstrated.  And the proof will justify the changes.  If they're good and the complexities required to get there aren't awful, then they'll make into the code base.  If they're not, then they wont.  The status quo is easy to get stuck in and help no one.
> 
> Someone with a good background in GC's needs to step up and be it's champion.  I expect that several people would rally to help once some basic momentum is established.  So, willing to be the rallying cry and step up?

I've recently bought (but waiting on delivery) The Garbage Collection Handbook. It covers generational GC's, memory allocators (which is what I'm interested in) and like 13 pages on write barriers.

It would be an interesting experiment to see if we added a -enablewb flag and have it enable more GC options at runtime, if this allowed some better fitting GC's.
January 21
On Friday, 21 January 2022 at 02:17:34 UTC, Brad Roberts wrote:
> To make any progress towards a better GC it's going to have to be demonstrated.  And the proof will justify the changes.  If they're good and the complexities required to get there aren't awful, then they'll make into the code base.  If they're not, then they wont.  The status quo is easy to get stuck in and help no one.
>
> Someone with a good background in GC's needs to step up and be its champion.  I expect that several people would rally to help once some basic momentum is established.  So, willing to be the rallying cry and step up?

I agree.  But: it is an involved task that will likely not bear fruit until it is nearly done; I do not expect an implementation would perform very well until it performed the optimizations I mentioned elsewhere.  (Well, a first step would be to make the precise gc actually precise, which would benefit everybody; but after that...)

For my part, I think it would be a fun project, but it would not be a high enough priority for me to see it through unless somebody were paying me to do it full time (and who would pay for an 'unproven' idea? It is exactly the problem you identify).  Maybe rikki will be the champion :)
January 21
On 21/01/2022 5:48 PM, Elronnd wrote:
> Maybe rikki will be the champion :)

I've considered it, but it wouldn't align with what I am doing with D atm.

I'd also like to see is fiber aware GC hooks and configurable memory allocator.
January 21
On Friday, 21 January 2022 at 02:17:34 UTC, Brad Roberts wrote:
> On 1/20/2022 5:46 PM, Elronnd via Digitalmars-d wrote:
>> On Friday, 21 January 2022 at 00:55:43 UTC, H. S. Teoh wrote:
>
>>> Write barriers are required for an incremental GC to work. Write barriers are unlikely to be accepted in D because they introduce synchronization overhead per pointer write. This would kill D's performance in low-level code, and I don't think Walter will ever accept this.
>> 
>> I have heard this claim before.  I don't buy it.
>
> This is clearly an area where anecdotals like "Walter will never accept this" aren't useful.  There's ample evidence to show that he accepts when he's proven wrong.
>
> To make any progress towards a better GC it's going to have to be demonstrated.  And the proof will justify the changes.  If they're good and the complexities required to get there aren't awful, then they'll make into the code base.  If they're not, then they wont.  The status quo is easy to get stuck in and help no one.
>
> Someone with a good background in GC's needs to step up and be it's champion.  I expect that several people would rally to help once some basic momentum is established.  So, willing to be the rallying cry and step up?

To be honest, that is something that is more fun to do in the Go, .NET and Java communities, because not only no one cares about the matra that on a systems programming language GC verbotten is supposed to be a thing, there are hardware companies shipping real products with them.

So in those communities the whole discussion isn't if GC belongs or not in a systems programming language, being rebooted every couple of months, rather how to improve it to the point that e.g. writing firmware in Go is a reality that one can ship into a commercial product (USB Armory).
January 21

On Friday, 21 January 2022 at 04:17:53 UTC, rikki cattermole wrote:

>

I've recently bought (but waiting on delivery) The Garbage Collection Handbook. It covers generational GC's, memory allocators (which is what I'm interested in) and like 13 pages on write barriers.

I've browsed through it. The writing style is very accessible, I think. It also has a chapter on real time garbage collection ("wait-free" collection), but I guess that requires a different take on the language-runtime. Some also require OS-support, I guess.

>

It would be an interesting experiment to see if we added a -enablewb flag and have it enable more GC options at runtime, if this allowed some better fitting GC's.

I think many programmers would shoot themselves in the the foot in @nogc code... You would need very good documentation and tutorials for that to be a reasonable option.

« First   ‹ Prev
1 2 3 4 5