10 ms·

> glibc could introduce arbitrary delays, but it generally doesn't. Yeah it does, that's why gamedevs and hfts don't use any malloc in the fast path, glibc or

> glibc could introduce arbitrary delays, but it generally doesn't. Yeah it does, that's why gamedevs and hfts don't use any malloc in the fast path, glibc or otherwise.

IshKebab 3y ago
Incorrect. They don't use malloc in the fast path because allocation is slow, not because it introduces arbitrary delays like GC pauses do. To be clear: * Not allocating (or stack/bump allocation): extremely fast, completely deterministic. * malloc: pretty fast, in theory arbitrarily slow but in practice it's well bounded * GC pauses: very slow (until Go anyway)
- dadoum 3y ago
  If you can avoid allocations where speed matters, then the GC won't slow you down either, as (at least in D) it cannot be triggered if you don't allocate.
  - IshKebab 3y ago
    The difference is that it's deterministic. If you avoid allocation in C/C++/Zig/Rust then you know nothing is going to slow you down, and at worst you have a couple of allocations that won't cause a big spike. With GC you can try to avoid allocations, but you might miss a couple and get occasional frame stutters anyway every now and then. Also avoiding allocation is a whole lot harder in languages that use a GC for everything than languages that provide an alternative. The real solution for games is explicit control over GC runs - tell it not to GC under any circumstances until the frame is finished rendering, then it can GC until the next frame starts. I assume Unity does this for example. Still, games are only one application where you don't want big pauses - one that happens to have convenient regular times when you probably aren't doing anything.
    - saghm 3y ago
      > The difference is that it's deterministic. If you avoid allocation in C/C++/Zig/Rust then you know nothing is going to slow you down, and at worst you have a couple of allocations that won't cause a big spike. > With GC you can try to avoid allocations, but you might miss a couple and get occasional frame stutters anyway every now and then. Also avoiding allocation is a whole lot harder in languages that use a GC for everything than languages that provide an alternative Something that I think doesn't get the attention it deserves in Rust is how explicit it makes allocations at the type level. You don't have a pointer that maybe points to the heap and maybe to the stack (or in the case of GC maybe even is on the stack right now but won't be when you change how it's used later) or a slice that you need to track down whether it originated as a reference to a fixed-size array or if it it's dynamically allocated; you have either type that you know is a reference like &T or &str or a slice, or you have a type you know was allocated on the heap like a Box or an Arc or a String or a Vec. I've seen people need to spend a lot of time profiling projects in other languages to track down where they can optimize their memory usage. I wonder if people who are skeptical of languages with expressive type systems might see the benefits more if they were presented less in terms of what the type system provides you directly, but in terms of what it makes available for tooling to take advantage of; in the case of using the type system to track allocations, the advantage might seem limited to your own code and not helpful when handling dependencies without being willing to dive into their code, but I think it's easy to overlook that having the information available statically makes it possible for tooling to utilize it, and that applies just as much to dependencies.
    - dadoum 3y ago
      In D you have 2 options to deal with that: - As you described, you can disable the GC to do your thing. That's not the solution I would recommend, but if you call GC.disable then the GC won't collect anything until you enable it back (or if the program is running out of memory). - You can mark a function as @nogc, and then the compiler will prevent you from allocating anything that could trigger GC allocation. There is some level of support for @nogc in the language and few libraries to help, the issue is more in the standard library which relies a lot on the GC.
- naasking 3y ago
  > GC pauses: very slow (until Go anyway) If by "slow" you mean "high latency", then this isn't true. Plenty of GC algorithms provide guaranteed sub-millisecond pauses.
  - IshKebab 3y ago
    It wasn't the norm until Go focused on it though, and "sub milliseconds" is not a high bar. Malloc is much much faster than that.
    - naasking 3y ago
      > It wasn't the norm until Go focused on it though It's still not the norm, but the point is that those were available > and "sub milliseconds" is not a high bar. Malloc is much much faster than that. Malloc is not guaranteed to return in that time frame. The sub-millisecond latency of these GCs is a real-time guarantee.
      - IshKebab 3y ago
        > Malloc is not guaranteed to return in that time frame No but in practice it always does.
        naasking 3y ago
        It doesn't though, which is why malloc is rarely used in embedded and realtime systems.

