4 ms·

Thanks, I think swapping and controlling the GC would be a very useful feature. In the game example I gave performance is important, but what's also important

Thanks, I think swapping and controlling the GC would be a very useful feature. In the game example I gave performance is important, but what's also important is consistency. Interactive apps rely on a steady framerate so what you want to avoid is accumulating garbage across multiple frames, then doing a single large collection pass. In other words, it's better to do a bit of GC every frame than a bunch at once and risk stuttering.

mattparas 3y ago
I'll make a tracking issue for it - new GC work is fun! I'll do some research, I have on my back log to integrate Steel into Bevy or some other Rust game engine, would give me a reason to make some fun GCs
- CooCooCaCha 3y ago
  Nice! Hopefully my statements didn't come off as demanding. Just providing some info on that use case.
  - mattparas 3y ago
    Not at all! I agree it is a useful feature, I'd be curious how much it is necessary if not using any mutation, but the best way for me to find out is to try it out :)
zozbot234 3y ago
There are concurrent GC implementations for Rust, e.g. Samsara https://redvice.org/2023/samsara-garbage-collector/ https://redvice.org/2023/samsara-garbage-collector/ https://github.com/chc4/samsara https://github.com/chc4/samsara that avoid blocking, except to a minimal extent in rare cases of contention. That fits pretty well with the pattern of "doing a bit of GC every frame". (Note that doing GC over large object graphs will nonetheless involve significant overhead, even with efficient implementations as seen here; GC is not at all a silver bullet, and should be avoided if at all possible. The actual point of GC is to enable computing over highly general, possibly cyclical object graphs - if that doesn't apply, other memory management strategies can be used instead.)

4 ms·

Thanks, I think swapping and controlling the GC would be a very useful feature. In the game example I gave performance is important, but what's also important

by CooCooCaCha 3y ago

mattparas 3y ago
I'll make a tracking issue for it - new GC work is fun! I'll do some research, I have on my back log to integrate Steel into Bevy or some other Rust game engine, would give me a reason to make some fun GCs
- CooCooCaCha 3y ago
  Nice! Hopefully my statements didn't come off as demanding. Just providing some info on that use case.
  - mattparas 3y ago
    Not at all! I agree it is a useful feature, I'd be curious how much it is necessary if not using any mutation, but the best way for me to find out is to try it out :)
zozbot234 3y ago
There are concurrent GC implementations for Rust, e.g. Samsara https://redvice.org/2023/samsara-garbage-collector/ https://redvice.org/2023/samsara-garbage-collector/ https://github.com/chc4/samsara https://github.com/chc4/samsara that avoid blocking, except to a minimal extent in rare cases of contention. That fits pretty well with the pattern of "doing a bit of GC every frame". (Note that doing GC over large object graphs will nonetheless involve significant overhead, even with efficient implementations as seen here; GC is not at all a silver bullet, and should be avoided if at all possible. The actual point of GC is to enable computing over highly general, possibly cyclical object graphs - if that doesn't apply, other memory management strategies can be used instead.)