Live data from Hacker News

Apple Silicon M1: Black Magic Fuckery

singhkays.com

271–280 of 1001 posts

Re: Apple Silicon M1: Black Magic Fuckery

#271

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…

> Stop changing the UI like you’re working at Hermès. It’s not fashion. Of course it is. Our phones are intimately close to us. Physically, cognitively, socially and even emotionally. They may be the most widely-owned intimately-connected object humans have ever invented outside religion. Our computers don't occupy as close of a niche. But they're in a similar space. I agree with your observation that the new OS feel…

> It’s not fashion.

For the most part, you are correct. Yes there are design trends, but that isn't the primary factor here. Staff designers have to justify their existence by making changes to established design patterns. They don't have to be good, just different.

Bonus points for following a public design trend, but so long as the visual diff is big enough, you get your pay check.

Re: Apple Silicon M1: Black Magic Fuckery

#272

For those of us who just don't where MacOS is concerned, what are the prospects for Linux on an M1?

Probably not very good, but the recent Ryzen offerings are still pretty strong, as is the very newest Intel stuff. See for example the 4900HS & 4800U on this Anandtech chart comparing spec2017 vs. the M1: https://images.anandtech.com/graphs/graph16252/119365.png

That's basically just sorted by power consumption. 4900HS is the most power used & fastest, followed by the ~22W M1 with all 8 cores loaded, then the 15W 4800U, and then the M1 with just the 4 bigs was last.

Re: Apple Silicon M1: Black Magic Fuckery

#273

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

I bought my MBP for personal projects, in which I don't use Docker or any other virtualization-based tooling and I could live with 16GB RAM. I expect the kinks with things like Brew to be worked out in a matter of weeks. So I think these would do fine for my purposes

Re: Apple Silicon M1: Black Magic Fuckery

#274
post #81

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 pretty trivial to disable most animations (and more importantly transparency!). I’ve been doing that on new MacOS installs since Jaguar and it only takes a few minutes. If you want to move quickly you’re probably already using keyboard shortcuts and ignoring the dock and toolbars. For less technically adept users (ie. most users) the animations and spacings mostly seem to help them understand what’s going on. I…

AFAIK the workspace switching animation can't be disabled.

Re: Apple Silicon M1: Black Magic Fuckery

#275

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

The better tinfoil hat question is how much did they intentionally sandbag the outgoing Intel models vs. how much was it a case that M1 was delayed? Such as the Intel MacBook Air whose fan wasn't even connected to anything? Was that bad design because it wasn't supposed to exist, or was that bad design intentional to help drive up the huge generation over generation gains?

Re: Apple Silicon M1: Black Magic Fuckery

#276

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…

While I won’t go that far, arguing that macOS with a Windows 95 UI is a good idea, I do agree that Big Sur’s current UI is a mess. Traditional macOS users valued the Mac user interface deeply, and IMO that was why while iOS 7 got a big refresh, macOS got a much smaller one, only with flatness refinements. Big Sur feels like the iOS 7 for the Mac, and I’m very sad that I’ll have to wait at least 4~5 years to see the n…

> The new control center and notification center’s UI is so foreign from other parts of the macOS. It’s just… so custom.

Apparently it’s all SwiftUI, which makes it look strange and animate weirdly.

Re: Apple Silicon M1: Black Magic Fuckery

#277

Earlier quoted context omitted.

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…

I didn't understand why the implementation wouldn't just do an atomic increment, but I guess Obj-C semantics provide too much magic to permit such a simple approach. The actual code, in addition to [presumably] not being inlined, does not seem easy to optimize at the hardware level: https://github.com/apple/swift-corelibs-foundation/blob/main...

The native Swift retain (swift_retain above) seems to be somewhere inside this mess: https://github.com/apple/swift/blob/main/stdlib/public/runti...

Re: Apple Silicon M1: Black Magic Fuckery

#278

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…

> Stop changing the UI like you’re working at Hermès. It’s not fashion. Of course it is. Our phones are intimately close to us. Physically, cognitively, socially and even emotionally. They may be the most widely-owned intimately-connected object humans have ever invented outside religion. Our computers don't occupy as close of a niche. But they're in a similar space. I agree with your observation that the new OS feel…

Of course it is. Our phones are intimately close to us. Physically, cognitively, socially and even emotionally. They may be the most widely-owned intimately-connected object humans have ever invented outside religion.

Artisans and their tools have been close for millennia. Every craftsman has been attached to their tools, even passed down generations, specially the good ones. But that's it. They're tools. In the end, they need to serve their purpose, or they're not.

If the OS is more masturbatory UI design exercise, and less tool experience, what's the point?

Re: Apple Silicon M1: Black Magic Fuckery

#279

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…

“A reference counting strategy would be more efficient in processor utilization compared to garbage collection as it does not need to perform processor intensive sweeps through memory identifying unreferenced objects. So reference counting trades memory for processor cycles.”

I think it’s the reverse.

Firstly, garbage collection (GC) doesn’t identify unreferenced objects, it identifies referenced objects (GC doesn’t collect garbage). That’s not just phrasing things differently, as it means that the amount of garbage isn’t a big factor in the time spent in garbage collection. That’s what makes GC (relatively) competitive, execution-time wise. However, it isn’t competitive in memory usage. There, consensus is that you need more memory for the same performance (https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf: with five times as much memory, an Appel-style generational collector with a non-copying mature space matches the performance of reachability-based explicit memory management. With only three times as much memory, the collector runs on average 17% slower than explicit memory management)

(That also explains why iPhones can do with so much less memory than phones running Android)

Secondly, the textbook implementation of reference counting (RC) in a multi-processor system is inefficient because modifying reference counts requires expensive atomic instructions.

Swift programs spend about 40% of their time modifying reference counts (http://iacoma.cs.uiuc.edu/iacoma-papers/pact18.pdf)

So, reference counting gets better memory usage at the price of more atomic operations = less speed.

That last PDF describes a technique that doubles the speed of RC operations, decreasing that overhead to about 20-25%.

It wouldn’t surprise me if these new ARM macs use a similar technique to speed up RC operations.

It might also help that the memory model of ARM is weaker than that of x64, but I’m not sure that’s much of an advantage for keeping reference counts in sync across cores.

Re: Apple Silicon M1: Black Magic Fuckery

#280
post #77

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…

It's all mostly redesign for the sake for redesign at this point. Desktop OSes had been feature-complete for quite some time, but they still have to update every year. They have to. Don't you even dare question that. I'm still on Mojave and it does everything I need from an OS. I also absolutely love native Mac apps, which are becoming rarer and rarer. And no, iOS apps that run on macOS aren't native mac apps. The ab…

> Desktop OSes had been feature-complete for quite some time

It's less that desktop OSes are feature complete, and more that vendors want recurring cloud subscription fees from users for new features these days.

Post reply on HN