Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple Silicon M1: Black Magic Fuckery

singhkays.com

Post reply on HN
Print view View original

21–30 of 1001 posts

Re: Apple Silicon M1: Black Magic Fuckery

#21

Post by saagarjha »

goatinaboat wrote: post #19
neilpanchal wrote: post #4

I just got one. I’m blown away by the speed as well. Chrome runs insanely fast! Alas, it’s not developer ready yet. Brew is a mess. Docker doesn’t work. PyCharm is WIP although can use x86 version. I was skeptical of the hype but this little laptop has made me realize how slow everything else is. Unfortunately, while the hardware has accelerated far beyond expectations, the software - specifically MacOS BigSur is a m…

It’s not fashion. Unfortunately you are wrong. Everything we call tech is in fact driven by fashion. My older version Mac is badgering me to upgrade to Bug Sur. Top feature: 100 new emojis. That is what Apple prioritised. Why the hell are emojis even part of the OS let alone its top feature! Truth is GUIs are done, were a decade or more ago. All there is left now is change for the sake of change. And Apple can’t thin…

https://www.apple.com/macos/big-sur/ says it's the new design.

Re: Apple Silicon M1: Black Magic Fuckery

#23

Post by saagarjha »

berkut wrote: post #20
saagarjha wrote: post #17

Earlier quoted context omitted.

I believe it was being brought up as an example of "Apple has designed their hardware around their software" and then that translates to "Apple's software does well on machines with less memory".

Compared to something like Android, sure, I get that, but compared to ObjectiveC/Swift on x86 (which I think was being argued - i.e. against the Intel Macs)? I guess it makes reference counting in general more efficient, I'm just saying I don't see why that would mean Apple Silicon Macs running ObjectC/Swift code would have less memory usage than the same code compiled and running on x86.

I'm not necessarily convinced by the posted argument. That being said, I tend to think that people running a bunch of VMs and Electron apps and Docker cause them to use a bunch more RAM than I would consider to be "reasonable", and they've lost sight of how much you can do in a lesser amount of memory. (Typing this from a computer with 8 GB of RAM, which I have repeatedly been told is "below adequate" for development.)

Re: Apple Silicon M1: Black Magic Fuckery

#25

Post by brundolf »

This is fascinating:

> Retain and release are tiny actions that almost all software, on all Apple platforms, does all the time. ….. The Apple Silicon system architecture is designed to make these operations as fast as possible. It’s not so much that Intel’s x86 architecture is a bad fit for Apple’s software frameworks, as that Apple Silicon is designed to be a bespoke fit for it …. retaining and releasing NSObjects is so common on MacOS (and iOS), that making it 5 times faster on Apple Silicon than on Intel has profound implications on everything from performance to battery life.

> Broadly speaking, this is a significant reason why M1 Macs are more efficient with less RAM than Intel Macs. This, in a nutshell, helps explain why iPhones run rings around even flagship Android phones, even though iPhones have significantly less RAM. iOS software uses reference counting for memory management, running on silicon optimized to make reference counting as efficient as possible; Android software uses garbage collection for memory management, a technique that requires more RAM to achieve equivalent performance.

Re: Apple Silicon M1: Black Magic Fuckery

#26

Post by ianhowson »

berkut wrote: post #15

I don't quite understand how 'retain' and 'release' can be more memory efficient on Apple Silicon than x86.... I can understand how they can be more efficient from a performance standpoint in terms of more efficient reference counting, but I don't understand how that translates to less memory usage which is apparently what's being argued... ? Unless on x86 some of the 'free's when the ref counts hit 0 were being batc…

I don't think retain/release perf has anything to do with memory consumption, but I have seen a bunch of reviews claiming that 8GB is perfectly fine.

This is fascinating to me, because:

(a) every 8GB Mac I've used in the past has been unusably slow

(b) since upgrading my 32GB Hackintosh to Big Sur, my usual 40GB working set is only about 20GB.

(c) My 2015 16GB MBPr with Big Sur is also using about half as much physical memory on the same workload. Swappiness is up a little, but I haven't noticed.

So my guess is that something in Big Sur has dramatically reduced memory consumption and that fix is being commingled with the M1 announce.

Re: Apple Silicon M1: Black Magic Fuckery

#27

Post by trevyn »

berkut wrote: post #15

I don't quite understand how 'retain' and 'release' can be more memory efficient on Apple Silicon than x86.... I can understand how they can be more efficient from a performance standpoint in terms of more efficient reference counting, but I don't understand how that translates to less memory usage which is apparently what's being argued... ? Unless on x86 some of the 'free's when the ref counts hit 0 were being batc…

They stuff the reference count in the unused bits of the 64-bit pointers.

Re: Apple Silicon M1: Black Magic Fuckery

#28

Post by azangru »

jrm4 wrote: post #6

At the risk of being that (Linux) guy -- What is gained here if we're just still applying faster cycles to Apple-esque wasteful (and perhaps harmful, as we're apparently learning re: their telemetry) software? If people really dig their Apple stuff, great. But I think its worth thinking about the likelihood that a "slower" computer running Linux could probably serve the actual user better in terms of "getting stuff d…

Another linux guy here, on the market for a new linux laptop.

After reading the article, which linux-compatible laptops, would you say, come the closest to compete with the new generation of Apple products? Long battery life, plenty of power, good screen, good speakers? Is it the inevitable Dell XPS 13 and Thinkpad X1 Carbon, or are there any other darlings among the linux community?

Re: Apple Silicon M1: Black Magic Fuckery

#29

Post by Areading314 »

vmception wrote: post #18

weren't the old exploits on the intel processors patched by essentially making many operations slower? like they had to disable some cpu instructions which were previously innovative and this debilitated the irreparable processors. so a new architecture with better versions of the same instructions would feel very fast, since we went two steps back first.

Yes, these were due to the Spectre and Meltdown vulnerabilities

Re: Apple Silicon M1: Black Magic Fuckery

#30

Post by jdminhbg »

ianhowson wrote: post #26
berkut wrote: post #15

I don't quite understand how 'retain' and 'release' can be more memory efficient on Apple Silicon than x86.... I can understand how they can be more efficient from a performance standpoint in terms of more efficient reference counting, but I don't understand how that translates to less memory usage which is apparently what's being argued... ? Unless on x86 some of the 'free's when the ref counts hit 0 were being batc…

I don't think retain/release perf has anything to do with memory consumption, but I have seen a bunch of reviews claiming that 8GB is perfectly fine. This is fascinating to me, because: (a) every 8GB Mac I've used in the past has been unusably slow (b) since upgrading my 32GB Hackintosh to Big Sur, my usual 40GB working set is only about 20GB. (c) My 2015 16GB MBPr with Big Sur is also using about half as much physic…

iPhones and iPads also have relatively small amounts of RAM compared to Android devices in the same class, so I wonder if Apple is doing something smart with offloading memory to fast SSD storage in a way that isn't noticeable to the user.
Post reply on HN