3 ms·
A valid question, happy to enlighten! To get the automatic threading speed improvements, a (region-aware) language might add a `parallel` keyword in front of l
by verdagon 4y ago
A valid question, happy to enlighten!
To get the automatic threading speed improvements, a (region-aware) language might add a `parallel` keyword in front of loops, to temporarily freeze pre-existing memory, thus completely eliminating the overhead to access it. Vale is building this for its generational references [0] model but I hope that more RC-based languages attempt something like it. Can't get much easier than that ;)
Lobster's algorithm doesn't actually incur any additional complexity. It's completely automatic.
Perceus and HVM require immutability, which does require programmer effort, I admit. Pure functional programming just isn't as convenient as imperative programming for most. However, languages are learning to blend mutable and immutable styles, such as Pony [1], Vale [2], and Cone [3]. When a language allows you to create an object imperatively and then freeze it, it's wonderfully easy.
I think the next decade in languages will be about this exact topic: making it easy to have fast and safe code. I think RC will soon bring some very compelling factors to that equation.
[0] https://verdagon.dev/blog/seamless-fearless-structured-concurrency https://verdagon.dev/blog/seamless-fearless-structured-concu...
[1] https://tutorial.ponylang.io/reference-capabilities/reference-capabilities.html https://tutorial.ponylang.io/reference-capabilities/referenc...
[2] https://vale.dev/guide/structs#mutability https://vale.dev/guide/structs#mutability
[3] https://cone.jondgoodwin.com/coneref/refperm.html https://cone.jondgoodwin.com/coneref/refperm.html
- MaxBarraclough 4y agoI 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 4y 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 4y agoYou shouldn’t attribute the difference to the GC algorithm used when there are generations between ios’s CPUs and android’s.
- astrange 4y 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 4y 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.