[deleted]
Apple Silicon M1: Black Magic Fuckery
61–70 of 1001 posts
Re: Apple Silicon M1: Black Magic Fuckery
#62At 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've tried Linux on the desktop and know that I'm significantly more productive on a Mac (and also more productive on a Mac vs Windows).
It's partly a personal thing but I think that you have to look at the evidence in the marketplace - people switch to Linux for philosophical or technical reasons but not generally due to the user experience. Denying that evidence and pretending that it's otherwise isn't going to change that situation especially now Apple has an imminent hardware advantage.
Re: Apple Silicon M1: Black Magic Fuckery
#63I 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 think the argument they were trying to get to but totally failed to make is possibly along these lines
huge memory bandwidth relative to ram size + os level memory compression => massive reduction in memory pressure for many many many workloads.
macos has supported memory compression for awhile now -- i would hypothesize that M1 may have massively improved that subsystem in ways that actually do translate into needing less memory on average for a lot of common real-world workloads that amount to "human timescale multitasking" between large working sets -- eg i click this app and it has a huge working set and then click into another that has a large working set and then click back -- with those clicks that represent application context switches occurring very very rarely in machine time scale.
If memory compression subsystem can swap working sets into and out of compressed memory space insanely quickly with low power usage then the os might've gotten very aggressive about using that feature to put not recently accessed memory into compressed memory space.
Re: Apple Silicon M1: Black Magic Fuckery
#64weren't the old exploits on the intel processors patched by essentially making many operations slower? like they had to disable some cpu instructions which were previously innovative and this debilitated the irreparable processors. so a new architecture with better versions of the same instructions would feel very fast, since we went two steps back first.
Good point. Intel earned this, hard.
Re: Apple Silicon M1: Black Magic Fuckery
#65I 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…
[deleted]
Re: Apple Silicon M1: Black Magic Fuckery
#66This 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…
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?
Re: Apple Silicon M1: Black Magic Fuckery
#67Re: Apple Silicon M1: Black Magic Fuckery
#68Earlier quoted context omitted.
Are you suggesting that companies shouldn't make, and consumers buy, faster hardware?
I'd suggest that someone who breaks into Slack HQ and secretly installs a underclocking kernel extension on all their developers' Macs wouldn't be a bad person.
I wonder if "Electron runs fine on my machine" can be banned under hate speech rules instead of being allowed under free speech.
Re: Apple Silicon M1: Black Magic Fuckery
#69I have an iPad Pro with keyboard and a 15-inch MacBook Pro I got when my previous MacBook Air couldn’t handle the video editing I was dabbling in.
I desperately want one machine (and probably in the iPad form factor) but I don’t know if Apple is ever going to get me there.
What say you HN? Is there a future where I can have a single machine? Any other suggestions for what I can do about it today? I’ve test driven Surface computers in various flavors from friends of mine and I really can’t get down with Windows. Am I doomed to carry two machines with me all the time?
Re: Apple Silicon M1: Black Magic Fuckery
#70Earlier quoted context omitted.
But how? It has an Arm CPU - how does it differ from any other machine with a 64 bit Arm CPU?
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?