5 ms·

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 performan

by 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
        dep_b 8y ago
        Well try to use C++ without the C part, see how that goes. C is a part of Objective-C and you can write Swift code that will compile byte for byte into code as performant as C. It's ugly, it's unsafe but it's part of the language and if you need it it's there. You sound like those people that complain that Objective-C is so slow compared to C because NSArray is much slower than it's C counterpart. Objective-C is always exactly as fast as C since you can always write C in Objective-C. And if all Java based UI's suck despite the fact that it's the most popular programming language and despite the fact that it powers the most popular operating system you might start suspecting there's something wrong with it, but nope, you've read a paper and saw a video. About a kernel driver. OK.

by dep_b 8y ago

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
      - dep_b 8y ago
        Well try to use C++ without the C part, see how that goes. C is a part of Objective-C and you can write Swift code that will compile byte for byte into code as performant as C. It's ugly, it's unsafe but it's part of the language and if you need it it's there. You sound like those people that complain that Objective-C is so slow compared to C because NSArray is much slower than it's C counterpart. Objective-C is always exactly as fast as C since you can always write C in Objective-C. And if all Java based UI's suck despite the fact that it's the most popular programming language and despite the fact that it powers the most popular operating system you might start suspecting there's something wrong with it, but nope, you've read a paper and saw a video. About a kernel driver. OK.