4 ms·

It's quite similar to Rust... if Rust literally used Arc<Mutex<T>> everywhere. And Arc<Mutex<T>> everywhere might actually have lower throughput than tracing G

It's quite similar to Rust... if Rust literally used Arc<Mutex<T>> everywhere. And Arc<Mutex<T>> everywhere might actually have lower throughput than tracing GC! (Though it's arguably preferable for low-latency code, so it might make some sense for the typical use cases of ObjC and Swift.)

terhechte 8y ago
That's not entirely true, it would be similar to `Arc<T>` everywhere, because the Swift compiler and the language are by default not concurrency safe (there're runtime features to detect issues here, similar to RefCell though). This means that Rust has to use `Arc<Mutex<T>>` in order to satisfy the compiler, Swift gets away with `Arc<T>` (and I'm currently not sure, but it might even be only `Rc<T>`) because the compiler doesn't prevent it.
dep_b 8y ago
The advantage of ARC is that the cost of deallocating is very constant and always happens at the same moment. This helps enormously when you are doing performance sensitive stuff like scrolling over a list of complex cells. With the Java style of GC the minimum and maximum cost and timing of GC are just not so predictable so in real-world scenarios ARC based apps feel more fluent. It's like playing games. You'll notice the 10FPS dips more than the difference between 50FPS or 60FPS on average.
- pjmlp 8y ago
  Not really. Cascading deletes of highly nested data structures are similar to pause the world in tracing GCs. If the way destruction is triggered does not take this into account, stack overflows are bound to happen. Finally it introduces slowdowns in shared data structures used across threads. Herb Sutter has a very good CppCon talk about these issues. EDIT: Forgot to mention that Swift was the loosing language at CCC talk about implementing device drivers in memory safe languages. All the ones with tracing GC had a better outcome.
  - dep_b 8y ago
    I think nothing of what you just wrote undermines what I just said. > Cascading deletes of highly nested data structures are similar to pause the world in tracing GCs. Which is simply difficult for every language. But even then still more predictable than Java "we'll do it when we feel ready for it" approach.
    - pjmlp 8y ago
      Yet all the languages with a tracing GC wipe the floor of Swift's reference counting implementation. "35C3 - Safe and Secure Drivers in High-Level Languages" https://www.youtube.com/watch?v=aSuRyLBrXgI https://www.youtube.com/watch?v=aSuRyLBrXgI https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages The subject of Herb's talk was actually going through all the reference counting problems to introduce in the end a lightweight implementation of deferred pointers, which isn't nothing more than basic tracing GC. https://www.youtube.com/watch?v=JfmTagWcqoE https://www.youtube.com/watch?v=JfmTagWcqoE
      - dep_b 8y ago
        Well if you think a driver is somewhat similar to a front-end implementation to begin with then it's OK. If "wiping the floor" means what I see on a day by day basis comparing JVM based UI's versus the same thing built in Swift you're probably talking about something different to begin with. I'm talking about predictable performance and guaranteed minimum performance. I don't think you're speaking about the same thing. The video seems to be interesting anyway, so thanks for that.
        pjmlp 8y ago
        Actually it is, that network packet is not going to wait. "Wiping the floor" means getting last place against all tracing GC languages used to research the mentioned paper. Yes, many JVM based UIs do suck, mostly because the authors didn't bother to learn how to use Swing properly by reading books like Filthy Rich Clients. The thing with Swift UIs, is that they are actually C and C++ UIs, given that those are the languages used to implement Core Graphics, Core Animation and Metal. Additionally Cocoa is still mostly Objective-C, with performance critical sections making use of NSAutoreleasePool like in the old good NeXTSTEP days. Coming back to Java, factory automation and high integrity systems are perfectly fine with it. https://www.aicas.com/cms/ https://www.aicas.com/cms/ https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc

terhechte 8y ago

That's not entirely true, it would be similar to `Arc<T>` everywhere, because the Swift compiler and the language are by default not concurrency safe (there're runtime features to detect issues here, similar to RefCell though). This means that Rust has to use `Arc<Mutex<T>>` in order to satisfy the compiler, Swift gets away with `Arc<T>` (and I'm currently not sure, but it might even be only `Rc<T>`) because the compiler doesn't prevent it.

dep_b 8y ago

The advantage of ARC is that the cost of deallocating is very constant and always happens at the same moment. This helps enormously when you are doing performance sensitive stuff like scrolling over a list of complex cells. With the Java style of GC the minimum and maximum cost and timing of GC are just not so predictable so in real-world scenarios ARC based apps feel more fluent. It's like playing games. You'll notice the 10FPS dips more than the difference between 50FPS or 60FPS on average.

pjmlp 8y ago
Not really. Cascading deletes of highly nested data structures are similar to pause the world in tracing GCs. If the way destruction is triggered does not take this into account, stack overflows are bound to happen. Finally it introduces slowdowns in shared data structures used across threads. Herb Sutter has a very good CppCon talk about these issues. EDIT: Forgot to mention that Swift was the loosing language at CCC talk about implementing device drivers in memory safe languages. All the ones with tracing GC had a better outcome.
- dep_b 8y ago
  I think nothing of what you just wrote undermines what I just said. > Cascading deletes of highly nested data structures are similar to pause the world in tracing GCs. Which is simply difficult for every language. But even then still more predictable than Java "we'll do it when we feel ready for it" approach.
  - pjmlp 8y ago
    Yet all the languages with a tracing GC wipe the floor of Swift's reference counting implementation. "35C3 - Safe and Secure Drivers in High-Level Languages" https://www.youtube.com/watch?v=aSuRyLBrXgI https://www.youtube.com/watch?v=aSuRyLBrXgI https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages The subject of Herb's talk was actually going through all the reference counting problems to introduce in the end a lightweight implementation of deferred pointers, which isn't nothing more than basic tracing GC. https://www.youtube.com/watch?v=JfmTagWcqoE https://www.youtube.com/watch?v=JfmTagWcqoE
    - dep_b 8y ago
      Well if you think a driver is somewhat similar to a front-end implementation to begin with then it's OK. If "wiping the floor" means what I see on a day by day basis comparing JVM based UI's versus the same thing built in Swift you're probably talking about something different to begin with. I'm talking about predictable performance and guaranteed minimum performance. I don't think you're speaking about the same thing. The video seems to be interesting anyway, so thanks for that.
      - pjmlp 8y ago
        Actually it is, that network packet is not going to wait. "Wiping the floor" means getting last place against all tracing GC languages used to research the mentioned paper. Yes, many JVM based UIs do suck, mostly because the authors didn't bother to learn how to use Swing properly by reading books like Filthy Rich Clients. The thing with Swift UIs, is that they are actually C and C++ UIs, given that those are the languages used to implement Core Graphics, Core Animation and Metal. Additionally Cocoa is still mostly Objective-C, with performance critical sections making use of NSAutoreleasePool like in the old good NeXTSTEP days. Coming back to Java, factory automation and high integrity systems are perfectly fine with it. https://www.aicas.com/cms/ https://www.aicas.com/cms/ https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc