4 ms·

with RC being an escape hatch only I don't know what you mean by escape hatch, but it generally just isn't necessary and memory is managed automatically by sco

with RC being an escape hatch only I don't know what you mean by escape hatch, but it generally just isn't necessary and memory is managed automatically by scope. The bigger point here is that it just isn't a significant part of execution time. But there are plenty of problems/programs where you simply can’t know the lifetime of your objects Like what? I can only think of one, which is passing memory allocated in one thread to another thread. Chrome uses a proper GC for C++ as well This is an anecdote, it doesn't prove or disprove anything in the bigger picture.

kaba0 4y ago
> managed automatically by scope That’s just an implementation detail. The point is that the object’s lifetime is only known at runtime and will be reclaimed when a counter reaches zero, this is reference counting. Whether you have to manually inc/dec that counter, or the language does it for you through some abstraction is besides the point, it is automatic memory management either way, as it.. manages memory automatically. > Like what? I can only think of one, which is passing memory allocated in one thread to another thread Any programming language, both parsing into an AST, AST manipulations, interpretation (and that is a very wide category, not only for things you would think of as proper languages). But even some games may want to use GC for some in-game objects, as the lifetime of those is fundamentally dependent on user action. Would the litany of managed languages and their widespread usage be less anecdotal?
- CyberDildonics 4y ago
  I'm not sure what points you are trying to make now, but originally you were talking about reference counting being slow and I was saying in a language like C++ it has no impact on performance because it is only necessary when giving memory allocated in one thread to another thread. both parsing into an AST, AST manipulations, interpretation even some games may want to use GC for some in-game objects, as the lifetime of those is fundamentally dependent on user action Here you are conflating the lifetime of resources inside the various scopes of a program with dynamic resources in a game. These are not the same thing. Language level reference counting will not save you or help you to know when to unload a level or a texture. Just because there is control over resources doesn't mean reference counting. Likewise even in something like java you need to set links to heap allocated objects to null so that they can be garbage collected. The language doesn't magically know when you need to unload a level.
  - kaba0 4y ago
    Because reference counting is slow. Sure, if you use it for 2 objects that are always in scope you won’t see its effect, but I would argue about “using RC” at all with such a small number. > only necessary when giving memory allocated in one thread to another thread RC count can be larger than one even when only a single thread using it. But I’m not familiar with this usage and it is not really RC for memory management anymore, more like a lock-less data structure. I wasn’t talking about texture/level loading/unloading because it is more complex, but things like using scripting languages for part of the game logic.
    - CyberDildonics 4y ago
      Because reference counting is slow. I think you're just repeating yourself, but I'm not sure what question you're answering. RC count can be larger than one even when only a single thread using it. But I’m not familiar with this usage and it is not really RC for memory management anymore, more like a lock-less data structure. I don't understand what you are saying here. things like using scripting languages for part of the game logic. Scripting languages are slow for a lot of reasons, like pointer chasing and excessive memory allocations. Reference counting is a very small piece of that puzzle.
      - pebal 4y ago
        Reference counting has limitations. It does not release cyclic structures, not suitable for lock-free algorithms and may overflow the stack.
        CyberDildonics 4y ago
        It does not release cyclic structures I don't think anyone is debating that. not suitable for lock-free algorithms and may overflow the stack. This you will have to explain. I see people make vague assertions like this but I never see a good explanation.
        4y ago
tsimionescu 4y ago
> Like what? I can only think of one, which is passing memory allocated in one thread to another thread. How would you implement a graph that requires heap allocation for each node and supports adding/removing nodes and links with purely scope-based memory management (no shared_ptr or equivalent, no tracing GC), while still reclaiming memory as soon as possible (so no arena-based solutions)? There are also single-threaded concurrent scenarios where object ownership can be ambiguous, but those are similar to the multi-threaded scenarios you discuss.
- CyberDildonics 4y ago
  In the case of nodes in a graph, you have to keep track of where the connections go anyway, so you can count the list of connections.

kaba0 4y ago

> managed automatically by scope That’s just an implementation detail. The point is that the object’s lifetime is only known at runtime and will be reclaimed when a counter reaches zero, this is reference counting. Whether you have to manually inc/dec that counter, or the language does it for you through some abstraction is besides the point, it is automatic memory management either way, as it.. manages memory automatically. > Like what? I can only think of one, which is passing memory allocated in one thread to another thread Any programming language, both parsing into an AST, AST manipulations, interpretation (and that is a very wide category, not only for things you would think of as proper languages). But even some games may want to use GC for some in-game objects, as the lifetime of those is fundamentally dependent on user action. Would the litany of managed languages and their widespread usage be less anecdotal?

CyberDildonics 4y ago
I'm not sure what points you are trying to make now, but originally you were talking about reference counting being slow and I was saying in a language like C++ it has no impact on performance because it is only necessary when giving memory allocated in one thread to another thread. both parsing into an AST, AST manipulations, interpretation even some games may want to use GC for some in-game objects, as the lifetime of those is fundamentally dependent on user action Here you are conflating the lifetime of resources inside the various scopes of a program with dynamic resources in a game. These are not the same thing. Language level reference counting will not save you or help you to know when to unload a level or a texture. Just because there is control over resources doesn't mean reference counting. Likewise even in something like java you need to set links to heap allocated objects to null so that they can be garbage collected. The language doesn't magically know when you need to unload a level.
- kaba0 4y ago
  Because reference counting is slow. Sure, if you use it for 2 objects that are always in scope you won’t see its effect, but I would argue about “using RC” at all with such a small number. > only necessary when giving memory allocated in one thread to another thread RC count can be larger than one even when only a single thread using it. But I’m not familiar with this usage and it is not really RC for memory management anymore, more like a lock-less data structure. I wasn’t talking about texture/level loading/unloading because it is more complex, but things like using scripting languages for part of the game logic.
  - CyberDildonics 4y ago
    Because reference counting is slow. I think you're just repeating yourself, but I'm not sure what question you're answering. RC count can be larger than one even when only a single thread using it. But I’m not familiar with this usage and it is not really RC for memory management anymore, more like a lock-less data structure. I don't understand what you are saying here. things like using scripting languages for part of the game logic. Scripting languages are slow for a lot of reasons, like pointer chasing and excessive memory allocations. Reference counting is a very small piece of that puzzle.
    - pebal 4y ago
      Reference counting has limitations. It does not release cyclic structures, not suitable for lock-free algorithms and may overflow the stack.
      - CyberDildonics 4y ago
        It does not release cyclic structures I don't think anyone is debating that. not suitable for lock-free algorithms and may overflow the stack. This you will have to explain. I see people make vague assertions like this but I never see a good explanation.
        4y ago

tsimionescu 4y ago

> Like what? I can only think of one, which is passing memory allocated in one thread to another thread. How would you implement a graph that requires heap allocation for each node and supports adding/removing nodes and links with purely scope-based memory management (no shared_ptr or equivalent, no tracing GC), while still reclaiming memory as soon as possible (so no arena-based solutions)? There are also single-threaded concurrent scenarios where object ownership can be ambiguous, but those are similar to the multi-threaded scenarios you discuss.

CyberDildonics 4y ago
In the case of nodes in a graph, you have to keep track of where the connections go anyway, so you can count the list of connections.