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

281–290 of 1001 posts

Re: Apple Silicon M1: Black Magic Fuckery

#281

Post by socialdemocrat »

rowls66 wrote: post #254
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…

The bit about reference counting being the reason that Macs and iOS devices get better performance with less ram makes no sense. As a memory management strategy, reference counting will always use more ram because a reference count must be stored with every object in the system. Storing all of those reference counts requires memory. A reference counting strategy would be more efficient in processor utilization compar…

No, many garbage collection approaches WILL require more RAM, some need twice as much RAM to run efficiently. Then there is the case that with garbage collection can have a delay which lets garbage pile up thus using more memory than necessary. Retain-release used by Apple is not as efficient, but you reclaim memory faster. https://www.quora.com/Why-does-Garbage-Collection-take-a-lot...

Re: Apple Silicon M1: Black Magic Fuckery

#282

Post by saagarjha »

torstenvl wrote: post #161
uncomputation wrote: post #122

Earlier quoted context omitted.

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

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.

Re: Apple Silicon M1: Black Magic Fuckery

#283

Post by coopsmgoops »

iJohnDoe wrote: post #209

I’m starting to wonder if this is the reason we had some serious problems with macOS and iOS in recent months and years. Serious bugs and serious security flaws. The A-team was working on getting everything ready for M1. The B-team was working on the usual releases. If the M1 is as good as everyone says, then that means they had the best people on it.

I doubt the team designing the chips has much overlap with the OS team.

Re: Apple Silicon M1: Black Magic Fuckery

#284

Post by 3np »

crazygringo wrote: post #129
megablast wrote: post #97

Earlier quoted context omitted.

Every 8gb mac I’ve used before was fine, and that was with running Xcode, Firefox, photoshop, mail, terminal, and other programs.

Seriously, I'm utterly baffled by all the people claiming that 8 GB isn't enough for the average user. The only situation I ever ran into where it was a problem was in trying to run multiple VM's at once. Otherwise it's just a non-issue. Programs often reserve a lot more memory than they actually use (zero hit in performance) so memory stats are misleading, and the OS is really good at swapping memory not touched in…

I pretty much daily have to do a closing round to not run out of my 24GiB. That’s all web browsers (Usually 100-200 tabs), vs code with some extensions and 2x4k display.

Re: Apple Silicon M1: Black Magic Fuckery

#285

Post by IggleSniggle »

tobyjsullivan wrote: post #243
sooheon wrote: post #219

Earlier quoted context omitted.

I'm surprised they're getting rid of long held keyboard shortcut conventions though. Previously, modal popup options (i.e. for saving docs) could be selected via Option-letter, i.e. "Save _a_ll" could be selected with Option-a. Their new popups which may or may not be prettier force you to either use the mouse or turn on "Use keyboard navigation to move focus between controls" globally and tab around. Neither of thes…

In Apple's defence, I've been exclusively a mac user (work and personal) for going-on eight years now and I had no idea about the Option-letter shortcut. I've always found keyboard nav within modal popups confusing. I consider myself lucky if hitting Space selects the primary button. Doesn't sound like the change is necessarily an improvement, though.

Wow, I didn’t know about that either. And yet Windows 95 had this solved: just show the shortcut letter underlined and/or bolder.

Re: Apple Silicon M1: Black Magic Fuckery

#286

Post by cercatrova »

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…

The increased padding, spread out buttons, big icons. Do you see the pattern?

They're gonna make a touch screen Mac, whether it be in the form of a laptop, iMac, or an iPad running macOS.

Re: Apple Silicon M1: Black Magic Fuckery

#287

Post by macintux »

jandrese wrote: post #265
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.

The RAM limitation on the first gen M1s makes this claim a bit dubious.

https://www.diyphotography.net/this-700-computer-can-edit-8k...

Re: Apple Silicon M1: Black Magic Fuckery

#288

Post by Shish2k »

ultrarunner wrote: post #235
jerf wrote: post #130

Earlier quoted context omitted.

"it’s not developer ready yet." Hey, what if we just... kept it that way? Kiss all that speed goodbye once software developers get their hands on this. And then the low end current-gen models will be even slower when running "the code that runs ok on the M1 hardware, I guess, ship it."

It’s unclear to me how reduced availability of developer tooling will result in a faster software experience for M1 owners.

If developers are forced to use slow machines to develop, then they’re less likely to build bloaty slow software that depends on fast machines

Re: Apple Silicon M1: Black Magic Fuckery

#290

Post by gwking »

dathinab wrote: post #92
brundolf wrote: post #74

Earlier quoted context omitted.

The exact reason is out of my depth, but the original quote makes it clear that there is something. Memory bandwidth would be one possibility.

My guess: 1. "weak" memory ordering (atomic Aquire/Release loads/stores) 2. low memory latencies between cache and system memory (so dirty pages in caches are faster updated etc.) 3. potential a coherency impl. optimized for this kind of atomic access (purely speculative: e.g. maybe sometimes updating less then a page in a cache when detecting certain atomic operations which changed a page or maybe wrt. the window ma…

These are interesting points. I'd like to hazard a guess that the leading contributor is cache-related. Just looking at the https://en.wikipedia.org/wiki/Reference_counting suggests as much: "Not only do the operations take time, but they damage cache performance and can lead to pipeline bubbles."

I roughly understand how refcounting causes extra damage to cache coherency: anywhere that a refcount increment is required, you mutate the count on an object before you use it, and then decrement it later. Often times, those counting operations are temporally distant from the time that you access the object contents.

I do not really understand the "pipeline bubbles" part, and am curious if someone can elaborate.

Reading on in the wiki page, they talk about weak references (completely different than weak memory ordering referenced above). This reminds me that Cocoa has been making ever more liberal use of weak references over the years, and a lot of iOS code I see overuses them, particularly in blocks. I last looked at the objc implementation years ago, but it was some thread safe LLVM hash map split 8 or 16 ways to reduce lock contention. My takeaway was roughly, "wow that looks expensive". So while weak refs are supposed to be used judiciously, and might only represent 1% or less of all refs, they might each cost over 100x, and then I could imagine all of your points could be significant contributors.

In other words, weak references widen the scope of this guessing game from just "what chip changes improve refcounting" to "what chip changes improve parallelized, thread safe hash maps."

Post reply on HN