4 ms·

Apple Silicon is NOT just an ARM CPU. It's also a deep integration with macOS, and a unified memory architecture (less unnecessary copying on the bus). For exam

Apple Silicon is NOT just an ARM CPU. It's also a deep integration with macOS, and a unified memory architecture (less unnecessary copying on the bus). For example on the M1, certain very common operations for macOS apps, like freeing Objective C pointers, which happens millions of time per second, are optimized at the hardware level. The M1 is not a CPU. So no, the Ryzen 5000 with 5nm would NOT level the field.

slver 5y ago
How are objective c pointers handled?
- skohan 5y ago
  From what I understood, ARC operations are cheaper on M1 because of weaker memory ordering constraints. But I thought this was and ARM thing, not M1 specific, but I could be wrong
  - astrange 5y ago
    That's right. M1 doesn't have specific Objective-C optimizations.
    - slver 5y ago
      An interesting realization that it could, though. Overwhelming majority of MacOS/iOS software is written on Obj C and Swift, which have the same underlying semantics. That said ARC doesn't have such a great impact on performance as some people (esp. fans of Java's GC etc.) would convince you. Most ++/-- operations on the refcount are eliminated by the compiler.
      - skohan 5y ago
        The worst case performance is very bad though. I have done some playing around with pushing Swift in terms of performance, and it's very hard because of ARC.
        foobiekr 5y ago
        Code in the fastpath must not generate substantial garbage whether using ARC or a gc. That's just a coding error.
        skohan 5y ago
        It's not about garbage creation, is about reference cost. With ARC, you pay a penalty every time you pass a reference type, not only for memory churn. You can avoid this using value types, but this often results in a lot of unnecessary copying. It's not unavoidable, but Swift doesn't give good tools for avoiding ARC-based performance cliffs, so it takes a lot of profiling and effort compared to other languages.
        astrange 5y ago
        It's ok to generate garbage if it goes away immediately; that's essentially a stack allocation. Performance problems come up when you have a mix of lifetimes. (that slows GCs down and causes heap fragmentation outside copying GCs)
      - pjmlp 5y ago
        Some fans do measure, and know the difference from marketing and reality in regards to tracing GC versus reference counting marketing material. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages
        astrange 5y ago
        Wallclock time isn't the only performance metric to care about. ObjC had a GC in the past and lost it in favor of ARC for a reason; it's a poor fit for iPhone-sized devices.
        pjmlp 5y ago
        That was the marketing reason, the official reason was that fitting a GC into a language with C memory model wasn't never going to work, and there were plenty of crashes and memory corruptions coming out of that. So they made the only sensible decision, and just like Microsoft did with COM, they added support to the Objective-C compiler to automate retain/release messages in OS X Frameworks. Naturally being Apple, that pivot had to be sold in a way that the reason was being of RC being better and not because of the technical failure to have a tracing GC in Objective-C , while remaining compatible with C memory model. Apparently, moving the GC document with all its caveats regarding possible programming issues, out of search index also helps to keep the story as well. https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/GarbageCollection/Introduction.html https://developer.apple.com/library/archive/documentation/Co...
        astrange 5y ago
        No, the performance issues are real. GC programs have more page demand and higher peak memory use, which is specifically what the iOS memory model (jetsam and memory compression) can't deal with well. They can have some wins due to compacting. There is of course a GC language on iOS (JavaScript) but expensive webpages get killed quickly.
        pjmlp 5y ago
- igammarays 5y ago
  I can't find the interview now, but I distinctly remember someone at Apple saying that Cocoa apps benefit from hardware-level optimizations of common Objective C operations in the M1.
skohan 5y ago
But from what I understand, there's a much smaller gap between ryzen and M1 than intel
kllrnohj 5y ago
> and a unified memory architecture (less unnecessary copying on the bus). So does every other Intel & AMD laptop CPU from the last 5+ years. So does every Qualcomm SoC from the last 5+ years. This has been incredibly common for years and years now. This does a lot less than you think it does, particularly since there's very few consumer workloads that switch between CPU & GPU.
rsynnott 5y ago
> For example on the M1, certain very common operations for macOS apps, like freeing Objective C pointers, which happens millions of time per second, are optimized at the hardware level I mean, this is _kind_ of true, but it's not unique to Objective C, the M1, or even particularly intentional. The _ARM_ memory model is more conducive to reference counting in general than the x86 one. Nothing special about Apple's chip in that respect, tho.

