Apple’s M1 Positioning Mocks the Entire x86 Business Model

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by igammarays on Friday April 23, 2021 @07:13AM (#26913470)

Apple Silicon is NOT just an ARM CPU. It's also a deep integration with macOS, and a unified memory architecture (less unnecessary copying on the bus). For example on the M1, certain very common operations for macOS apps, like freeing Objective C pointers, which happens millions of time per second, are optimized at the hardware level. The M1 is not a CPU.

So no, the Ryzen 5000 with 5nm would NOT level the field.

[ Parent | on HN ]

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by skohan on Friday April 23, 2021 @07:32AM (#26913587)

But from what I understand, there's a much smaller gap between ryzen and M1 than intel

[ Parent | on HN ]

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by rsynnott on Friday April 23, 2021 @02:13PM (#26917508)

> For example on the M1, certain very common operations for macOS apps, like freeing Objective C pointers, which happens millions of time per second, are optimized at the hardware level

I mean, this is _kind_ of true, but it's not unique to Objective C, the M1, or even particularly intentional. The _ARM_ memory model is more conducive to reference counting in general than the x86 one. Nothing special about Apple's chip in that respect, tho.

[ Parent | on HN ]

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by kllrnohj on Friday April 23, 2021 @12:36PM (#26916474)

> and a unified memory architecture (less unnecessary copying on the bus).

So does every other Intel & AMD laptop CPU from the last 5+ years. So does every Qualcomm SoC from the last 5+ years. This has been incredibly common for years and years now.

This does a lot less than you think it does, particularly since there's very few consumer workloads that switch between CPU & GPU.

[ Parent | on HN ]

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by slver on Friday April 23, 2021 @07:28AM (#26913561)

How are objective c pointers handled?

[ Parent | on HN ]

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by skohan on Friday April 23, 2021 @07:31AM (#26913586)

From what I understood, ARC operations are cheaper on M1 because of weaker memory ordering constraints. But I thought this was and ARM thing, not M1 specific, but I could be wrong

[ Parent | on HN ]

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by astrange on Friday April 23, 2021 @07:56AM (#26913765)

That's right. M1 doesn't have specific Objective-C optimizations.

[ Parent | on HN ]

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by slver on Friday April 23, 2021 @09:30AM (#26914548)

An interesting realization that it could, though.

Overwhelming majority of MacOS/iOS software is written on Obj C and Swift, which have the same underlying semantics.

That said ARC doesn't have such a great impact on performance as some people (esp. fans of Java's GC etc.) would convince you. Most ++/-- operations on the refcount are eliminated by the compiler.

[ Parent | on HN ]

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by pjmlp on Saturday April 24, 2021 @03:10AM (#26922914)

Some fans do measure, and know the difference from marketing and reality in regards to tracing GC versus reference counting marketing material.

https://github.com/ixy-languages/ixy-languages

[ Parent | on HN ]

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by astrange on Saturday April 24, 2021 @10:10PM (#26929793)

Wallclock time isn't the only performance metric to care about. ObjC had a GC in the past and lost it in favor of ARC for a reason; it's a poor fit for iPhone-sized devices.

[ Parent | on HN ]

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by pjmlp on Sunday April 25, 2021 @05:48AM (#26931526)

That was the marketing reason, the official reason was that fitting a GC into a language with C memory model wasn't never going to work, and there were plenty of crashes and memory corruptions coming out of that.

So they made the only sensible decision, and just like Microsoft did with COM, they added support to the Objective-C compiler to automate retain/release messages in OS X Frameworks.

Naturally being Apple, that pivot had to be sold in a way that the reason was being of RC being better and not because of the technical failure to have a tracing GC in Objective-C , while remaining compatible with C memory model.

Apparently, moving the GC document with all its caveats regarding possible programming issues, out of search index also helps to keep the story as well.

https://developer.apple.com/library/archive/documentation/Co...

[ Parent | on HN ]

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by astrange on Sunday April 25, 2021 @10:44PM (#26938726)

No, the performance issues are real. GC programs have more page demand and higher peak memory use, which is specifically what the iOS memory model (jetsam and memory compression) can't deal with well. They can have some wins due to compacting.

There is of course a GC language on iOS (JavaScript) but expensive webpages get killed quickly.

[ Parent | on HN ]

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by pjmlp on Monday April 26, 2021 @02:32AM (#26939855)

And yet Microsoft was able to do very good phones with GC languages with very good performance for 200 euros, maybe Apple should talk to their runtime engineers.

[ Parent | on HN ]

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by astrange on Tuesday April 27, 2021 @01:52AM (#26952483)

Wasn't most of the system stack in C++ since it was shared with either Windows or Nokia? Either way, they went out of business, so we can't tell if they can support a phone 5 years back with new OS features.

[ Parent | on HN ]

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by skohan on Friday April 23, 2021 @07:41PM (#26920580)

The worst case performance is very bad though. I have done some playing around with pushing Swift in terms of performance, and it's very hard because of ARC.

[ Parent | on HN ]

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by foobiekr on Friday April 23, 2021 @08:18PM (#26920841)

Code in the fastpath must not generate substantial garbage whether using ARC or a gc. That's just a coding error.

[ Parent | on HN ]

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by skohan on Saturday April 24, 2021 @10:36AM (#26925120)

It's not about garbage creation, is about reference cost. With ARC, you pay a penalty every time you pass a reference type, not only for memory churn. You can avoid this using value types, but this often results in a lot of unnecessary copying.

It's not unavoidable, but Swift doesn't give good tools for avoiding ARC-based performance cliffs, so it takes a lot of profiling and effort compared to other languages.

[ Parent | on HN ]

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by astrange on Saturday April 24, 2021 @10:49PM (#26929969)

It's ok to generate garbage if it goes away immediately; that's essentially a stack allocation. Performance problems come up when you have a mix of lifetimes. (that slows GCs down and causes heap fragmentation outside copying GCs)

[ Parent | on HN ]

Re:Apple’s M1 Positioning Mocks the Entire x86 Business Model by igammarays on Friday April 23, 2021 @09:40AM (#26914645)

I can't find the interview now, but I distinctly remember someone at Apple saying that Cocoa apps benefit from hardware-level optimizations of common Objective C operations in the M1.

[ Parent | on HN ]