> glibc could introduce arbitrary delays, but it generally doesn't. Yeah it does, that's why gamedevs and hfts don't use any malloc in the fast path, glibc or otherwise.

IshKebab 3y ago

Incorrect. They don't use malloc in the fast path because allocation is slow, not because it introduces arbitrary delays like GC pauses do. To be clear: * Not allocating (or stack/bump allocation): extremely fast, completely deterministic. * malloc: pretty fast, in theory arbitrarily slow but in practice it's well bounded * GC pauses: very slow (until Go anyway)

dadoum 3y ago
If you can avoid allocations where speed matters, then the GC won't slow you down either, as (at least in D) it cannot be triggered if you don't allocate.
- IshKebab 3y ago
  The difference is that it's deterministic. If you avoid allocation in C/C++/Zig/Rust then you know nothing is going to slow you down, and at worst you have a couple of allocations that won't cause a big spike. With GC you can try to avoid allocations, but you might miss a couple and get occasional frame stutters anyway every now and then. Also avoiding allocation is a whole lot harder in languages that use a GC for everything than languages that provide an alternative. The real solution for games is explicit control over GC runs - tell it not to GC under any circumstances until the frame is finished rendering, then it can GC until the next frame starts. I assume Unity does this for example. Still, games are only one application where you don't want big pauses - one that happens to have convenient regular times when you probably aren't doing anything.
  - saghm 3y ago
    > The difference is that it's deterministic. If you avoid allocation in C/C++/Zig/Rust then you know nothing is going to slow you down, and at worst you have a couple of allocations that won't cause a big spike. > With GC you can try to avoid allocations, but you might miss a couple and get occasional frame stutters anyway every now and then. Also avoiding allocation is a whole lot harder in languages that use a GC for everything than languages that provide an alternative Something that I think doesn't get the attention it deserves in Rust is how explicit it makes allocations at the type level. You don't have a pointer that maybe points to the heap and maybe to the stack (or in the case of GC maybe even is on the stack right now but won't be when you change how it's used later) or a slice that you need to track down whether it originated as a reference to a fixed-size array or if it it's dynamically allocated; you have either type that you know is a reference like &T or &str or a slice, or you have a type you know was allocated on the heap like a Box or an Arc or a String or a Vec. I've seen people need to spend a lot of time profiling projects in other languages to track down where they can optimize their memory usage. I wonder if people who are skeptical of languages with expressive type systems might see the benefits more if they were presented less in terms of what the type system provides you directly, but in terms of what it makes available for tooling to take advantage of; in the case of using the type system to track allocations, the advantage might seem limited to your own code and not helpful when handling dependencies without being willing to dive into their code, but I think it's easy to overlook that having the information available statically makes it possible for tooling to utilize it, and that applies just as much to dependencies.
  - dadoum 3y ago
    In D you have 2 options to deal with that: - As you described, you can disable the GC to do your thing. That's not the solution I would recommend, but if you call GC.disable then the GC won't collect anything until you enable it back (or if the program is running out of memory). - You can mark a function as @nogc, and then the compiler will prevent you from allocating anything that could trigger GC allocation. There is some level of support for @nogc in the language and few libraries to help, the issue is more in the standard library which relies a lot on the GC.
naasking 3y ago
> GC pauses: very slow (until Go anyway) If by "slow" you mean "high latency", then this isn't true. Plenty of GC algorithms provide guaranteed sub-millisecond pauses.
- IshKebab 3y ago
  It wasn't the norm until Go focused on it though, and "sub milliseconds" is not a high bar. Malloc is much much faster than that.
  - naasking 3y ago
    > It wasn't the norm until Go focused on it though It's still not the norm, but the point is that those were available > and "sub milliseconds" is not a high bar. Malloc is much much faster than that. Malloc is not guaranteed to return in that time frame. The sub-millisecond latency of these GCs is a real-time guarantee.
    - IshKebab 3y ago
      > Malloc is not guaranteed to return in that time frame No but in practice it always does.
      - naasking 3y ago
        It doesn't though, which is why malloc is rarely used in embedded and realtime systems.