tag:blogger.com,1999:blog-8397311766319215218.post7418129419962429400..comments2023-11-29T18:05:17.337+01:00Comments on metablog: M1 Memory and PerformanceMarcel Weiherhttp://www.blogger.com/profile/11651004661887001433noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-8397311766319215218.post-84414813508757487122022-05-01T03:50:52.144+02:002022-05-01T03:50:52.144+02:00"The benefit of sticking to RC is much-reduce..."The benefit of sticking to RC is much-reduced memory consumption. It turns out that for a tracing GC to achieve performance comparable with manual allocation, it needs several times the memory (different studies find different overheads, but at least 4x is a conservative lower bound)."<br /><br />All of the evidence I have seen shows precisely the opposite, e.g.: https://programming-language-benchmarks.vercel.app/ocaml-vs-swift<br />Jon Harrophttps://www.blogger.com/profile/11059316496121100950noreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-6742731659854115532020-11-25T02:37:50.337+01:002020-11-25T02:37:50.337+01:00One of the most loved and fastest growing programm...One of the most loved and fastest growing programming languages outside of Apple is Rust, which also uses retain/release by default instead of a GC. That language also compiles to WebAssembly, so I wouldn't count the web out just yet in terms of performance.Billyhttps://www.blogger.com/profile/03186773166703979971noreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-22714786715624971652020-11-20T14:18:43.686+01:002020-11-20T14:18:43.686+01:00Interesting to read this from 2013
https://seale...Interesting to read this from 2013 <br /><br />https://sealedabstract.com/rants/why-mobile-web-apps-are-slow/index.htmlMike Contehttps://www.blogger.com/profile/05667728181016463247noreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-51601933313072576972020-11-16T10:57:44.045+01:002020-11-16T10:57:44.045+01:00Anon., it seems the benefits you mention derive fr...Anon., it seems the benefits you mention derive from automatic memory allocation, and they would therefore be there regardless of whether that automatic memory allocation is implemented using tracing garbage collection or reference counting. <br /><br />I think reference counting was long considered too slow compared to tracing gc. But, reclaiming aggressively, it (generally) uses substantially less memory. It also does not stop unpredictably, pausing execution for an indeterminate time. With changes in the memory hierarchy relative latencies, reference counting could now outperform gc.<br /><br />Weiher, annotating "strong" etc. is probably "essentially" impossible to get wrong, and you would never, I am sure, being a good, very thorough programmer ;) But if it is possible to get it wrong, some (bad programmer!) is bound to. Also, you want to have as few chores of annotating this and that as possible when coding. Freeing up mental space is very important for productivity. I agree with Anon that automatic memory management should be used except where runtime performance dictates otherwise.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-8757003081206554472020-11-14T08:45:31.755+01:002020-11-14T08:45:31.755+01:00@Anonymous
You seem to have a very different expe...@Anonymous<br /><br />You seem to have a very different experience from mine, and from many if not most developers. I also have written production code in various full GC, RC and fully manual languages. The big difference is the step up from fully manual, because object lifetime is a global problem and you only have local information. Even "semi-manual" RC, incorrectly called MRC, solves that problem, and after that you're talking about very slight differences.<br /><br />You annotate your property as "strong" (or use an objectAccessor() ) and you're done in terms of crashes. Then you go back and add "weak" to back-references and you've taken care of leaks, and quite frankly the amount of leakage tends to be less than GC overhead. Not sure how you're managing to get crashes attributable to memory at that point.<br /><br />Swift falling over its own feet is a different matter, I would say.<br /><br />GCD is actually worse than threads in most cases, the whole idea of using closures for concurrency is just nuts and using them for "callbacks" is also a fairly stupid idea, for a bunch of reasons. So yes, if you're using extremely closure-heavy code, then that might be a problem, but it won't be your only problem, . Closure-heavy code is essentially non-comprehensible and non-debuggable.<br /><br />And notice I wrote "the convenience level" is <i>essentially</i> indistinguishable, not that the overall experience is indistinguishable. What you casually dismiss as "might have to spend some time tuning it" can be a never-ending nightmare, which in the end you cannot actually solve. See the high-perf Java programs that have to roll their own memory management off the Java heap. <br /><br />Compared to having to implement your own completely custom memory management, having to think for a second whether "strong" or "weak" is correct seems rather easier.<br /><br /><br /><br />Marcel Weiherhttps://www.blogger.com/profile/11651004661887001433noreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-40990097978414495192020-11-14T02:56:24.211+01:002020-11-14T02:56:24.211+01:00"With increased automation of those reference..."With increased automation of those reference counting operations and the addition of weak references, the convenience level for developers is essentially indistinguishable from a tracing GC now."<br /><br />I cannot imagine what would lead someone to make such a claim. I've been writing Swift and Objective-C since the MRC days, and also various languages which have a full tracing GC. Apple's platforms have made it much easier to use than it used to be, but in the convenience department, it's never going to be a match for GC.<br /><br />Defaults matter, and GC's default is "it just works". With a GC, you might have to spend some time tuning it, but I've never had to spend time tracking down a memory-related crash. That's not true of any real-world Cocoa program I've worked on. (Swift is so complex that for a while the compiler would happily generate a double-free for you in some cases!) Apple's own apps still crash pretty regularly.<br /><br />Minimizing memory usage is great for the hardware vendor and for the user, but it sucks for the developer. These are not just theoretical concerns. I see people online struggling with [weak self] on trivial closures every day, and no other platform has this problem. ARC might be a worthwhile tradeoff, but it's definitely a tradeoff.<br /><br />You may as well try to convince me that GCD is as good as Erlang for concurrency. They're both "not plain C threads", but that's where the similarities end. Nobody would ever mistake one for the other.<br />Anonymousnoreply@blogger.com