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

51–60 of 1001 posts

Re: Apple Silicon M1: Black Magic Fuckery

#51

Post by CalChris »

jrm4 wrote: post #6

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

Linux gets the look right. But it gets the feel wrong, very wrong. This surprises me. I don’t understand why they haven’t caught up on feel.

Re: Apple Silicon M1: Black Magic Fuckery

#52

Post by acdha »

jrm4 wrote: post #6

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

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

Your comment is based on some sweeping claims with no supporting evidence — can you point to something specific you think is wasteful, alleged harmful telemetry (not Jeffrey Paul's misunderstandings about OCSP), or prevents “getting stuff done”?

As someone who started using Linux as a desktop OS in the 1990s I would especially suggest that if smugly-nonspecific sneering at other operating systems was an effective advocacy strategy the number of Linux desktop users would be a lot greater than it is now.

Re: Apple Silicon M1: Black Magic Fuckery

#53

Post by saagarjha »

berkut wrote: post #31
trevyn wrote: post #27

Earlier quoted context omitted.

They stuff the reference count in the unused bits of the 64-bit pointers.

So just tagged pointers essentially? That's possible on x86 isn't it (unless it's an endian-thing)?

It is and both both platforms use tagged pointers.

Re: Apple Silicon M1: Black Magic Fuckery

#54

Post by brundolf »

lisper wrote: post #44
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…

Remember Lisp machines? The M1 is a Swift machine.

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

Re: Apple Silicon M1: Black Magic Fuckery

#55

Post by j16sdiz »

berkut wrote: post #31
trevyn wrote: post #27

Earlier quoted context omitted.

They stuff the reference count in the unused bits of the 64-bit pointers.

So just tagged pointers essentially? That's possible on x86 isn't it (unless it's an endian-thing)?

yes, but they have hardware acceleration for that specific tagged pointer type.

Re: Apple Silicon M1: Black Magic Fuckery

#56

Post by wtallis »

berkut wrote: post #31
trevyn wrote: post #27

Earlier quoted context omitted.

They stuff the reference count in the unused bits of the 64-bit pointers.

So just tagged pointers essentially? That's possible on x86 isn't it (unless it's an endian-thing)?

x86-64 was designed to prevent (or at least discourage) efficient use of tagged pointers, with the higher half/lower half split in the virtual address space. All the excess high-order bits you don't need for actual addressing are required to have the same value, so you effectively only get at most one tag bit.

Re: Apple Silicon M1: Black Magic Fuckery

#57

Post by xoa »

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, including essentially any non-AIO desktop system above the Mini. At one point they had quite competitive PowerMacs and then Mac Pros covering the range of $2k all the way up to $10k+, and while sure there was some premium there was feature coverage, and they got regular yearly updates. They were "boring", but in the best way. There didn't need to be anything exciting about them. The prices did steadily inch upward, but far more critically sometime between 2010 and 2012 somebody at Apple decided the MP had to be exciting or something and created the Mac Cube 2, except this time to force it by eliminating the MP entirely. And it was complete shit, and to zero surprise never got a single update (since they totally fucked the power/thermal envelope, there was nowhere to go) and users completely lost the ability to make up for that. And then that was it, for 6 years. Then they did a kind of sort of ok update, but at a bad point given that Intel was collapsing, and forcing in some of their consumer design in ways that really hurt the value.

The hackintosh, particularly virtualized ones in my opinion (running macOS under ESXi deals with a ton of the regular problem spots), has helped fill that hole as frankenstein MP 2010s finally hit their limits. I'm sure Apple Silicon will be great for a range of systems, but it won't help in areas that Apple just organizationally doesn't care about/doesn't have the bandwidth for because that's not a technology problem. So I'm a bit pessimistic/whistful about that particular area, even though it'll be a long time before the axe completely falls on it. It'll be fantastic and it's exciting to see the return of more experimentation in silicon, but at the same time it was a nice dream for a decade or so to be able to freely take advantage of a range of hardware the PC market offered which filled holes Apple couldn't.

Re: Apple Silicon M1: Black Magic Fuckery

#58

Post by egypturnash »

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?

In Electron 14, we have found an astounding new paradigm for writing apps that results in astounding developer time savings! Now instead of running your Javascript app inside a copy of Chrome, we have a custom hybrid of Javascript and Lisp, which is internally transpiled onto a Brainfuck interpreter running in Conway's Life!

Electron 15: The Life machine has been re-implemented as a series of GPU instructions, which will use up approximately 93% of most users' graphics performance in return for a 20% speedup!

Re: Apple Silicon M1: Black Magic Fuckery

#59

Post by saagarjha »

jonny_eh wrote: post #24
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?

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.

Re: Apple Silicon M1: Black Magic Fuckery

#60

Post by _2d30 »

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…

Brew is only slightly a mess, in my experience.

I've installed brew both in the historical /usr/local location as well as the future home of /opt/homebrew. I then created these two aliases:

  alias armbrew="/opt/homebrew/bin/brew"
  alias intbrew="arch -x86_64 /usr/local/bin/brew"
My PATH selects for programs installed in the /opt/homebrew location first and then /usr/local. I try to install with the ARM version first with `armbrew install -s ` and if it fails, I move to using the `intbrew` alias as normal. I haven't really had any issues.

It's obviously still messy but not in a way that is too bad!

Post reply on HN