6 ms·

Someone please correct me for the sake of all of us if I’m wrong, but it sounds like Apple is using specialized hardware for “NSObject” retain-and-release opera

Someone please correct me for the sake of all of us if I’m wrong, but it sounds like Apple is using specialized hardware for “NSObject” retain-and-release operations, which may bypass/reduce the impact on general RAM.

gameswithgo 6y ago
it makes objective c and swift memory management faster but it doesn’t reduce ram usage at all. (maybe a weee bit less bandwidth used)
- rimliu 6y ago
  If memory is released as soon as possible instead of waiting for the next GC cycle, does not it make it more efficient?
  - masklinn 6y ago
    There is no “next GC cycle”, objc and swift use ref counting on every platform (there was an abortive GC attempt on desktops a few years back but it never saw wide use and has been deprecated since mountain lion).
  - tokamak-teapot 6y ago
    Yes! Hopefully I can clear up the discussion a little: Q: Does reference counting 'use' less RAM than GC? A: Yes (caveats etc. go here, but your question is a good explanation) Q: Does the M1 in and of itself require less RAM than x86 processors? A: No Q: So why are people talking about the M1 and its RAM usage as if it's better than with x86? A: It's really just around the faster reference counting. MacOS was already pretty efficient with RAM. I'd like to propose tokamak-teapot's formula for hardware purchase: Minimum RAM believed to be required = actual amount of RAM required * 2 N.B. I am aware that a sum that's greater than 16GB doesn't magically become less than 16GB, but it is somewhat surprising how well MacOS performs when it feels like RAM should be tight, so I'd suggest borrowing a Mac or making a Hackintosh to experience this if you're anxious about hitting the ceiling.
  - gameswithgo 6y ago
    these are not gc apps, they are reference counted.
nemothekid 6y ago
I saw that point brought up on Twitter and I don't know how it it makes more efficient use of RAM. Specifically, as I understood it is that Apple software (written in objective C/Swift) uses a lot of retain/release (or Atomic Reference Counting) on top of manual memory, for memory management rather than other forms of garbage collection (such as those found in Java/C#), which gives Objective C programs a lower memory overhead (supposedly). This is why the iPhone ecosystem is able to run so much more snappier than the Android ecosystem. That said, I don't see how that translates to lower memory usage than x86 programs. I think the supporting quotes he used for that point are completely orthogonal. I don't have an M1 mac, but I believe the same program running on both machines should use the same amount of memory.
- ianai 6y ago
  Tfa says the hardware optimization for ARC is to the point of being bespoken. Hardware will always beat software optimization. Further, the other GCs have much higher ram overheads than this combined, bespoke system. Apple has decades of proven experience producing and shipping massively over engineered systems. I believe em when they say these processors do ARC natively.
  - nemothekid 6y ago
    I’m not denying that Apple has better ARC performance. It’s that I don’t understand how an application would use less memory on ARM than x86. I’d expect the ARM code to run faster (as a result of being able to do atomic operations faster), but I don’t see how that translates to less memory usage
    - ianai 6y ago
      Read up on the performance overhead of GC across other languages. They’re messy and can lock up periodically. They take up significant ram and resources.
      - wmf 6y ago
        We're talking about non-GC apps on x86 vs. the same non-GC apps on Arm.
jolux 6y ago
Their hardware is almost certainly specialized for reference counting, but I would be surprised if they had a custom instruction or anything.
torstenvl 6y ago
I don't think that's quite right. Apple believes strongly in retain-and-release / ARC. It has designed its software that way; it has designed its M1 memory architecture that way. The harmony between those design considerations leads to efficiency: the software does things in the best way possible, given the memory architecture. I'm not an EE expert and I haven't torn apart an M1, but Occams's Razor would suggest it's unlikely they made specialized hardware for NSObjects specifically. Other ARC systems on the same hardware would likely see similar benefits.
- saagarjha 6y ago
  The hardware makes uncontended atomics very fast, and Objective-C is a heavy user of those. But it would really help any application that could use them, too.
  - thu2111 6y ago
    But GCd languages don't need to hit atomic ops constantly in the way ref-counted Objective C does, so making them faster (though still not as fast as regular non-atomic ops) is only reducing the perf bleeding from the decision to use RC in the first place. Indeed GC is generally your best choice for anything where performance matters a lot and RAM isn't super tight, like on servers. Kotlin/Native lets us do this comparison somewhat directly. The current and initial versions used reference counting for memory management. K/N binaries were far, far slower than the equivalent Kotlin programs running on the JVM and the developer had to deal with the hassle of RC (e.g. manually breaking cycles). They're now switching to GC. The notion that GC is less memory efficient than RC is also a canard. In both schemes your objects have a mark word of overhead. What does happen though, is GC lets you delay the work to deallocate from memory until you really need it. A lot of people find this quite confusing. They run an app on a machine with plenty of free RAM, and observe that it uses way more memory than it "should" be using. So they assume the language or runtime is really inefficient, when in reality what's happened is that the runtime either didn't collect at all, or it collected but didn't bother giving the RAM back to the OS on the assumption it's going to need it again soon and hey, the OS doesn't seem to be under memory pressure. These days on the JVM you can fix that by using the latest versions. The runtime will collect and release when the app is idle.
