Live data from Hacker News

Undocumented arm64 ISA extension present on the Apple M1

gist.github.com

121–130 of 202 posts

Re: Undocumented arm64 ISA extension present on the Apple M1

#121

Earlier quoted context omitted.

Don't be absurd. LLVM was a research project until Apple hired Chris Lattner and poured money into it to make a viable alternative to GCC. They've been among the project's top contributors (financially and in terms of code) for 15 years. That's quite the long con. Apple creates plenty of proprietary technologies but I can't think of a time they've been credibly accused of crushing an open technology that already exis…

CUPS is the closest where you could accuse Apple of doing that I guess.

Put another way: "Apple pays project leader Bay Area salary + pre-iPhone AAPL stock to support open source development for more than a decade." (There are certainly more projects Apple relies on that deserve this!)

Most of Apple's extinguished open source projects are ones they started themselves and then abandoned.

Re: Undocumented arm64 ISA extension present on the Apple M1

#122
post #87

Earlier quoted context omitted.

My life is so much better being in the Apple ecosystem. Some of it was unintentional, but now its iPhone, Macbook Pro, Apple Watch, Airpods Pro, and IOT devices that use Homekit. I have an iPad but I use it the least. Pre-Intel I used to make fun of "Apple fanboys". But aside from the niche and incompatibilities of the PowerPC architecture back then, that turned out to be a lot of other immaturities I had and was rai…

This is a non-sequitur. There is nothing stopping Apple from doing things in an open manner - it's purely cultural. The fact that they don't is why I do not buy for a second that they can be trusted with privacy, whether they care or not. The quality of Apple's ecosystem is because of the centralized effort put into it and them owning the stack, not because the end result is walled-in.

When someone tells me Apple really cares about user privacy, I point them to how Apple has been deliberately crippling their wares to actually spy better on their users. Some of the recent events include:

- Crippled macOS Mojave+ to let Apple know every app you open (in the name of malware protection, but sent unencrypted over the internet).

- Crippled macOS Big Sur to allow any Apple whitelisted software to bypass any user application firewall blocks and some VPN apps.

- Even ios, that has a whole lot of "do you give app permissions" for loads of stuff, leaves a glaring wide hole open as it doesn't let the user to allow or block an app from connecting to the internet (on WiFi).

Re: Undocumented arm64 ISA extension present on the Apple M1

#123

Earlier quoted context omitted.

Apple added custom instructions on top of the ARM instruction set to do matrix operations. Matrix operations are used a lot in some algorithms, such as in computer graphics and machine learning and these instructions help those operations go faster. Although the ARM ISA has a multiply and accumulate instruction, it would take many more instructions on a standard ARM core to compute a matrix with only standard instruc…

Correction: ^when applications use these instructions; either as a result of use of a system API/framework, of the compiler optimizing code into these M1 instructions, or of the developer writing M1 assembler themselves. It is very likely that the majority of cases that use these instructions will be compiled by Xcode without the knowledge of developers that these instructions exist at all.

Apple might use these instruction in CoreML/Accelerate Framework and not integrated to LLVM as the author said:

> This is an undocumented arm64 ISA extension present on the Apple M1. These instructions have been reversed from Accelerate (vImage, libBLAS, libBNNS, libvDSP and libLAPACK all use them),

So we still cannot understand all of them from LLVM source code.

Re: Undocumented arm64 ISA extension present on the Apple M1

#124
post #100

I’m thinking this is related to the machine-learning coprocessor. They likely expose this to developers through their ML API and don’t want to have to support this for external customers if it changes. Still this is a great find!

Other vendors ML hardware is very much "A far away device over the PCI express bus which you give bunch of work to and later come back and see if its done".

Looks like apple has decided to make it very tightly integrated into the CPU. It means while doing ML operations, the CPU core can't go off and do other useful work. It also forces all cores to require matching ML hardware (or have a lot of OS complexity as certain threads can only run on some cores). The benefit is latency to get ML stuff done is lowered from microseconds to nanoseconds.

I suspect Apple probably messed up with that tradeoff... Very few applications can't wait a few microseconds for results of some ML computation...

Re: Undocumented arm64 ISA extension present on the Apple M1

#125

Earlier quoted context omitted.

