Live data from Hacker News

Apple Silicon M1: Black Magic Fuckery

Post reply on HN

Print view View original

421–430 of 1001 posts

Re: Apple Silicon M1: Black Magic Fuckery

#421

Post by AnonC » Wed, Nov 25, 2020, 4:52 AM UTC

nemothekid wrote: post #352

ianai wrote: post #256

Earlier quoted context omitted.

Tfa says the hardware optimization for ARC is to the point of being bespoken. Hardware will always beat software optimization. Further, the other GCs have much higher ram overheads than this combined, bespoke system. Apple has decades of proven experience producing and shipping massively over engineered systems. I believe em when they say these processors do ARC natively.

I’m not denying that Apple has better ARC performance. It’s that I don’t understand how an application would use less memory on ARM than x86. I’d expect the ARM code to run faster (as a result of being able to do atomic operations faster), but I don’t see how that translates to less memory usage

In one of those random “benchmark tests” online where someone opened several applications on an M1 Mac with 8GB RAM and did some work on those, they kept Activity Monitor open alongside and pointed to the increase in swap at some stage. So it seems like the swap is fast enough and is used more aggressively. That reduces the amount of RAM used at any point in time. The data in RAM has also benefited from compression in macOS for several years now.

Re: Apple Silicon M1: Black Magic Fuckery

#422

Post by jolux » Wed, Nov 25, 2020, 4:54 AM UTC

sneak wrote: post #414

alwillis wrote: post #365

Earlier quoted context omitted.

Additionally gatekeeper OCSP checks on app launches serve as telemetry in practice, and this has no preference or setting to disable it. This is just a check that the developer's certificate hasn't been revoked or expired. I wouldn't call it telemetry. Apple has said they're working on allowing users to opt-out of Gatekeeper checks if that's what people want. Details— https://eclecticlight.co/2020/11/16/checks-on-exe…

> This is just a check that the developer's certificate hasn't been revoked or expired. I wouldn't call it telemetry. It's an unencrypted network transmission of a unique identifier, at the time of an app launch, that maps to a single app for 99% of cases (due to the fact that almost all developers publish only a single app). That's objectively telemetry no matter what you call it, irrespective of the intent of the d…

>That's objectively telemetry no matter what you call it, irrespective of the intent of the designers.

There's no objective definition of "telemetry" that I know of, though, and this is a purely functional feature implemented straightforwardly. They are moving towards encrypting the requests, too.

Whether or not you can toggle something is absolutely relevant from a privacy perspective. Gatekeeper is something that should be on by default anyways, and I personally am more concerned about my endpoint security than Apple getting pinged with a signature when I open an app.

Re: Apple Silicon M1: Black Magic Fuckery

#423

Post by breatheoften » Wed, Nov 25, 2020, 4:56 AM UTC

alwillis wrote: post #331

spurgu wrote: post #143

Earlier quoted context omitted.

How is "Apple may run Linux in their cloud, but their laptops don't ;(" not on topic? Edit: It's not like Apple has any (commercial) interest in working with the Linux kernel developers to ensure support/compatibility even if the M1 is ARM based. Edit 2: Don't get me wrong, if Apple announces they will support Linux I'll run out the door and buy one now, as a MacOS user. Edit 3: And this is a criticism against Apple…

Do you really think the M1 future is looking rosy for Linux? I think fairly soon, we'll have Linux running nicely on Apple Silicon Macs, using the hypervisor built into macOS. And it will run faster than comparable Intel machines. Apple gets the importance of Linux and Docker for developers; I'm pretty sure it'll get worked out.

I hope that hypervisor eventually "becomes the os" -- such that macOS or linux or whatever "collected set of software that needs to think it has an ownership relationship to hardware state" can all run on top of essentially the same hypervisor provided hardware abstractions ...

Re: Apple Silicon M1: Black Magic Fuckery

#424

Post by iJohnDoe » Wed, Nov 25, 2020, 4:58 AM UTC

totalZero wrote: post #388

coopsmgoops wrote: post #283

Earlier quoted context omitted.

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

I think the suggestion is that the best OS developers were allocated to producing M1-compatible OS rather than maintaining x86-compatible OS.

