4 ms·
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 e
by 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 agoReference counting has limitations. It does not release cyclic structures, not suitable for lock-free algorithms and may overflow the stack.
- CyberDildonics 4y agoIt 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 agoCan'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 agoCan'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 agoDid 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.
- CyberDildonics 4y agoI think you're confusing shared_ptr with reference counting as a technique in general. Can you answer the questions I have above without talking about shared_ptr? Stack overflow is not unique to a shared_ptr, but GC pointers don't have this problem No one should ever have this problem. It is a ridiculous way to make a linked list in the first place.
- pebal 4y agoI see you just don't want to see the problem. Look at this document: https://www.open-std.org/jtc1/sc22/WG21/docs/papers/2014/n4162.pdf https://www.open-std.org/jtc1/sc22/WG21/docs/papers/2014/n41...
- CyberDildonics 4y agoYou're still trying to compare one basic smart pointer implementation to garbage collection in general. You told me something was impossible to do without garbage collection and I explained three different ways that I've already done it, then you just keep trying to talk about something that was never up for discussion in the first place. You hallucinated shared_ptr into the conversation from nowhere. Without talking about smart pointers, what am I missing from the list above? Why do some lock free algorithms need garbage collection?
- pebal 4y agoI am writing about shared_ptr because C++ is one of a top language. Read about the ABA problem.