3 ms·
> Swift does not use virtual machine and garbage collection, it competes more to c++ and rust Doesn't it use ARC by default?
by timeon 2y ago
> Swift does not use virtual machine and garbage collection, it competes more to c++ and rust
Doesn't it use ARC by default?
- azinman2 2y agoWhich is reference counting, not garbage collection. Ref counts free when count = 0. Garbage collection scans all object pointers and looks for loops / no missing pointers.
- vor_ 2y agoReference counting is a kind of garbage collection.
- mkl 2y agoThat's tracing garbage collection. Reference counting is another type of garbage collection. https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Strategies https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...
- derrasterpunkt 2y agoReference counting is not tracing garbage collection. To also quote a Wikipedia Link: „The main advantage of the reference counting over tracing garbage collection is that objects are reclaimed as soon as they can no longer be referenced, and in an incremental fashion, without long pauses for collection cycles and with clearly defined lifetime of every object.“ + https://en.wikipedia.org/wiki/Reference_counting https://en.wikipedia.org/wiki/Reference_counting
- vor_ 2y ago> Reference counting is not tracing garbage collection. ??? They didn't say it was.
- mkl 2y agoOf course reference counting is not tracing garbage collection. I never said it was. The comment I replied to claimed reference counting was not garbage collection at all and seemed to think tracing garbage collection was the only kind of garbage collection. Reference counting and tracing garbage collection are two different types of garbage collection.
- synergy20 2y agoit does, I thought ARC is more performant than GC and has no stop-the-world issue,thus not a GC
- pebal 2y agoARC is a variation of GC. Besides, a tracing GC doesn't have to stop the world at all.
- neonsunset 2y agoUsually, it's the other way around: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... binary-trees is almost completely dominated by the time spent in allocator code, and stresses its throughput. This benchmark showcases how big of a gap is between manual per-thread arenas, then tracing generational multi-heap GCs, then ARC and more specialized designs like Go GC. Honorable mention goes to BEAM which also showcases excellent throughput by having process-level independent GCs, in this case resembling the behavior of .NET's and OpenJDK GC implementations.
- astrange 2y agoA tree is indeed a bad fit for RC; so is anything else where you have multiple references to something but know there is a single real owner. I'd suggest keeping strong references to all the tree nodes in an array, then having everything within the tree be unowned. Basically fake arena allocation. Actually, the way it's written: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-swift-3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... is a common way you see toy data structures code written, but it's inefficient (because pointer chasing is slow) and there's better patterns. If you use the arena method above, you could use indexes into the arena. If not, intrusive data structures (where the references are inside Node instead of inside Tree) are better.
- neonsunset 2y agoPointer chasing is irrelevant here. It takes <= 15% of the execution time, and CPUs have gotten good at it. If it takes more - it speaks more about the quality of the allocator which has poor memory locality. As noted in my previous comment, it is dominated by the time spent in the allocator/GC code. Please read https://benchmarksgame-team.pages.debian.net/benchmarksgame/description/binarytrees.html#binarytrees https://benchmarksgame-team.pages.debian.net/benchmarksgame/... The requirement to implement the same algorithm with the same data structure is what makes this benchmark interesting and informative. Don't tell me "allocate parent object A, allocate child objects C, D and E and assign them to A's fields, then allocate array F and G, and assign them to D's fields" isn't the bread and butter of all kinds of application logic, something that this benchmark stresses.