6 ms·

Perhaps? Most scenarios that explicitly involve .NET's GC vs Swift's ARC display much better performance of the former, to the point where the fact that ARC doe

Perhaps? Most scenarios that explicitly involve .NET's GC vs Swift's ARC display much better performance of the former, to the point where the fact that ARC does not have GC pauses does not help if the whole things is multiple times slower, in many ways it's like Go's """low-pause""" GC design discussions that completely ignore allocation throttling and write barrier cost. Swift lacking proper performant GC is a disadvantage. Upcoming features solve it by likely enabling more scenarios to sidestep ARC, but their impact on the Swift as a whole, and user applications that use them, is yet to be seen. It's important to always remember - there's no free lunch. I'm sad that Miguel de Icaza seems to have a bone to pick with C# nowadays, but it's not surprising given Xamarin story.

astrange 2y ago
> Perhaps? Most scenarios that explicitly involve .NET's GC vs Swift's ARC display much better performance of the former By which you mean "less CPU cycles on a desktop machine with plenty of memory"? That's not when ARC is more performant; it's better on smaller devices that are under memory pressure and have swapped out some of your memory. In which case you have to swap it back in to go scan for pointers. And if you're a low-priority daemon then you evict higher priority pages in the process.
- neonsunset 2y ago
  Perhaps? You assume GC takes unreasonably more space. It's purely a function of a tradeoff between running it more frequently, tuning heap sizing algortithms, choosing to run them as part of allocation calls on the same thread, sacrificing throughput in the process. GC can be more compact than what you assume. Modern good GC implementation are precise and don't have to mark dead GC roots as live, even within a scope of a single method. .NET and I assume Java GC implementations work this way - that's what "precise" means in "precise tracing GC".
  - astrange 2y ago
    It's not that it takes more space, it's that it has to read memory more often. Not all memory pages have the same cost to read. Most memory swapping on most people's home computers is from web browsers for this reason; it's part that everyone uses them, but it's also because they're running JavaScript. And they're pretty well tuned, too.
    - neonsunset 2y ago
      > it's that it has to read memory more often Wait until you learn about "reads become writes with ARC" :) ARC as implemented by Swift, on top of ObjCs retain and release, is design that has an advantage in being more simple, but at the same time worse at other key aspects like throughput, contention, memory traffic and sometimes even memory efficiency. Originally, Swift was meant to use GC, but this failed because Apple could not integrate it well enough with existing Objective-C code, leading to a very crash-prone solution. Also, JavaScript has nothing to do with the lower in abstraction languages discussed in this chain of comments.
      - astrange 2y ago
        You're lecturing me about my job here. I don't need to learn nothin'. > reads become writes with ARC That's not a big problem (it is a problem but a smaller one) since you can choose a different tradeoff wrt whether you keep the reference counting info on the same page or not. There's other allocator metadata with the same issue though. A more interesting one comes up with GC too; if you're freeing all the time, everyone compresses their swap these days, which means zeroing the freed allocations is suddenly worth it because it compresses so much better. > Originally, Swift was meant to use GC, but this failed because Apple could not integrate it well enough with existing Objective-C code, leading to a very crash-prone solution. It was Objective-C that had the GC (a nice compacting one too) and it failed mostly for that reason, but has not come back because of the performance issues I mentioned. > Also, JavaScript has nothing to do with the lower in abstraction languages discussed in this chain of comments. Oh, people definitely want to use it in the same places and will if you don't stop them. See how everyone's writing apps in Electron now.

astrange 2y ago

> Perhaps? Most scenarios that explicitly involve .NET's GC vs Swift's ARC display much better performance of the former By which you mean "less CPU cycles on a desktop machine with plenty of memory"? That's not when ARC is more performant; it's better on smaller devices that are under memory pressure and have swapped out some of your memory. In which case you have to swap it back in to go scan for pointers. And if you're a low-priority daemon then you evict higher priority pages in the process.

neonsunset 2y ago
Perhaps? You assume GC takes unreasonably more space. It's purely a function of a tradeoff between running it more frequently, tuning heap sizing algortithms, choosing to run them as part of allocation calls on the same thread, sacrificing throughput in the process. GC can be more compact than what you assume. Modern good GC implementation are precise and don't have to mark dead GC roots as live, even within a scope of a single method. .NET and I assume Java GC implementations work this way - that's what "precise" means in "precise tracing GC".
- astrange 2y ago
  It's not that it takes more space, it's that it has to read memory more often. Not all memory pages have the same cost to read. Most memory swapping on most people's home computers is from web browsers for this reason; it's part that everyone uses them, but it's also because they're running JavaScript. And they're pretty well tuned, too.
  - neonsunset 2y ago
    > it's that it has to read memory more often Wait until you learn about "reads become writes with ARC" :) ARC as implemented by Swift, on top of ObjCs retain and release, is design that has an advantage in being more simple, but at the same time worse at other key aspects like throughput, contention, memory traffic and sometimes even memory efficiency. Originally, Swift was meant to use GC, but this failed because Apple could not integrate it well enough with existing Objective-C code, leading to a very crash-prone solution. Also, JavaScript has nothing to do with the lower in abstraction languages discussed in this chain of comments.
    - astrange 2y ago
      You're lecturing me about my job here. I don't need to learn nothin'. > reads become writes with ARC That's not a big problem (it is a problem but a smaller one) since you can choose a different tradeoff wrt whether you keep the reference counting info on the same page or not. There's other allocator metadata with the same issue though. A more interesting one comes up with GC too; if you're freeing all the time, everyone compresses their swap these days, which means zeroing the freed allocations is suddenly worth it because it compresses so much better. > Originally, Swift was meant to use GC, but this failed because Apple could not integrate it well enough with existing Objective-C code, leading to a very crash-prone solution. It was Objective-C that had the GC (a nice compacting one too) and it failed mostly for that reason, but has not come back because of the performance issues I mentioned. > Also, JavaScript has nothing to do with the lower in abstraction languages discussed in this chain of comments. Oh, people definitely want to use it in the same places and will if you don't stop them. See how everyone's writing apps in Electron now.