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

181–190 of 1001 posts

Re: Apple Silicon M1: Black Magic Fuckery

#181

Post by grishka »

nbzso wrote: post #172
grishka wrote: post #142

Earlier quoted context omitted.

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…

Just a thought: If someone in 2008 asked me -What desktop interfaces will be used in 2020? My answer may have been: Apple will implement a new Desktop paradigm on top of Raskin Zoomable UI Ideas ( https://en.wikipedia.org/wiki/Jef_Raskin ). But here we are: Monster SOC with Cartoon Network on top. :)

The thing with interfaces is that there's no inherent need for change if the method of interaction doesn't change. It was a non-touch screen, a keyboard, and a mouse/trackpad 20 years ago, and it still is today. Some things just work great. They're tried and true and battle-tested. Like, you know, densely packed windows that are optimized for the precision of the mouse pointer.

Re: Apple Silicon M1: Black Magic Fuckery

#182

Post by dwaite »

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…

I believe the idea was that reference counting was more memory efficient than other forms of garbage collection, such as copy collectors and mark and sweep collectors which commonly make up generational garbage collectors.

Languages like Java also do not yet support stack-allocated value types outside a few primitives like integers, and heap allocations are both slower and less space efficient due to the indirection and memory management.

Re: Apple Silicon M1: Black Magic Fuckery

#184

Post by ianhowson »

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…

> people claiming that 8 GB isn't enough for the average user

I'm not claiming anything of the sort.

My point is that memory consumption seems to be greatly reduced in Big Sur, and that might make 8GB machines much better to use than before. All of my testing is on Intel machines. It's not exclusively an M1 phenomenon.

I would still recommend 16GB to anyone, and if the extra $200 was a factor, I would recommend that they buy last year's Intel with 16GB of RAM.

Re: Apple Silicon M1: Black Magic Fuckery

#185

Post by lynndotpy »

krrrh wrote: post #81
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…

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…

The animations on the iPhone are what made me return to Android.

On iPhones, you can only "reduce motion", which still has the "moving through molasses" feeling, replacing them with a fade in/out. Can you truly disable most animations in MacOS, or are they simply replaced with fade in/out animations?

Re: Apple Silicon M1: Black Magic Fuckery

#186

Post by dwaite »

BillinghamJ wrote: post #174
raphaelj wrote: post #89

Earlier quoted context omitted.

This is most probably more linked to Java/Kotlin vs Objective-C/Swift. Want an array of 1000 objects in Java ? You'll endup with 1001 allocations and 1000 pointers.

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.

Re: Apple Silicon M1: Black Magic Fuckery

#187

Post by nojito »

gameswithgo wrote: post #152
nojito wrote: post #101

Earlier quoted context omitted.

The quote right after explains your concerns. >The memory bandwidth on the new Macs is impressive. Benchmarks peg it at around 60GB/sec–about 3x faster than a 16” MBP. Since the M1 CPU only has 16GB of RAM, it can replace the entire contents of RAM 4 times every second. Think about that…

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 point of the memory bandwidth is so that it never has to swap to disk in the first place.

Re: Apple Silicon M1: Black Magic Fuckery

#188

Post by koffiezet »

I understand the machine is great or going to be great for most use cases. My mbp is my main workhorse, but as a freelance SRE "devops" guy, the Apple ARM platform won't be suitable for my job any time soon, if ever.

Docker is not yet available - but even when it would become available, emulating virtualised x86 code is explicitly not going to be supported. That in many cases means pulling a docker image built in a ci/cd pipeline where a dev screwed something up and debugging it locally is no longer an option. If I wasn't freelance, I could probably get away with some cloud instance to run all my docker stuff, but I'm dealing with too many different environments, for clients with various different legal requirements making this simply 'not an option'.

Too bad, because the machines look very promising for everything else. Development tools aren't there yet, but I expect that to be fixed pretty quickly.

Re: Apple Silicon M1: Black Magic Fuckery

#189

Post by Ar-Curunir »

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…

If your hardware enables more regular/efficient garbage collection, then it absolutely can lower memory consumption.

Given that the M1 chip was designed to better support reference counting, it makes sense that doing the same for HC could lead to a benefit

Re: Apple Silicon M1: Black Magic Fuckery

#190

Post by sneak »

jolux wrote: post #175
nbzso wrote: 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…

Oh hey another emacs user! You can turn off all the telemetry in macOS and they ask you if you want it on when you setup the computer. Agree to disagree on Big Sur, I love the new look. Keep in mind they’re calling it macOS 11, so there are probably bigger and less superficial changes down the road.

> You can turn off all the telemetry in macOS and they ask you if you want it on when you setup the computer.

That's false. You can turn off OS analytics but there is tons of telemetry built into almost every Apple app, separate from that, that you cannot disable. It tells you about it on first app launch. Open Maps, for example, and it will tell you about the unique, rotating identifier it uses to track your searches. Opting out of OS analytics does not disable telemetry for the other Apple services now deeply integrated in the OS. Even disabling these features doesn't prevent the mac from talking to the services, such as in the case of Siri.

Additionally gatekeeper OCSP checks on app launches serve as telemetry in practice, and this has no preference or setting to disable it.

Post reply on HN