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

451–460 of 1001 posts

Re: Apple Silicon M1: Black Magic Fuckery

#451

Post by sidm83 »

momokoko wrote: post #426
chongli wrote: post #408

Earlier quoted context omitted.

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.

Agreed. Do not see anything worth downvoting at all.

Re: Apple Silicon M1: Black Magic Fuckery

#452

Post by ogre_codes »

CraftThatBlock wrote: post #405
victor106 wrote: post #109

> A task like editing 8K RAW RED video file that might have taken a $5000 machine before can now be done on a $699 Mac Mini M1 or a fan-less MacBook Air that costs $999 That’s insanely great. Maybe I am exaggerating but Apple’s M1 might be the best innovation in the tech industry in the past 5 years.

It's very easy to perform very well on a specific benchmark when there's dedicated hardware for this. I'm not saying this isn't good, it's great for people editing, but this isn't a general indicator of performance (which is reportedly good!)

> It's very easy to perform very well on a specific benchmark when there's dedicated hardware for this.

I'd say the same about GPUs as well. It's great for people who game, but beyond a certain baseline, it's pretty pointless for most of us.

> I'm not saying this isn't good, it's great for people editing, but this isn't a general indicator of performance

Umm, it's also great for people who watch YouTube or Netflix. Zoom calls use the encoder and the decoder. Fundamentally, modern computers do a crapload of video (and audio!) decoding and encoding. Arguably for most of us, it is more important than having a high performance GPU.

This is all trebly important when you are using Netflix, YouTube, HBO Max, Zoom, Skype, etc on battery where the specialized encoder uses about 1/3 the power as the CPU.

Re: Apple Silicon M1: Black Magic Fuckery

#453

Post by lilyball »

dfox wrote: post #297
torstenvl wrote: post #161

Earlier quoted context omitted.

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.

M1 is faster at retain/release under Rosetta2 than x86, and yet Rosetta2 still has the same strong memory model that x86 does.

Re: Apple Silicon M1: Black Magic Fuckery

#454

Post by favorited »

brundolf wrote: post #54
lisper wrote: post #44

Earlier quoted context omitted.

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

No, because Rc isn't atomic. Arc, however, would get the benefit. The reason retain/release in ObjC/Swift are so much faster here is because they are atomic operations.

Re: Apple Silicon M1: Black Magic Fuckery

#455

Post by [deleted] »

macintux wrote: post #361
throw0101a wrote: post #348

Earlier quoted context omitted.

That's nice. But what does CPU/GPU horse power have to do with memory? If I want to spin up a bunch of VMs to do pre-commit test builds in clean environments, and each need RAM for the OS and user land, being able to edit a lot of raw video does nothing for me. I'm generally fine running macOS (or Linux), but sometimes I need to boot up Windows in a VM for specialized apps: how do I assign >16GB of memory to it if I…

So far as I can tell from this thread, the open question was: can these computers edit 8k video? The answer per that video seems to be yes, with limitations. I’m not trying to assert anything about anyone’s needs.

[deleted]

Re: Apple Silicon M1: Black Magic Fuckery

#456

Post by lilyball »

wahern wrote: post #277
lilyball wrote: post #72

Earlier quoted context omitted.

I sure hope so. In macOS 10.15, the fast path for a retain on a (non-tagged-pointer) Obj-C object does a C11 relaxed atomic load followed by a C11 relaxed compare-and-exchange. This seems pretty standard for retain-release and I'd expect Rust's Rc to be doing something similar. It's possible Apple added some other black magic to the runtime in 10.16 (and they haven't released the 10.16 objc sources yet) but it's hard…

I didn't understand why the implementation wouldn't just do an atomic increment, but I guess Obj-C semantics provide too much magic to permit such a simple approach. The actual code, in addition to [presumably] not being inlined, does not seem easy to optimize at the hardware level: https://github.com/apple/swift-corelibs-foundation/blob/main... The native Swift retain (swift_retain above) seems to be somewhere insid…

What you’ve linked is CoreFoundation’s retain, Objective-C’s can be found in https://opensource.apple.com/source/objc4/objc4-787.1/runtim... (look for objc_object::rootRetain).

The short answer for why it can’t just be an increment is because the reference count is stored in a subset of the bits of the isa pointer, and when the reference count grows too large it has to overflow into a separate sidetable. So it does separate load and CAS operations in order to implement this overflow behavior.

Re: Apple Silicon M1: Black Magic Fuckery

#457

Post by hyperdimension »

macintux wrote: post #287
jandrese wrote: post #265

Earlier quoted context omitted.

The RAM limitation on the first gen M1s makes this claim a bit dubious.

https://www.diyphotography.net/this-700-computer-can-edit-8k...

Just for the future: you always have the option to formulate an argument in words rather than simply copying-and-pasting link "salvos" to the other.

I might even go so far as to say it might promote a better discussion!

Re: Apple Silicon M1: Black Magic Fuckery

#458

Post by gumby »

tobyjsullivan wrote: post #243
sooheon wrote: post #219

Earlier quoted context omitted.

I'm surprised they're getting rid of long held keyboard shortcut conventions though. Previously, modal popup options (i.e. for saving docs) could be selected via Option-letter, i.e. "Save _a_ll" could be selected with Option-a. Their new popups which may or may not be prettier force you to either use the mouse or turn on "Use keyboard navigation to move focus between controls" globally and tab around. Neither of thes…

In Apple's defence, I've been exclusively a mac user (work and personal) for going-on eight years now and I had no idea about the Option-letter shortcut. I've always found keyboard nav within modal popups confusing. I consider myself lucky if hitting Space selects the primary button. Doesn't sound like the change is necessarily an improvement, though.

MacOS used to show the keys when you held down the command key, but they foolishly removed that a while ago.

Re: Apple Silicon M1: Black Magic Fuckery

#459

Post by bitwize »

ogre_codes wrote: post #442
mhh__ wrote: post #410

Earlier quoted context omitted.

Linus Torvalds was and is probably still right that unless developers have the same breed of processor (not just AArch64 but the actual chipset, for example) on the bench it'll probably never be particularly prevalent server-side. That and Apple presumably dream of not letting developers touch anything without going through their stack, so no touching the hardware for you. For example, I believe Apple expose Performa…

I suspect the previous poster was referring to non-Apple ARM hardware, not Apple servers. > The wider point being that Apple will probably never let you run Linux on their hardware Apple has already issued docs on how to load alternative OSs on their system and has said explicitly that Windows support is up to Microsoft. Linux on Mac metal is not out of the question, but it's going to take some time to get running we…

That was for x86 Macs. Apple is not supporting alternative operating systems on the M1 Mac except via virtualization.

Re: Apple Silicon M1: Black Magic Fuckery

#460

Post by spear »

totorovirus wrote: post #416

A moment when a tech giant can build a computer from bottom to top.

Apple does use TSMC to build the M1 itself. So it's not quite bottom to top like the early computers up to the early to mid 90s, when a number of the workstation companies (eg. DEC, IBM, HP) still had their own fabs to make the CPUs.
Post reply on HN