4 ms·
I think the real point of their question was along the lines of GC works great and these days it's pretty fast, why research cleverer reference-counting? Will
by MaxBarraclough 5y ago
I think the real point of their question was along the lines of GC works great and these days it's pretty fast, why research cleverer reference-counting?
Will these developments lead to appreciable performance improvements for 'typical' non-embedded, non-real-time programs?
- astrange 5y agoThe fastest system currently out there is iOS, which (as this article says) doesn't use GC and does use clever reference counting, so yes? Note, most people here arguing that GC is actually always faster are forgetting that reading memory itself has a cost, especially in systems with swap or other reasons it might have a /really/ large cost.
- kaba0 5y agoYou shouldn’t attribute the difference to the GC algorithm used when there are generations between ios’s CPUs and android’s.
- astrange 5y agoIf you won't believe me, you could believe Chris in the article. > Chris Lattner: Here’s the way I look at it, and as you said, the ship has somewhat sailed: I am totally convinced that ARC is the right way to go upfront.
- Someone 5y agoI think the consensus is that GC works great _if_ you throw enough memory at it (about three times what you really need) On mobile, the problem with that isn’t as much that memory costs money, but that it costs Joules. Peak power usage of RAM may not be large compared to that of your screen, CPU, GPU, GPS, etc. but AFAIK, with current tech, memory keeps eating energy even if your device is sleeping. Being able to run with less memory, I think, is why iPhones can do with relatively small batteries and yet have decent stand by times.