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

71–80 of 1001 posts

Re: Apple Silicon M1: Black Magic Fuckery

#71

Post by whynotminot »

Teknoman117 wrote: post #45

Tin foil hat warning - but how much of the M1 performance improvement is from optimizations made in Big Sur for Apple Silicon that they just didn't bother implementing for x86 since it's now the outgoing technology for Apple? I realize the reducing in power consumed for any given quantity of work is downright amazing for laptops, but I guess I'm more curious about workstation and (build) server kinds of applications.…

Apple has been using x86 for practically 15 years now. Your theory is this whole time they've been too lazy to bother to implement "god mode" ?

What about Windows and Linux on x86? Also too lazy?

It can be fun to put on the tin foil hat, but at least make sure the theory makes even a little bit of sense first.

Re: Apple Silicon M1: Black Magic Fuckery

#72

Post by lilyball »

brundolf wrote: post #54
lisper wrote: post #44

Earlier quoted context omitted.

Remember Lisp machines? The M1 is a Swift machine.

I'm wondering if the "optimized for reference-counting" thing applies to other languages too. i.e. if I write a piece of software in Rust, and I make use of Rc , will Macs be extra tolerant of that overhead? In theory it seems like the answer should be yes

I sure hope so. In macOS 10.15, the fast path for a retain on a (non-tagged-pointer) Obj-C object does a C11 relaxed atomic load followed by a C11 relaxed compare-and-exchange. This seems pretty standard for retain-release and I'd expect Rust's Rc to be doing something similar. It's possible Apple added some other black magic to the runtime in 10.16 (and they haven't released the 10.16 objc sources yet) but it's hard to imagine what they'd do that makes more sense than just optimizing for relaxed atomic operations.

Re: Apple Silicon M1: Black Magic Fuckery

#73

Post by wayneftw »

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…

I don't get the anti-Linux comments here. I use Manjaro with XFCE as my daily driver and I haven't had to tinker with shit on it since I set it up. Has nobody tried this distro?

Everything I need to do on it runs like a dream. Installing software is easier than anything, especially since I just use the GUI for that. I've had more trouble with Mac and Windows.

Even other Linux distros that I've tried don't really stand up to Manjaro. Ubuntu and other Debian derivatives have you hunting down PPAs and using the terminal to add things - maybe that's the "tinkering" that annoys people? If so, I wholly recommend you try Manjaro or another Arch based distro.

Re: Apple Silicon M1: Black Magic Fuckery

#74

Post by brundolf »

klelatti wrote: post #70
brundolf wrote: post #67

Earlier quoted context omitted.

The M1 is much more than a CPU, and a CPU is much more than an instruction set

I know it's a fast Arm CPU - I've read the Anandtech analysis etc - and that there is lots of extra hardware on the SoC. But the specific point was why is it a Swift machine. What makes it particularly suited to running Swift?

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.

Re: Apple Silicon M1: Black Magic Fuckery

#75

Post by meragrin_ »

klelatti wrote: post #66
lisper wrote: post #44

Earlier quoted context omitted.

Remember Lisp machines? The M1 is a Swift machine.

But how? It has an Arm CPU - how does it differ from any other machine with a 64 bit Arm CPU?

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

Re: Apple Silicon M1: Black Magic Fuckery

#76

Post by Karupan »

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…

> running on silicon optimized to make reference counting as efficient as possible

I'm curious to understand this. Is this because of a specific instruction set support, or just the overall unified memory architecture?

Re: Apple Silicon M1: Black Magic Fuckery

#77

Post by nbzso »

Those of us who are long enough in UI design know what is a result of attention to detail and professional GUI. We have all used Os X not only for UNIX like core (Darwin) but for consistent UX and UI libraries. In some point in time Apple was influencing our work in really meaningful way by setting the standard (remember Apple Human Interface Guidelines pre Yosemite). For me personally Soundtrack Pro is most polished professional interface ever made. So in this context UI “innovation” trough emoji and implementation of white space for touch interaction (without touch interaction) is funny but not usable. Performance aside ( which is big accomplishment ) I miss the old approach with balance of contrast and natural flow and will stay on Catalina as long as I can. If Apple changes their stance on telemetry, bypassing things and fixes UI/UX design I have no problem to join again. What is lacking in Linux desktop is consistent approach to UI, but for some of us may be is time to revaluate and relearn things. My personal time investment is in Emacs, with time I have more and more respect for those ideas of freedom and consistency. The selling point for me with Apple was professional interface and high UI standards, sadly they are gone. But hey everyone of us is different and this is good, right?

Re: Apple Silicon M1: Black Magic Fuckery

#78

Post by CountSessine »

trevyn wrote: post #27
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.

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 bits - it was to stop applications and OS programmers from writing a bunch of software with tagged pointers which would tie Intel's and AMD's hands when adding address lines. I guess Apple is ok with tying their own hands.

Re: Apple Silicon M1: Black Magic Fuckery

#79

Post by whynotminot »

brundolf wrote: post #13

> cries in 2020 MBP We may need to start a support group

Heh, I'm in the 2020 MBP group. But I still think these M1 Macs--as awesome as they undoubtedly are--are not quite yet ready for developers. Virtualization support still looks iffy, and while I really don't care much whether my container is Arm or x86, the ecosystems and tooling around those architectures are still at different levels of maturity.

The exciting (or depressing, for the 2020 crew) thing is that the fact that these M1 Macs are such a triumph probably does mean that these various rough edges will be smoothed out way faster than even I, a self admitted Apple fan, expected them to be.

I was thinking I'd be waiting until 2022 or 2023 before being ready as a developer to have my primary device be an Apple Silicon laptop. But with the overwhelming success of these chips, every developer wants to be on these things ASAP. I could easily see the ecosystem for Arm being radically improved over the next year.

Re: Apple Silicon M1: Black Magic Fuckery

#80

Post by ubercow13 »

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…

How does this work? Isn't reference counting a lot of +1 and -1?
Post reply on HN