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

291–300 of 1001 posts

Re: Apple Silicon M1: Black Magic Fuckery

#291

Post by socialdemocrat »

jml7c5 wrote: post #163
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…

I think the author doesn't understand what Gruber wrote here. Android uses more memory because most Android software is written to use more memory (relying on garbage collection). It has nothing to do with the chips. If you ran Android on an M1, it wouldn't magically need less RAM. And Photoshop compiled for x86 is going to use about the same amount of memory as Photoshop compiled for Apple silicon. Sure, if you rewr…

Maybe I misread, but I understood that more as Apple using ARC and that gives them a memory advantage. M1 is simply making that more efficient by doing retain-release faster. But I agree that should not change total memory usage.

But I think in general you could say that Apple has focused more on optimizing their OS for memory usage than the competition may have done. Android uses Java which eats memory like crazy and I suspect C# is not that much better being a managed and garbage collected language. Not sure how much .NET stuff is used on Windows, but I suspect a lot.

macOS in contrast is really dominated by Objective-C and Swift which does not use these memory hungry garbage collection schemes, nor require JIT compilation which also eats memory.

Re: Apple Silicon M1: Black Magic Fuckery

#292

Post by Izikiel43 »

nojito wrote: post #187
gameswithgo wrote: post #152

Earlier quoted context omitted.

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

What? https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste... > Besides the additional cores on the part of the CPUs and GPU, one main performance factor of the M1 that differs from the A14 is the fact that’s it’s running on a 128-bit memory bus rather than the mobile 64-bit bus. Across 8x 16-bit memory channels and at LPDDR4X-4266-class memory, this means the M1 hits a peak of 68.25GB/s memory bandwidth. The…

By swap speed I think he meant that the bottle neck is the time that it takes to move data from the SSD to the RAM, not how fast can the RAM be read from the processor.

Re: Apple Silicon M1: Black Magic Fuckery

#293

Post by socialdemocrat »

fomine3 wrote: post #230
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…

I can't understand why less RAM is enough specially in Apple Silicon rather than Intel. Is the argument proved? RAM capacity is just RAM capacity. Possibly Swift-made apps uses less RAM compared to other apps, but microarchitecture shouldn't be matter.

I don't quite see that either. But I suspect that it is just macOS itself which uses less memory than Windows in general.

But the much faster SSD to RAM transfer for the M1 means that shuffling stuff in and out of RAM is much faster meaning RAM matters less.

Re: Apple Silicon M1: Black Magic Fuckery

#294

Post by cmelbye »

crazygringo wrote: post #137
supernova87a wrote: post #2

You know the thing I worry about next: how are apps going to inevitably bloat in inefficiency and claw back the improvements in CPU?

Well, the great thing is that as long as computers are bifurcated between a majority of slow Intel PC's and a minority of fast Apple Macs... apps will need to remain usable on Intels, so they'll hopefully stay super-fast on Macs! ;)

Was thinking the same exact thing while reading this. We’ll have a good chunk of lead time on that.

Re: Apple Silicon M1: Black Magic Fuckery

#295

Post by IggleSniggle »

mkj wrote: post #274
krrrh wrote: post #81

Earlier quoted context omitted.

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.

You can pick between a “swipe” animation and a “fade” animation.

Re: Apple Silicon M1: Black Magic Fuckery

#296

Post by heavyset_go »

anigbrowl wrote: post #228

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

Pretty slim, ARM SoCs require a lot of work on the vendor's part to support Linux[1], and Apple has said that they won't support running other operating systems outside of virtualization.

[1] https://news.ycombinator.com/item?id=25180129

Re: Apple Silicon M1: Black Magic Fuckery

#297

Post by dfox »

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…

I suspect that Apple didn't anything special to improve performance of reference counting apart from not using x86. Simply put x86 ISA and memory model is built on assumption that atomic operations are mostly used as part of some kind of higher-level synchronization primitive and not for their direct result.

Re: Apple Silicon M1: Black Magic Fuckery

#298

Post by kyriakos »

zakki wrote: post #223
RachelF wrote: post #218

Earlier quoted context omitted.

But one can choose to ignore fashion and wear comfortable clothes. Apple has chosen to make everyone live in its crazy world. Letting users skin the OS would be a better choice.

Usual answer is: go buy other vendor product.

Judging from HN posts that's what a lot of people are doing

Re: Apple Silicon M1: Black Magic Fuckery

#299

Post by aaron_m04 »

scoot wrote: post #271
JumpCrisscross wrote: post #177

Earlier quoted context omitted.

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

> Staff designers have to justify their existence by making changes to established design patterns.

Yet another example of the bullshit jobs David Graeber warned us about.

Re: Apple Silicon M1: Black Magic Fuckery

#300

Post by [deleted] »

dwaite wrote: post #186
BillinghamJ wrote: post #174

Earlier quoted context omitted.

Pretty sure you'll end up with exactly the same in an NSArray? ObjC is excellent but it's not doing anything fundamentally magic there

In Swift you can add value types to the heap-backed array directly, in ObjC you can use stack allocated arrays (since you have all of C) and there are optimizations such as NSNumber using tagged pointers.

[deleted]
Post reply on HN