wmf 6y ago
It's ARMv8.x atomic instructions.
xenadu02 6y ago
On recent Apple Silicon CPUs uncontended most atomic operations are essentially free - almost identical in speed to the non-atomic version of the same operation. Reference counting must be atomic safe whether using ARC or MRR. On x86 systems those atomic operations impose a performance cost. On Apple Silicon they do not. It does not change how much memory is used but it does mean you can stop worrying about the cost of atomic operations. It has nothing to do with the ARMv8 instruction set, it has to do with how the underlying hardware implements those operations and coordinates among cores. Separately from that x86's TSO-ish memory model also imposes a performance cost whether your algorithm needs those guarantees or not. Code sometimes relies on those guarantees without knowing it. Absent hardware support you would need to insert ARM atomics in translated code to preserve those guarantees which on most ARM CPUs would impose a lot of overhead. The M1 allows Rosetta to put the CPU into a memory ordering mode that preserves the expected memory model very efficiently (as well as using 4K page size for translated processes).
- kllrnohj 6y ago
  > On recent Apple Silicon CPUs uncontended most atomic operations are essentially free - almost identical in speed to the non-atomic version of the same operation. They are fast for atomics but still far, far slower than the equivalent non-atomic operation. An add operation takes around half a cycle (upper bound here - with how wide the firestorm core is an add operation is almost certainly less than half a cycle). At 1ghz a cycle is 1 nanosecond. The M1 runs at around 3ghz. So you're still talking the atomic operation being >10x slower than non-atomics. Which should not be surprising at all. Apple didn't somehow invent literal magic here. They still need coherency across 8 cores, which means at a minimum L1 is bypassed for the atomic operation. The L2 latency is very impressive, contributing substantially to that atomic operation performance. But it's still coming at a very significant cost. It's very, very far from free. There's also no ARM vs. x86 difference here, since the atomic necessarily forces a specific memory ordering guarantee that's stricter than x86's default. Both ISAs are forced to do the same thing and pay the same costs.
  - saagarjha 6y ago
    > So you're still talking the atomic operation being >10x slower than non-atomics. How did you arrive at this number?

gameswithgo 6y ago

it makes objective c and swift memory management faster but it doesn’t reduce ram usage at all. (maybe a weee bit less bandwidth used)

rimliu 6y ago
If memory is released as soon as possible instead of waiting for the next GC cycle, does not it make it more efficient?
- masklinn 6y ago
  There is no “next GC cycle”, objc and swift use ref counting on every platform (there was an abortive GC attempt on desktops a few years back but it never saw wide use and has been deprecated since mountain lion).
- tokamak-teapot 6y ago
  Yes! Hopefully I can clear up the discussion a little: Q: Does reference counting 'use' less RAM than GC? A: Yes (caveats etc. go here, but your question is a good explanation) Q: Does the M1 in and of itself require less RAM than x86 processors? A: No Q: So why are people talking about the M1 and its RAM usage as if it's better than with x86? A: It's really just around the faster reference counting. MacOS was already pretty efficient with RAM. I'd like to propose tokamak-teapot's formula for hardware purchase: Minimum RAM believed to be required = actual amount of RAM required * 2 N.B. I am aware that a sum that's greater than 16GB doesn't magically become less than 16GB, but it is somewhat surprising how well MacOS performs when it feels like RAM should be tight, so I'd suggest borrowing a Mac or making a Hackintosh to experience this if you're anxious about hitting the ceiling.
- gameswithgo 6y ago
  these are not gc apps, they are reference counted.

nemothekid 6y ago

I saw that point brought up on Twitter and I don't know how it it makes more efficient use of RAM. Specifically, as I understood it is that Apple software (written in objective C/Swift) uses a lot of retain/release (or Atomic Reference Counting) on top of manual memory, for memory management rather than other forms of garbage collection (such as those found in Java/C#), which gives Objective C programs a lower memory overhead (supposedly). This is why the iPhone ecosystem is able to run so much more snappier than the Android ecosystem. That said, I don't see how that translates to lower memory usage than x86 programs. I think the supporting quotes he used for that point are completely orthogonal. I don't have an M1 mac, but I believe the same program running on both machines should use the same amount of memory.

