4 ms·
In language garbage collection just makes implementing a compiler that much harder to do and frankly bloats up the runtime. Basic c++ shared pointers take up p
by bnolsen 13y ago
In language garbage collection just makes implementing a compiler that much harder to do and frankly bloats up the runtime. Basic c++ shared pointers take up pretty much 90+% of what people need in GC (non stupid software architecture decisions should make up the remaining 10%).
I have seen problems with stalling caused by kernel memory heap defragging on linux resulting in some serious thrashing. What that means is that the issue of heap fragmentation can be a problem regardless of which language used.
- pjmlp 13y agoUnless you happen to have a compacting GC. :)
- gillianseed 13y agoWell since compacting means the expensive task of moving managed memory blocks around to free larger sections that solution certainly comes with a big penalty of it's own. Better to avoid heap fragmentation to such extents by applying a better allocation strategy imo.
- betterunix 13y agoThat is why generational collectors are so good. It is not common to have huge blocks of memory than also happen to be short lived, and if you do have such a design, you can probably refactor it (or just not use garbage collection there, which any production-grade programming environment should allow by some means).
- gsg 13y agoReference counting, even ignoring the additional expense C++ places on std::shared_ptr by requiring it be thread safe, is far too slow for allocation heavy languages. Only "we don't give a damn" implementations (like CPython) use it, because it is simply not competitive.
- pcwalton 13y agoNot necessarily true. See "Down for the Count?" ISMM 2012: http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2...
- gsg 13y ago"This brings the performance of reference counting on par with that of a well tuned mark-sweep collector." I'm not really convinced. How well does it stack up when the competition is a copying generational collector?
- pcwalton 13y agoThey compare against a copying collector.
- pkolaczk 13y ago... implemented in Jikes RVM which is very far behind Oracle JVM. Herz and Berger (2005) based their experiment on Jikes RVM, too, and incorrectly concluded that GC needs 5x more memory to have acceptable performance comparable to malloc/free. Someone else redid their experiments using Oracle JVM and it turned out that it was not 5x, but 20%.
- a8da6b0c91d 13y agoshared_ptr may be slow (I don't know) but you actually make very little "garbage" in C++, so it's not a problem. You're simply forced by the language to have clear ownership of resources most of the time.
- comex 13y agoThis, and if you're using shared_ptr heavily in C++, you're probably doing it wrong, since unique_ptr is usually sufficient. (You could say that shared_ptr has the advantage that you don't have to think about who owns what, but with C++ there's no way around doing some amount of thinking about that, lest you get cycles.)
- ExpiredLink 13y agoshared pointers? You must be joking!
- betterunix 13y ago"In language garbage collection just makes implementing a compiler that much harder to do" A simple copying or mark-and-sweep collector is far easier to write than even basic dataflow-analysis optimizations. Implementor effort is hardly an argument against garbage collection; implementing efficient garbage collection is no worse than implementing a good optimizer or efficient code generation. "Basic c++ shared pointers take up pretty much 90+% of what people need in GC" They do so in a way that is right in the programmers face, adding needless effort to writing software, and can actually wind up being slower than a modern garbage collector. Shared pointers are a mistake, not quite as bad as auto_ptr but pretty bad nonetheless; the committee should have just introduced a garbage-collected smart pointer class and kept things simple (I guess that would not be the C++ way, though).