5 ms·

The nice thing about designing your own hardware stack: >fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nan

The nice thing about designing your own hardware stack: >fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nanoseconds on an M1 https://twitter.com/Catfish_Man/status/1326238434235568128 https://twitter.com/Catfish_Man/status/1326238434235568128

astrange 5y ago
This has nothing to do with custom hardware, it's one of the few differences that's actually due to ARM vs x86. Though, part of it is from being a unified memory SoC.
- Tagbert 5y ago
  I heard in an interview with Craig Federighi, that in designing the Apple Silicon chips they had looked at specific operations that were frequently used by their OS and software and optimized those on their chips. Reference counting was one of those operations and that was why the speed of that operation was so much faster on Apple Silicon. Sure those other things about unified memory contribute speed to all kinds of operations, but they really focused on some of them to let their hardware and software work well together.
  - astrange 5y ago
    Choosing to use ARM and unified memory is part of designing the SoC, though. There is no magic in the refcount machinery; you can disassemble it and look at it.
pjmlp 5y ago
Now try Swift outside that hardware stack.
- aeldidi 5y ago
  I agree with the sentiment, but does Swift actually see any usage outside of Apple’s own hardware? I think Swift’s reliance on such an optimization is justified since the hardware this optimization is applied to is the main target. While Swift’s approach may be slower in theory, is it actually slower in practice? Just a thought.
  - pjmlp 5y ago
    Hardly, but having to design hardware to fix ARC performance, proves the point how much "better" it is. Depends how much one cares about performance beyond iOS GUI apps, specially when Swift's original goal was to become the main language across the whole Apple stack. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages
- GeekyBear 5y ago
  Swift has been used to write parts of MacOS that are used on Intel today. The good faith efforts to write parts of a consumer OS in a garbage collected language that I can remember are Microsoft's effort to write Longhorn in C# and Google's effort to write part of Fuchsia in Go. Both efforts failed for performance reasons.
  - vips7L 5y ago
    Go has a bad GC. Go relies on the compiler to do escape analysis and allocate on the stack. Once you actually start heap allocating you hit massive pauses. It’s why Go does so bad on the binary tree benchmark.
    - jatone 5y ago
      > Once you actually start heap allocating you hit massive pauses. citation needed. go afaik has millisecond pauses at most. maybe you're thinking of throughput losses due to forcing more CPU to be spent on collecting?
  - pjmlp 5y ago
    Wrong, Longhorn failed because WinDev sabotaged the project. https://news.ycombinator.com/item?id=30486727 https://news.ycombinator.com/item?id=30486727 Likewise, Midori was powering Asian Bing cluster for a while, and even that wasn't good enough for WinDev. And in Fuchsia, same thing happened, the parts in Go were only taken away when the Go advocates that driven those modules were no longer around to argue for their implementations. Politics are more relevant than technical limitations. Finally, Azure Cloud OS and Windows together have surely more lines of C# powering them than Apple has been doing with Swift. And then there is Android.
    - GeekyBear 5y ago
      The leaked builds of Longhorn took forever just to boot on the hardware of the era. That's a performance issue. However, the internal politics of Microsoft certainly didn't help either. The stated reasons for removing the Go portions of Fuchsia and rewriting them in another language were also firmly based in performance.

astrange 5y ago

This has nothing to do with custom hardware, it's one of the few differences that's actually due to ARM vs x86. Though, part of it is from being a unified memory SoC.

Tagbert 5y ago
I heard in an interview with Craig Federighi, that in designing the Apple Silicon chips they had looked at specific operations that were frequently used by their OS and software and optimized those on their chips. Reference counting was one of those operations and that was why the speed of that operation was so much faster on Apple Silicon. Sure those other things about unified memory contribute speed to all kinds of operations, but they really focused on some of them to let their hardware and software work well together.
- astrange 5y ago
  Choosing to use ARM and unified memory is part of designing the SoC, though. There is no magic in the refcount machinery; you can disassemble it and look at it.

pjmlp 5y ago

Now try Swift outside that hardware stack.

aeldidi 5y ago
I agree with the sentiment, but does Swift actually see any usage outside of Apple’s own hardware? I think Swift’s reliance on such an optimization is justified since the hardware this optimization is applied to is the main target. While Swift’s approach may be slower in theory, is it actually slower in practice? Just a thought.
- pjmlp 5y ago
  Hardly, but having to design hardware to fix ARC performance, proves the point how much "better" it is. Depends how much one cares about performance beyond iOS GUI apps, specially when Swift's original goal was to become the main language across the whole Apple stack. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages
GeekyBear 5y ago
Swift has been used to write parts of MacOS that are used on Intel today. The good faith efforts to write parts of a consumer OS in a garbage collected language that I can remember are Microsoft's effort to write Longhorn in C# and Google's effort to write part of Fuchsia in Go. Both efforts failed for performance reasons.
- vips7L 5y ago
  Go has a bad GC. Go relies on the compiler to do escape analysis and allocate on the stack. Once you actually start heap allocating you hit massive pauses. It’s why Go does so bad on the binary tree benchmark.
  - jatone 5y ago
    > Once you actually start heap allocating you hit massive pauses. citation needed. go afaik has millisecond pauses at most. maybe you're thinking of throughput losses due to forcing more CPU to be spent on collecting?
- pjmlp 5y ago
  Wrong, Longhorn failed because WinDev sabotaged the project. https://news.ycombinator.com/item?id=30486727 https://news.ycombinator.com/item?id=30486727 Likewise, Midori was powering Asian Bing cluster for a while, and even that wasn't good enough for WinDev. And in Fuchsia, same thing happened, the parts in Go were only taken away when the Go advocates that driven those modules were no longer around to argue for their implementations. Politics are more relevant than technical limitations. Finally, Azure Cloud OS and Windows together have surely more lines of C# powering them than Apple has been doing with Swift. And then there is Android.
  - GeekyBear 5y ago
    The leaked builds of Longhorn took forever just to boot on the hardware of the era. That's a performance issue. However, the internal politics of Microsoft certainly didn't help either. The stated reasons for removing the Go portions of Fuchsia and rewriting them in another language were also firmly based in performance.