3 ms·

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 (wr

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.
      - ianai 6y ago
        Even those still do memory management-and usually poorly.
  - AnonC 6y ago
    In one of those random “benchmark tests” online where someone opened several applications on an M1 Mac with 8GB RAM and did some work on those, they kept Activity Monitor open alongside and pointed to the increase in swap at some stage. So it seems like the swap is fast enough and is used more aggressively. That reduces the amount of RAM used at any point in time. The data in RAM has also benefited from compression in macOS for several years now.
lern_too_spel 6y ago
For a very long time, budget Android devices that were one or even two generations older were faster than just released iPhones at launching new apps to interactivity (see: hundreds of Youtube "speed comparison" videos). This was purely due to better software, as the iPhone had significantly faster processors and I/O. RAM doesn't play a big factor at launch. One very minor contributor would be that the GC doesn't need to kick in until later, while ARC is adding its overhead all the time. Edit: apparently, this isn't common knowledge. https://www.youtube.com/watch?v=emPiTZHdP88 https://www.youtube.com/watch?v=emPiTZHdP88 https://youtu.be/hPhkPXVxISY https://youtu.be/hPhkPXVxISY https://youtu.be/B5ZT9z9Bt4M https://youtu.be/B5ZT9z9Bt4M
- thu2111 6y ago
  Ridiculous that you're downvoted. There are a lot of people posting here who haven't worked on memory management subsystems. GC vs RC is not a trivial comparison to make, but overall there are good reasons new systems hardly use RC (Objective-C dating back to the 90s isn't new). Where RC can help is where you have a massive performance cliff on page access, i.e. if you're swapped to disk. Then GC is terrible because it'll try and page huge sections of the heap at once where as RC is way more minimal in what it touches. But in most other scenarios GC will win a straight up fight with an RC based system, especially when multi-threading gets involved. RC programs just spend huge amounts of time atomically incrementing and decrementing things, and rummaging through the heap structures, whereas the GC app is flying along in the L1 cache and allocations are just incrementing a pointer in a register. The work of cleaning up is meanwhile punted to those spare cores you probably aren't using anyway (on desktop/mobile). It's tough to beat that by hand with RC, again, unless you start hitting swap. If M1 is faster at memory ops than x86 it's because they massively increased memory bandwidth. In fact I'd go as far as saying the CPU design is probably not responsible for most of the performance increase users are seeing. Memory bandwidth is the bottleneck for a lot of desktop tasks. If M1 core is say 10% faster than x86 but you have more of them and memory bandwidth is really 3x-4x larger, and the core can keep far more memory ops in flight simultaneously, that'll explain the difference all by itself.
  - lern_too_spel 6y ago
sgerenser 6y ago
The only thing I can think of that would actually reduce memory usage on M1 vs the same version of MacOS on x86 would be if they were able to tune their compressed memory feature to run faster (with higher compression ratio) on the M1. That would serve to reduce effective memory usage or need to fall back to swap. I would not expect something like that to be responsible for more than, say, a 5-10% RAM usage decrease though.
- danieldk 6y ago
  That would serve to reduce effective memory usage or need to fall back to swap. I would not expect something like that to be responsible for more than, say, a 5-10% RAM usage decrease though. I think you can reach a lot more than that. Presumably, on Intel they use something like LZO or LZ4, since it compresses/decompresses without too much CPU overhead. But if you have dedicated hardware for something like e.g. Brotli or zstd, one could reach much higher compression ratios. Of course, this is assuming that memory can be compressed well, but I think this is true in many cases. E.g. when selecting one of the program/library files in the squash benchmarks: https://quixdb.github.io/squash-benchmark/ https://quixdb.github.io/squash-benchmark/ you can observe higher compression ratios for e.g. Brotli/gzip/deflate than LZO/LZ4.
  - sgerenser 6y ago
    I suspect Apple is using their own LZFSE[0] compression, perhaps now with special tweaks for M1. The reason I only suspected a 5-10% increase though is even if it’s able to achieve a massive increase in compression ratio (compressing 3GB to 1GB instead of 2GB, say), that’s still only saving 1GB total. Which I guess isn’t nothing and is more than 10% on an 8GB machine. [0] https://en.m.wikipedia.org/wiki/LZFSE https://en.m.wikipedia.org/wiki/LZFSE
donarb 6y ago
ARC stands for Automatic Reference Counting. https://en.wikipedia.org/wiki/Automatic_Reference_Counting https://en.wikipedia.org/wiki/Automatic_Reference_Counting

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.
    - ianai 6y ago
      Even those still do memory management-and usually poorly.
- AnonC 6y ago
  In one of those random “benchmark tests” online where someone opened several applications on an M1 Mac with 8GB RAM and did some work on those, they kept Activity Monitor open alongside and pointed to the increase in swap at some stage. So it seems like the swap is fast enough and is used more aggressively. That reduces the amount of RAM used at any point in time. The data in RAM has also benefited from compression in macOS for several years now.

lern_too_spel 6y ago

For a very long time, budget Android devices that were one or even two generations older were faster than just released iPhones at launching new apps to interactivity (see: hundreds of Youtube "speed comparison" videos). This was purely due to better software, as the iPhone had significantly faster processors and I/O. RAM doesn't play a big factor at launch. One very minor contributor would be that the GC doesn't need to kick in until later, while ARC is adding its overhead all the time. Edit: apparently, this isn't common knowledge. https://www.youtube.com/watch?v=emPiTZHdP88 https://www.youtube.com/watch?v=emPiTZHdP88 https://youtu.be/hPhkPXVxISY https://youtu.be/hPhkPXVxISY https://youtu.be/B5ZT9z9Bt4M https://youtu.be/B5ZT9z9Bt4M

thu2111 6y ago
Ridiculous that you're downvoted. There are a lot of people posting here who haven't worked on memory management subsystems. GC vs RC is not a trivial comparison to make, but overall there are good reasons new systems hardly use RC (Objective-C dating back to the 90s isn't new). Where RC can help is where you have a massive performance cliff on page access, i.e. if you're swapped to disk. Then GC is terrible because it'll try and page huge sections of the heap at once where as RC is way more minimal in what it touches. But in most other scenarios GC will win a straight up fight with an RC based system, especially when multi-threading gets involved. RC programs just spend huge amounts of time atomically incrementing and decrementing things, and rummaging through the heap structures, whereas the GC app is flying along in the L1 cache and allocations are just incrementing a pointer in a register. The work of cleaning up is meanwhile punted to those spare cores you probably aren't using anyway (on desktop/mobile). It's tough to beat that by hand with RC, again, unless you start hitting swap. If M1 is faster at memory ops than x86 it's because they massively increased memory bandwidth. In fact I'd go as far as saying the CPU design is probably not responsible for most of the performance increase users are seeing. Memory bandwidth is the bottleneck for a lot of desktop tasks. If M1 core is say 10% faster than x86 but you have more of them and memory bandwidth is really 3x-4x larger, and the core can keep far more memory ops in flight simultaneously, that'll explain the difference all by itself.
- lern_too_spel 6y ago

sgerenser 6y ago

The only thing I can think of that would actually reduce memory usage on M1 vs the same version of MacOS on x86 would be if they were able to tune their compressed memory feature to run faster (with higher compression ratio) on the M1. That would serve to reduce effective memory usage or need to fall back to swap. I would not expect something like that to be responsible for more than, say, a 5-10% RAM usage decrease though.

danieldk 6y ago
That would serve to reduce effective memory usage or need to fall back to swap. I would not expect something like that to be responsible for more than, say, a 5-10% RAM usage decrease though. I think you can reach a lot more than that. Presumably, on Intel they use something like LZO or LZ4, since it compresses/decompresses without too much CPU overhead. But if you have dedicated hardware for something like e.g. Brotli or zstd, one could reach much higher compression ratios. Of course, this is assuming that memory can be compressed well, but I think this is true in many cases. E.g. when selecting one of the program/library files in the squash benchmarks: https://quixdb.github.io/squash-benchmark/ https://quixdb.github.io/squash-benchmark/ you can observe higher compression ratios for e.g. Brotli/gzip/deflate than LZO/LZ4.
- sgerenser 6y ago
  I suspect Apple is using their own LZFSE[0] compression, perhaps now with special tweaks for M1. The reason I only suspected a 5-10% increase though is even if it’s able to achieve a massive increase in compression ratio (compressing 3GB to 1GB instead of 2GB, say), that’s still only saving 1GB total. Which I guess isn’t nothing and is more than 10% on an 8GB machine. [0] https://en.m.wikipedia.org/wiki/LZFSE https://en.m.wikipedia.org/wiki/LZFSE

donarb 6y ago

ARC stands for Automatic Reference Counting. https://en.wikipedia.org/wiki/Automatic_Reference_Counting https://en.wikipedia.org/wiki/Automatic_Reference_Counting