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

151–160 of 1001 posts

Re: Apple Silicon M1: Black Magic Fuckery

#151

Post by jml7c5 »

darren_ wrote: post #135
nojito wrote: post #101

Earlier quoted context omitted.

The quote right after explains your concerns. >The memory bandwidth on the new Macs is impressive. Benchmarks peg it at around 60GB/sec–about 3x faster than a 16” MBP. Since the M1 CPU only has 16GB of RAM, it can replace the entire contents of RAM 4 times every second. Think about that…

Yes, reading some more of the discussions it seems like the answer is that (roughly) the same amount of memory is used, but hitting swap is no longer a major problem, at least for user-facing apps. Seems like the original quote is reading too much into the retain/release thing.

If the same amount of memory is used, then wouldn't swap usage be the same?

Re: Apple Silicon M1: Black Magic Fuckery

#152

Post by gameswithgo »

nojito wrote: post #101
darren_ wrote: post #87

Earlier quoted context omitted.

This quote doesn’t really cover why M1 macs are more efficient with less ram than intel macs? You’ve got a memory budget, it’s likely broadly the same on both platforms, the speed at which your retains/releases happen isn’t going to be the issue. it’s not like intel macs use GC where m1 uses RC. (It explains why iOS does better with less ram than android, but the quote is specifically claiming this as a reason for 8G…

The quote right after explains your concerns. >The memory bandwidth on the new Macs is impressive. Benchmarks peg it at around 60GB/sec–about 3x faster than a 16” MBP. Since the M1 CPU only has 16GB of RAM, it can replace the entire contents of RAM 4 times every second. Think about that…

first there is no sensible reason why ram bandwidth would be different by 3x, its lpddr4x either way, and you can’t replace it from an ssd that fast, the ssd would limit swap speed

Re: Apple Silicon M1: Black Magic Fuckery

#153

Post by gameswithgo »

nottorp wrote: post #115
nojito wrote: post #101

Earlier quoted context omitted.

The quote right after explains your concerns. >The memory bandwidth on the new Macs is impressive. Benchmarks peg it at around 60GB/sec–about 3x faster than a 16” MBP. Since the M1 CPU only has 16GB of RAM, it can replace the entire contents of RAM 4 times every second. Think about that…

Sounds like some form of GDDR instead of plain DDR. Not only faster, but I bet simultaneously accessible from both the CPU and GPU.

no its normal mobile ram

Re: Apple Silicon M1: Black Magic Fuckery

#154

Post by nemothekid »

uncomputation wrote: post #122
darren_ wrote: post #87

Earlier quoted context omitted.

This quote doesn’t really cover why M1 macs are more efficient with less ram than intel macs? You’ve got a memory budget, it’s likely broadly the same on both platforms, the speed at which your retains/releases happen isn’t going to be the issue. it’s not like intel macs use GC where m1 uses RC. (It explains why iOS does better with less ram than android, but the quote is specifically claiming this as a reason for 8G…

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.

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.

Re: Apple Silicon M1: Black Magic Fuckery

#155

Post by blihp »

darren_ wrote: post #87
brundolf wrote: post #25

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 i…

This quote doesn’t really cover why M1 macs are more efficient with less ram than intel macs? You’ve got a memory budget, it’s likely broadly the same on both platforms, the speed at which your retains/releases happen isn’t going to be the issue. it’s not like intel macs use GC where m1 uses RC. (It explains why iOS does better with less ram than android, but the quote is specifically claiming this as a reason for 8G…

It's a contributing factor. If things like retain/release are fast and you have significantly more memory bandwidth and low latency to throw at the problem, you can get away without preloading and caching nearly as much. Take something simple like images on web pages: don't bother keeping hundreds (thousands?) of decompressed images in memory for all of the various open tabs. You can just decompress them on the fly as needed when a tab becomes active and then release them when it goes inactive and/or when the browser/system determines it needs to free up some memory.

Re: Apple Silicon M1: Black Magic Fuckery

#156

Post by jolux »

uncomputation wrote: post #122
darren_ wrote: post #87

Earlier quoted context omitted.

This quote doesn’t really cover why M1 macs are more efficient with less ram than intel macs? You’ve got a memory budget, it’s likely broadly the same on both platforms, the speed at which your retains/releases happen isn’t going to be the issue. it’s not like intel macs use GC where m1 uses RC. (It explains why iOS does better with less ram than android, but the quote is specifically claiming this as a reason for 8G…

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.

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

Re: Apple Silicon M1: Black Magic Fuckery

#157

Post by spurgu »

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…

Not too many people seem to be commenting on the UI but the Big Sur "improvements" were one of the main things that made me look into going back to Linux, researching how to replace my current MacOS workflow.

The UI changes are just completely nonsensical to me, and despite the initial announcements of the speed benefits of the M1 I was set on trying to go back to Linux. But now with articles like these I have to admit it feels tempting...

Re: Apple Silicon M1: Black Magic Fuckery

#158

Post by jgon »

CountSessine wrote: post #78
trevyn wrote: post #27

Earlier quoted context omitted.

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

Yikes. That's the same shenanigans that got them into trouble with the 68000. Everyone stuffed data into the top 8 bits of pointers because even though the 68000 had 32-bit addressing registers, it only had a 24-bit address bus and the top 8 bits were dontcare's. Then, the 6802x came out with more address lines and... ...and that's basically why x86_64 was specified to require a particular bit pattern in high-order b…

Doesn't this become less and less of an issue the more bits you add to your pointers? Like with 32 bits, you can't have one memory address per person on the planet earth, at 64 bits, you can have 1 pointer per atom that makes up the planet earth, and at 128 bits we're talking 1 address per atom in the known universe (or something like that, I haven't crunched the numbers exactly, this is more to give a flavor for the order of magnitude we're talking).

So if you cut off the top 8 bytes of a 32bit register and leave yourself with 24 bits, you can't even give a pointer to each person in Tokyo, but you cut off the top 8 bits of a 64 bit pointer you can still give a pointer to each atom of every human being on earth?

Re: Apple Silicon M1: Black Magic Fuckery

#159

Post by jolux »

nottorp wrote: post #119
meragrin_ wrote: post #75

Earlier quoted context omitted.

I doubt Apple allows anyone with the knowledge to speak about it.

This is where it's worth pointing out that Apple is an ARM architecture licensee. They're not using a design from ARM directly, they're basically modifying it however it suits them.

Indeed, they’re an ISA licensee, and I don’t think they’re using designs from ARM at all. They beat ARM to the first ARM64 core back in 2013 with the iPhone 5s.

Re: Apple Silicon M1: Black Magic Fuckery

#160

Post by person_of_color »

victor106 wrote: post #109

> A task like editing 8K RAW RED video file that might have taken a $5000 machine before can now be done on a $699 Mac Mini M1 or a fan-less MacBook Air that costs $999 That’s insanely great. Maybe I am exaggerating but Apple’s M1 might be the best innovation in the tech industry in the past 5 years.

Even more than k8s?
Post reply on HN