On Thu, Oct 17, 2013 at 9:46 AM, Jonathan S. Shapiro <[email protected]>wrote: > > The several (very clever) structural optimizations that you identify are > great, but they are not what I was trying to talk about. >
I think we are talking aside each-other. My point was not to promote specific structural optimizations, but to talk about how the raw-mutator throughput of a memory-collection design can be less important than the constraints it places on macro-level system optimization. Including, COW forking, pauses, SIMD, threading, memory sharing, etc, etc, etc. > There's actually a hidden pause in reference counting as well. > Decrementing a counter can cause a cascade of deallocations. This is not a hidden cost. This is an explicit cost of an explicit action, just like calilng free() on lots of stuff. If you don't want to incur the cost now, then don't release the reference. GC tracing is a hidden cost, because in between two instructions which don't allocate or deallocate you can lose alot of time to the GC. In fact, you can lose lots of time to a full heap trace that doesn't even free up much memory! All I was really trying to say is that reference counting doesn't make > sense (from a performance perspective) unless you apply some care and > thought to how you go about it. > How do you classify iOS and Python's reference counting on the spectrum of "don't make sense" vs "apply some care"? Both of them are used for many many very successful applications. (with quite low end-user perceived latencies) AFAIK... - neither iOS/ObjC or Python do release-deferral. - I have not looked at this code, but i'd guess python is pretty 'naive' about reference counts - ObjC benefits from pointer 'borrowing', because it's effectively RC assisted manual management - ObjC has a more sophisticated optimization to deal with free-threading<http://stackoverflow.com/questions/13942226/how-does-apples-objective-c-runtime-do-multithreaded-reference-counting-without> .
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