slver 5y ago

How are objective c pointers handled?

skohan 5y ago
From what I understood, ARC operations are cheaper on M1 because of weaker memory ordering constraints. But I thought this was and ARM thing, not M1 specific, but I could be wrong
- astrange 5y ago
  That's right. M1 doesn't have specific Objective-C optimizations.
  - slver 5y ago
    An interesting realization that it could, though. Overwhelming majority of MacOS/iOS software is written on Obj C and Swift, which have the same underlying semantics. That said ARC doesn't have such a great impact on performance as some people (esp. fans of Java's GC etc.) would convince you. Most ++/-- operations on the refcount are eliminated by the compiler.
    - skohan 5y ago
      The worst case performance is very bad though. I have done some playing around with pushing Swift in terms of performance, and it's very hard because of ARC.
      - foobiekr 5y ago
        Code in the fastpath must not generate substantial garbage whether using ARC or a gc. That's just a coding error.
        skohan 5y ago
        It's not about garbage creation, is about reference cost. With ARC, you pay a penalty every time you pass a reference type, not only for memory churn. You can avoid this using value types, but this often results in a lot of unnecessary copying. It's not unavoidable, but Swift doesn't give good tools for avoiding ARC-based performance cliffs, so it takes a lot of profiling and effort compared to other languages.
        astrange 5y ago
        It's ok to generate garbage if it goes away immediately; that's essentially a stack allocation. Performance problems come up when you have a mix of lifetimes. (that slows GCs down and causes heap fragmentation outside copying GCs)
    - pjmlp 5y ago
      Some fans do measure, and know the difference from marketing and reality in regards to tracing GC versus reference counting marketing material. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages
      - astrange 5y ago
        Wallclock time isn't the only performance metric to care about. ObjC had a GC in the past and lost it in favor of ARC for a reason; it's a poor fit for iPhone-sized devices.
        pjmlp 5y ago
        That was the marketing reason, the official reason was that fitting a GC into a language with C memory model wasn't never going to work, and there were plenty of crashes and memory corruptions coming out of that. So they made the only sensible decision, and just like Microsoft did with COM, they added support to the Objective-C compiler to automate retain/release messages in OS X Frameworks. Naturally being Apple, that pivot had to be sold in a way that the reason was being of RC being better and not because of the technical failure to have a tracing GC in Objective-C , while remaining compatible with C memory model. Apparently, moving the GC document with all its caveats regarding possible programming issues, out of search index also helps to keep the story as well. https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/GarbageCollection/Introduction.html https://developer.apple.com/library/archive/documentation/Co...
        astrange 5y ago
        No, the performance issues are real. GC programs have more page demand and higher peak memory use, which is specifically what the iOS memory model (jetsam and memory compression) can't deal with well. They can have some wins due to compacting. There is of course a GC language on iOS (JavaScript) but expensive webpages get killed quickly.
        pjmlp 5y ago
igammarays 5y ago
I can't find the interview now, but I distinctly remember someone at Apple saying that Cocoa apps benefit from hardware-level optimizations of common Objective C operations in the M1.

skohan 5y ago

But from what I understand, there's a much smaller gap between ryzen and M1 than intel

kllrnohj 5y ago

> and a unified memory architecture (less unnecessary copying on the bus). So does every other Intel & AMD laptop CPU from the last 5+ years. So does every Qualcomm SoC from the last 5+ years. This has been incredibly common for years and years now. This does a lot less than you think it does, particularly since there's very few consumer workloads that switch between CPU & GPU.

rsynnott 5y ago

> For example on the M1, certain very common operations for macOS apps, like freeing Objective C pointers, which happens millions of time per second, are optimized at the hardware level I mean, this is _kind_ of true, but it's not unique to Objective C, the M1, or even particularly intentional. The _ARM_ memory model is more conducive to reference counting in general than the x86 one. Nothing special about Apple's chip in that respect, tho.