6 ms·

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++

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.
      - pebal 4y ago
        Can't atomically assign a pointer and increment a counter, need to use a lock. If make a long list using shared_ptr will overflow the stack when the head destructor executes.
        CyberDildonics 4y ago
        Can't atomically assign a pointer and increment a counter You can do that in multiple ways. First you can use the extra bits of a pointer for a counter to fit it all into 64 bits. Second, you can use a 128 bit compare and swap which has been supported by CPUs for about 20 years now. Third, you can not use pointers and use indices of whatever bit resolution you want, using the extra bits for a counter. Finally, how does a garbage collector change this ? If make a long list using shared_ptr will overflow the stack when the head destructor executes. If we set aside for a second the insanity in making a linked list where every pointer destruction calls the next pointer in the list's destructor, how is this unique to a shared_ptr ?
        pebal 4y ago
        Did you know that the counter is stored in a different place than the pointer? All current atomic<shared_ptr> implementations use a lock. Stack overflow is not unique to a shared_ptr, but GC pointers don't have this problem. The reference counting has advantages, but it cannot fully replace GC pointers.

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.
    - pebal 4y ago
      Can't atomically assign a pointer and increment a counter, need to use a lock. If make a long list using shared_ptr will overflow the stack when the head destructor executes.
      - CyberDildonics 4y ago
        Can't atomically assign a pointer and increment a counter You can do that in multiple ways. First you can use the extra bits of a pointer for a counter to fit it all into 64 bits. Second, you can use a 128 bit compare and swap which has been supported by CPUs for about 20 years now. Third, you can not use pointers and use indices of whatever bit resolution you want, using the extra bits for a counter. Finally, how does a garbage collector change this ? If make a long list using shared_ptr will overflow the stack when the head destructor executes. If we set aside for a second the insanity in making a linked list where every pointer destruction calls the next pointer in the list's destructor, how is this unique to a shared_ptr ?
        pebal 4y ago
        Did you know that the counter is stored in a different place than the pointer? All current atomic<shared_ptr> implementations use a lock. Stack overflow is not unique to a shared_ptr, but GC pointers don't have this problem. The reference counting has advantages, but it cannot fully replace GC pointers.