On the other hand, Apple released their 64-bit ARM backend for LLVM[1] in 2014. They announced their intention do so almost immediately after the first ARM64 phone, but the process took several months because it had to be merged with a duplicate backend developed by others. I think it is likely that support for these instructions will be upstreamed to LLVM, and the teams involved in this monumental transition (which…

I just started getting into macOS and iOS development and the documentation is HORRENDOUS. Even the classroom educational material Apple put out is incomplete, outdated, and often completely wrong! Additionally, It seems to be impossible to compile anything in Xcode other than a hello-world without gettting undocumented warnings and (non fatal) errors logged, which, if you can find a matching thread on their forums,…

Why not pretend Swift doesn't exist and just use Objective-C instead? It's stable, it's well-understood, there's a ton of examples and docs everywhere and it hasn't changed much in a decade.

I'm mainly an Android developer, so I've never made anything serious for the Apple ecosystem (only some tiny Mac apps for myself), but I just hate moving targets with burning passion. It's hilarious to look at all the "community" with their Kotlin and support libraries and jetpack and other abstract-the-evil-OS-away stuff changing and breaking everything three times a month while the only changes I see myself are those to the raw underlying system APIs whenever there's a major OS release.

Re: Undocumented arm64 ISA extension present on the Apple M1

#126
post #66
post #7

Earlier quoted context omitted.

In the bigger picture Apple aren't really documenting anything for their new toys, which is not the end of the world but is a huge step back for openness. There is - as far as I can see - no long-form documentation for M1 other than patents. I already refuse to own apple products so I don't really have any skin in the game, but consider that if microsoft were like this the blind eye would not be turned - buy our new…

From an Apple perspective openness is a feature, not a goal in itself. Youre worrying about this or that specific ARM instruction, but Apple doesn't even want you to care whether it's ARM, or Intel, Or PowerPC, or whatever. It's an Apple system, part of the MacOS ecosystem and supported by Apple dev tools and power user features. If that's not the world you are interested in, what are you even doing owning a Mac? App…

That's true, at some level of abstraction you stop caring practically about openness. That line has shifted, and it points to hardware being commoditized more than lock-in. Do you care who made your logic gates or if it's documented?

Re: Undocumented arm64 ISA extension present on the Apple M1

#127

Earlier quoted context omitted.

Ultimately what the executives think is the reason is the real reason, as we saw from Oravle reproprietizing Solaris. And yes, it was a while back that literally lawyers had to get involved in their blatant GPL violation in the compiler space. We absolutely get to judge a company on it's past actions.

> We absolutely get to judge a company on it's past actions. I wholeheartedly agree with that statement, but you are judging a company based on the actions of another company it acquired 7 years later.

I'd argue that Apple of today is closer to Nextstep than Apple of the same time frame. Like, it was literally Steve Jobs making that decision at the time to violate the GPL. The joke for the longest time was that Nextstep bought Apple for negative dollars because of how much senior leadership was carried over from nextstep.

It's not like it was some random startup they acquihired for a couple engineers.

Re: Undocumented arm64 ISA extension present on the Apple M1

#128
post #51

Earlier quoted context omitted.

My point about the docs isn't the day-to-day stuff, but the things that cannot be machine generated - to write a good compiler you need to know the details of how the CPU is put together underneath. Intel will give you 800 pages on how to optimize for their current ISA (AMD will give you 45, but still)

As I understand it, Intel will also sell you a compiler that can optimize better than GCC because they know internal microarchitecture details. To me, that seems like a more clear-cut by-design conflict of interest between chip designer and user than these undocumented instructions.

GCC and Clang both generally match ICC’s performance, and in my experience beat it more often than they lose to it. ICC’s only real advantage is MKL and other bundled libraries, which are generally better than what free software has to offer.

Re: Undocumented arm64 ISA extension present on the Apple M1

#129
post #27

Earlier quoted context omitted.

From a third-party developer's perspective the ISA will be Swift. The actual CPU ISA will be a closely guarded trade secret. It will, however, run Swift code 2-3x faster (on a single-core basis) than any commercially available commodity CPU -- especially since Apple pays silicon fabs to not manufacture 3nm hypercubic gallium-arsenide ICs or whatever the cutting edge is on behalf of competitors.

I assume this is satire.

Nah fam. It's clear what Apple want: soup-to-nuts control of the platform and ecosystem. Anything less would be putting the value of the #1 brand in the world in the hands of potentially unscrupulous third-party devs. So whether you can run anything on Apple Silicon, what you can run, what inputs you are allowed to run it on will be decisions made in Cupertino. If just anyone is allowed to emit Apple Silicon binaries that presents a problem to the whole chain of custody.

In fact, it wouldn't surprise me if future versions of Xcode did all their compilation in Apple's cloud, without an option for local compilation.

Re: Undocumented arm64 ISA extension present on the Apple M1

#130

Earlier quoted context omitted.

> Apple can make tools that use the undocumented ISA, which they don't have to release to the public, potentially using it to develop applications with performance advantages that no one other than Apple can attain. Why would they? They sell hardware, not really software.

>They sell hardware, not really software. But they make more money from the Apple Store and the other services and they are always giving advantages to their own stuff on iOS like using private APIs or bypassing security rules .

If they make money from the App Store, why would they want to hobble the software in the App Store?
Post reply on HN