ianai 6y ago
Tfa says the hardware optimization for ARC is to the point of being bespoken. Hardware will always beat software optimization. Further, the other GCs have much higher ram overheads than this combined, bespoke system. Apple has decades of proven experience producing and shipping massively over engineered systems. I believe em when they say these processors do ARC natively.
- nemothekid 6y ago
  I’m not denying that Apple has better ARC performance. It’s that I don’t understand how an application would use less memory on ARM than x86. I’d expect the ARM code to run faster (as a result of being able to do atomic operations faster), but I don’t see how that translates to less memory usage
  - ianai 6y ago
    Read up on the performance overhead of GC across other languages. They’re messy and can lock up periodically. They take up significant ram and resources.
    - wmf 6y ago
      We're talking about non-GC apps on x86 vs. the same non-GC apps on Arm.

jolux 6y ago

Their hardware is almost certainly specialized for reference counting, but I would be surprised if they had a custom instruction or anything.

torstenvl 6y ago

I don't think that's quite right. Apple believes strongly in retain-and-release / ARC. It has designed its software that way; it has designed its M1 memory architecture that way. The harmony between those design considerations leads to efficiency: the software does things in the best way possible, given the memory architecture. I'm not an EE expert and I haven't torn apart an M1, but Occams's Razor would suggest it's unlikely they made specialized hardware for NSObjects specifically. Other ARC systems on the same hardware would likely see similar benefits.

saagarjha 6y ago
The hardware makes uncontended atomics very fast, and Objective-C is a heavy user of those. But it would really help any application that could use them, too.
- thu2111 6y ago
  But GCd languages don't need to hit atomic ops constantly in the way ref-counted Objective C does, so making them faster (though still not as fast as regular non-atomic ops) is only reducing the perf bleeding from the decision to use RC in the first place. Indeed GC is generally your best choice for anything where performance matters a lot and RAM isn't super tight, like on servers. Kotlin/Native lets us do this comparison somewhat directly. The current and initial versions used reference counting for memory management. K/N binaries were far, far slower than the equivalent Kotlin programs running on the JVM and the developer had to deal with the hassle of RC (e.g. manually breaking cycles). They're now switching to GC. The notion that GC is less memory efficient than RC is also a canard. In both schemes your objects have a mark word of overhead. What does happen though, is GC lets you delay the work to deallocate from memory until you really need it. A lot of people find this quite confusing. They run an app on a machine with plenty of free RAM, and observe that it uses way more memory than it "should" be using. So they assume the language or runtime is really inefficient, when in reality what's happened is that the runtime either didn't collect at all, or it collected but didn't bother giving the RAM back to the OS on the assumption it's going to need it again soon and hey, the OS doesn't seem to be under memory pressure. These days on the JVM you can fix that by using the latest versions. The runtime will collect and release when the app is idle.

wmf 6y ago

It's ARMv8.x atomic instructions.

xenadu02 6y ago

On recent Apple Silicon CPUs uncontended most atomic operations are essentially free - almost identical in speed to the non-atomic version of the same operation. Reference counting must be atomic safe whether using ARC or MRR. On x86 systems those atomic operations impose a performance cost. On Apple Silicon they do not. It does not change how much memory is used but it does mean you can stop worrying about the cost of atomic operations. It has nothing to do with the ARMv8 instruction set, it has to do with how the underlying hardware implements those operations and coordinates among cores. Separately from that x86's TSO-ish memory model also imposes a performance cost whether your algorithm needs those guarantees or not. Code sometimes relies on those guarantees without knowing it. Absent hardware support you would need to insert ARM atomics in translated code to preserve those guarantees which on most ARM CPUs would impose a lot of overhead. The M1 allows Rosetta to put the CPU into a memory ordering mode that preserves the expected memory model very efficiently (as well as using 4K page size for translated processes).

kllrnohj 6y ago
> On recent Apple Silicon CPUs uncontended most atomic operations are essentially free - almost identical in speed to the non-atomic version of the same operation. They are fast for atomics but still far, far slower than the equivalent non-atomic operation. An add operation takes around half a cycle (upper bound here - with how wide the firestorm core is an add operation is almost certainly less than half a cycle). At 1ghz a cycle is 1 nanosecond. The M1 runs at around 3ghz. So you're still talking the atomic operation being >10x slower than non-atomics. Which should not be surprising at all. Apple didn't somehow invent literal magic here. They still need coherency across 8 cores, which means at a minimum L1 is bypassed for the atomic operation. The L2 latency is very impressive, contributing substantially to that atomic operation performance. But it's still coming at a very significant cost. It's very, very far from free. There's also no ARM vs. x86 difference here, since the atomic necessarily forces a specific memory ordering guarantee that's stricter than x86's default. Both ISAs are forced to do the same thing and pay the same costs.
- saagarjha 6y ago
  > So you're still talking the atomic operation being >10x slower than non-atomics. How did you arrive at this number?