100% this, as well as Rosetta, etc.

Re: Apple Silicon M1: Black Magic Fuckery

#425

Post by ngai_aku » Wed, Nov 25, 2020, 5:00 AM UTC

zarkov99 wrote: post #198

I am thinking about getting thing mostly to ssh into a linux server. I would like to run emacs on the server and have its display bounced back via X to the Mac. Is this practical? I tried Quartz on my wife's Mac but the fonts looked like crap.

Why run emacs on the server instead of running emacs on your local machine and accessing the server via tramp?

Re: Apple Silicon M1: Black Magic Fuckery

#426

Post by momokoko » Wed, Nov 25, 2020, 5:06 AM UTC

chongli wrote: post #408

xoa wrote: post #57

Not to speak for anyone else, but one thing I gently disagree with: > Given that Hackintoshers are a particular bunch who don’t take kindly to the Apple-tax[...] I have zero issues with an Apple premium or paying a lot for hardware. I think a major generator of interest in hackintoshes has been that there are significant segments of computing that Apple has simply completely (or nearly completely) given up on, includ…

Apple does not want to offer to the hackintosh/enthusiast market because they are the most price conscious segment. Targeting that segment means putting out extremely performant, low-margin commodity machines. Doing so then cannibalizes the market for their ultra-high-end stuff. Not only that, though. Enthusiasts are also extremely fickle and quick to jump ship to a cheaper hardware offering. If you look at all of Ap…

I would be extraordinarily grateful for some insight into why this comment was downvoted.

Re: Apple Silicon M1: Black Magic Fuckery

#427

Post by mortenjorck » Wed, Nov 25, 2020, 5:12 AM UTC

yardie wrote: post #16

I'm typing this from a 2014 i7-4980HQ 15" MBP. This machine would have been replaced in 2017 but I wasn't impressed with that years model. I had planned to upgrade in 2020 but the announcement of the M1 basically quashed that. I've been on this planet long enough to know when Apple changes course like this the old architect is already obsolete. 68k -> PPC -> x86_64 -> ASi. The PPC G5 got exactly 1 OS upgrade (10.5) b…

This may actually be the perfect time to get a first-version Apple notebook, because it looks like the big design refresh will be staggered one release cycle. Buying one right now gets you the powerful new architecture inside the tried-and-true industrial design.

While the risks are probably less than they were earlier in Apple's history, I'd much rather take a chance on a first-generation Apple Silicon SoC than on a first-generation MacBook Pro redesign.

Re: Apple Silicon M1: Black Magic Fuckery

#428

Post by harrygeez » Wed, Nov 25, 2020, 5:12 AM UTC

woah wrote: post #404

crazygringo wrote: post #129

Earlier quoted context omitted.

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…

It's the never ending mystery of Hacker News- how do the commenters on here get their computers to run so slowly?

Docker and a few language servers can seriously drag your MacBook with 8GB RAM. Throw in another Android emulator...

Re: Apple Silicon M1: Black Magic Fuckery

#429

Post by kube-system » Wed, Nov 25, 2020, 5:22 AM UTC

nycticorax wrote: post #409

donor20 wrote: post #407

Earlier quoted context omitted.

What I don't understand - Windows 10 Pro comes with tons of pre-installed junk - Candy Crush etc. Just charge what you need to, business don't want this stuff.

Well, large businesses at least get Windows 10 Enterprise, which doesn't come with all of that nonsense. The real shame is that you can't get Windows 10 Enterprise without a volume license.

You can get Win 10 Pro. I don’t remember my system having any of that junk preinstalled

Re: Apple Silicon M1: Black Magic Fuckery

#430

Post by sgerenser » Wed, Nov 25, 2020, 5:24 AM UTC

nemothekid wrote: post #154

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

The only thing I can think of that would actually reduce memory usage on M1 vs the same version of MacOS on x86 would be if they were able to tune their compressed memory feature to run faster (with higher compression ratio) on the M1. That would serve to reduce effective memory usage or need to fall back to swap. I would not expect something like that to be responsible for more than, say, a 5-10% RAM usage decrease though.

Post reply on HN