5 ms·

While the opinion-pendulum is currently on the contra-GC side, I still believe GC is the correct default. Mostly because GC is easier than manual memory managem

by qznc 7y ago

While the opinion-pendulum is currently on the contra-GC side, I still believe GC is the correct default. Mostly because GC is easier than manual memory management. If you have real-time needs, then GC is probably out. That includes handling audio and video playback. Tight memory constraints are another killer argument against GC but that only applies to small embedded devices. Smartphones, desktops, and servers have enough RAM. The great thing about D is that you can start the easy way with a GC. When real-time or memory become constraints at some point you can selectively adapt parts of your program. You could say, D wants to provide Python and Rust and everything in between so that you can shift seamlessly to wherever your specific sweet spot is. Different parts of your program can even use different spots. In a game engine, you could have the audio and rendering parts as non-GC real-time code, while the game logic is easy high-level script-like. We are very used to a scripting language plus compiled language combo these days but is the separation a good one?

nickpsecurity 7y ago
Don't rule real-time out. Real-time GC's exist. People just need to build open ones for these languages. Example write-up on this: http://michaelrbernste.in/2013/06/03/real-time-garbage-collection-is-real.html http://michaelrbernste.in/2013/06/03/real-time-garbage-colle...
Const-me 7y ago
In my experience (.NET, including mobile and embedded) when handled with care, GC is often fine even for audio and video. The trick is not loading the GC too much, neither in terms of allocations/second nor bytes/second (for multimedia it means recycling buffers as opposed to creating/destroying), also having enough RAM so you don’t need to use 80% of installed memory.
pjmlp 7y ago
Just yesterday I posted a link about real time audio processing done in Java. Anti-GC hate seems to always come from religious objection or having had back luck not understanding how to actually use the tools at their disposal.
- skocznymroczny 7y ago
  Most of anti-GC hate seems to be coming from C++ and Rust programmers. Also game developers seem to hate GC with passion, then they go back to writing their games with Javascript and C#.
  - pjmlp 7y ago
    It comes from long time. One thing that having been an Oberon user teached me, was that having a GC wasn't a show stopper for systems programming. Ironically C++ has has GC support for more than 20 years now. Managed C++ and C++/CLI on .NET, C++/CX on UWP, Unreal C++, and the GC API introduced in C++11. So it seems to be one of those things that you only learn to enjoy after experiencing it personally.
p0nce 7y ago
> If you have real-time needs, then GC is probably out. That includes handling audio and video playback. You'd be surprised. At first our D audio products had GC enabled, and that created very little problems. When we got rid of the D GC for other reasons (macOS + druntime portability in shared library), we found that we only gain in memory usage. The GC was already "tamed" to happen outside real time threads. This is described in: https://www.auburnsounds.com/blog/2016-11-10_Running-D-without-its-runtime.html https://www.auburnsounds.com/blog/2016-11-10_Running-D-witho... The conclusion: > Long story short, we brute-forced our way into having fully @nogc programs, with the runtime left uninitialized. > As expected this fixed macOS Sierra compatibility. As a bonus Panagement and Graillon are now using 2x less memory, which is nice, but hardly life-changing. > We found no magical speed enhancement. Speed-wise nothing changed. Not registering threads in callbacks did not bring any meaningful gain. GC pauses were already never happening so disabling the GC did not help. > In conclusion, it is still our opinion that outside niche requirements, there isn't enough reasons to depart from the D runtime and its GC. And indeed now we dearly miss the GC... For sure you wouldn't allocate in tight loops. But the portion of a program that can accomodate a GC is very much larger than is commonly told on the internet. As for video, it is way less sensitive to scheduler pauses than audio. Video systems are full of allocations (often of commited virtual memory) because throughput is often more important than latency there.

by qznc 7y ago

nickpsecurity 7y ago

Don't rule real-time out. Real-time GC's exist. People just need to build open ones for these languages. Example write-up on this: http://michaelrbernste.in/2013/06/03/real-time-garbage-collection-is-real.html http://michaelrbernste.in/2013/06/03/real-time-garbage-colle...

Const-me 7y ago

In my experience (.NET, including mobile and embedded) when handled with care, GC is often fine even for audio and video. The trick is not loading the GC too much, neither in terms of allocations/second nor bytes/second (for multimedia it means recycling buffers as opposed to creating/destroying), also having enough RAM so you don’t need to use 80% of installed memory.

pjmlp 7y ago

Just yesterday I posted a link about real time audio processing done in Java. Anti-GC hate seems to always come from religious objection or having had back luck not understanding how to actually use the tools at their disposal.

skocznymroczny 7y ago
Most of anti-GC hate seems to be coming from C++ and Rust programmers. Also game developers seem to hate GC with passion, then they go back to writing their games with Javascript and C#.
- pjmlp 7y ago
  It comes from long time. One thing that having been an Oberon user teached me, was that having a GC wasn't a show stopper for systems programming. Ironically C++ has has GC support for more than 20 years now. Managed C++ and C++/CLI on .NET, C++/CX on UWP, Unreal C++, and the GC API introduced in C++11. So it seems to be one of those things that you only learn to enjoy after experiencing it personally.

p0nce 7y ago

> If you have real-time needs, then GC is probably out. That includes handling audio and video playback. You'd be surprised. At first our D audio products had GC enabled, and that created very little problems. When we got rid of the D GC for other reasons (macOS + druntime portability in shared library), we found that we only gain in memory usage. The GC was already "tamed" to happen outside real time threads. This is described in: https://www.auburnsounds.com/blog/2016-11-10_Running-D-without-its-runtime.html https://www.auburnsounds.com/blog/2016-11-10_Running-D-witho... The conclusion: > Long story short, we brute-forced our way into having fully @nogc programs, with the runtime left uninitialized. > As expected this fixed macOS Sierra compatibility. As a bonus Panagement and Graillon are now using 2x less memory, which is nice, but hardly life-changing. > We found no magical speed enhancement. Speed-wise nothing changed. Not registering threads in callbacks did not bring any meaningful gain. GC pauses were already never happening so disabling the GC did not help. > In conclusion, it is still our opinion that outside niche requirements, there isn't enough reasons to depart from the D runtime and its GC. And indeed now we dearly miss the GC... For sure you wouldn't allocate in tight loops. But the portion of a program that can accomodate a GC is very much larger than is commonly told on the internet. As for video, it is way less sensitive to scheduler pauses than audio. Video systems are full of allocations (often of commited virtual memory) because throughput is often more important than latency there.