Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Undocumented arm64 ISA extension present on the Apple M1

gist.github.com

Post reply on HN
Print view View original

51–60 of 202 posts

Re: Undocumented arm64 ISA extension present on the Apple M1

#51

Post by mhh__ »

rgovostes wrote: post #25
mhh__ wrote: 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…

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…

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)

Re: Undocumented arm64 ISA extension present on the Apple M1

#52

Post by a1369209993 »

giantrobot wrote: post #16
vegetablepotpie wrote: post #8

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…

> That enables the M1 chip to be faster in this case when developers use these instructions in their applications. Or more typically the compiler will emit those instructions and everyone gets them for free.

That's actually generally not true WRT SIMD/vector instructions (see eg http://yosefk.com/blog/humans-and-compilers-need-each-other-... which contrasts this with the more compiler-friendly VLIW case); they impose nontrivial requirements on data structures and ABI, so the application code needs to at least be aware of the possibility of vectorization, even if it's agnostic to whether the implementation actually uses it.

Re: Undocumented arm64 ISA extension present on the Apple M1

#53

Post by Someone »

rwmj wrote: post #35
mhh__ wrote: 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…

> Apple aren't really documenting anything for their new toys This seems an odd strategy for an accelerator. How are they expecting that people will use these new instructions? Only through Apple-supplied closed source compilers and libraries? (This is not meant to indicate you're wrong, only I'm confused about Apple's strategy)

The Accelerate Framework is a library with common functions such as BLAS, neural networks, Fourier transforms and compression (https://developer.apple.com/documentation/accelerate)

That is similar to Intel providing such functions in a library for their CPUs (https://software.intel.com/content/www/us/en/develop/tools/o...).

A difference, of course, is that Apple can ship it with its OS, and does so.

I would guess they’re not or not yet willing to commit to shipping these instructions in future hardware (possibly, but that is more guesswork, because they have to work around bugs to use them. Those NOPs this article is talking about might be to work around them)

Re: Undocumented arm64 ISA extension present on the Apple M1

#54

Post by _underfl0w_ »

emteycz wrote: post #40
_underfl0w_ wrote: post #31

Earlier quoted context omitted.

> Let's be happy with what we got. Ouch. It's exactly this mentality that enables malicious actors - "it could be worse". It could always be worse, but that doesn't make it sufficient justification. Functional equivalent: "It could always be even more anticompetitive. Let's be happy with what we got."

Eh, what ? What malicious actors? What sufficient justification, and justification of what and to whom? What could be worse? What could be more anticompetitive, and competing with what exactly? I said nothing like this, your "equivalents" are from an entirely different world. I said we should be happy Apple decided to open their platform - because they didn't have to, at all. It's entirely their right to not open any…

Meh, nothing serious, just that the "it could be worse" line of thinking can be a little dangerous if broadly applied since it could always be at least marginally worse, that's all I meant.

Completely agree about forcing them to do or avoid strategies, though governing bodies may disagree!

Jokes aside, it seems that despite occasional marketing/rhetoric from Apple, their platform represents the minimum bound of "openness". It's only open enough to allow further business - e.g. allowing 3rd parties to develop apps in the store (from which they take a cut of proceeds) - rather than being open for the spirit of it, if that makes any sense.

They are a business so that's not exactly something one could fault them for, though.

Re: Undocumented arm64 ISA extension present on the Apple M1

#55

Post by ardy42 »

mhh__ wrote: post #12
whatshisface wrote: post #10

Earlier quoted context omitted.

> The fact that they can be like this is really proof that their market position is much stronger than most HNers seem to think it is. Elsewhere on the HN front page is a computer made with a Russian internal CPU. The CPU has a custom ISA based on x86, and isn't open. The documentation is poor, and nobody has the source code for the compiler. It's also about 5 years behind the state of the art in x86. How can a produ…

The Russian CPU isn't surviving in a market

> The Russian CPU isn't surviving in a market

How so?

It's actually not that different from Apple Silicon when you think about it.

Apple Silicon: you only get it when you buy an iPhone, iPad, ARM Mac, etc. in the Smartphone or PC market; and it enables features that make those devices competitive.

Russian Elbrus: you only get it when you buy some Russian military hardware in the defense market; and it enables features that make those devices competitive.

Re: Undocumented arm64 ISA extension present on the Apple M1

#56

Post by klelatti »

api wrote: post #28
sharken wrote: post #22

Earlier quoted context omitted.

As someone who was actually thinking about getting the M1 based on the great performance and battery life, but without any actual use for it, I can see what you mean. But the lack of openness is enough to stop those ideas, a new Surface laptop or next generation AMD mobile is much more useful. I just hope that a battery life breakthrough is on the horizon from AMD or Intel.

Process node is a large part of it. Fab a Ryzen at 5nm and it will at least be in the ballpark, though X64 decode complexity makes it hard to completely close the gap. There is also nothing stopping someone else from matching or beating M1 performance with another ARM64 core or RISC-V. Both of those have simple easy to parallelize decoders. It will be done if there is demand. AMD, Marvell, Qualcomm, and Intel all hav…

I think you have to look beyond 'technical' ability and factor in commercial incentives: like who would be buying these CPUs and how many? Zero chance of an AMD or Intel ARM core like this in the near future. Marvell have pulled out of the Arm server market IIRC. Qualcomm a possibility but they have underwhelmed in the past.

Nvidia would be my favourite post the Arm acquisition but they probably have their eye on other markets.

Re: Undocumented arm64 ISA extension present on the Apple M1

#57

Post by Someone »

rwmj wrote: post #46
ac29 wrote: post #38

Earlier quoted context omitted.

> How are they expecting that people will use these new instructions? Only through Apple-supplied closed source compilers and libraries? This sounds right. Forcing people to use Apple supplied and supported libraries allows Apple to make major changes in hardware without breaking compatibility (there are always edge cases, though).

If the compiler generates these instructions, won't old binaries break if Apple later make changes in the hardware? (For shared libraries it would be "ok" because the old binary could use the new library, as long as Apple didn't also break the ABI).

The public compiler wouldn’t generate them, or only generate them when compiling with a special flag.

Re: Undocumented arm64 ISA extension present on the Apple M1

#58

Post by emteycz »

_underfl0w_ wrote: post #54
emteycz wrote: post #40

Earlier quoted context omitted.

Eh, what ? What malicious actors? What sufficient justification, and justification of what and to whom? What could be worse? What could be more anticompetitive, and competing with what exactly? I said nothing like this, your "equivalents" are from an entirely different world. I said we should be happy Apple decided to open their platform - because they didn't have to, at all. It's entirely their right to not open any…

Meh, nothing serious, just that the "it could be worse" line of thinking can be a little dangerous if broadly applied since it could always be at least marginally worse, that's all I meant. Completely agree about forcing them to do or avoid strategies, though governing bodies may disagree! Jokes aside, it seems that despite occasional marketing/rhetoric from Apple, their platform represents the minimum bound of "open…

Yes, what I am saying is that we can't fault them for being a business. We should be looking for our open computing platform elsewhere - I think there is more than enough options. If a supposedly "open" platform wasn't open then that would be bad, but Apple is about something different - offering a premium vertically integrated product for people that don't even know what a CPU or OS is. If they were forced to open their platform it is very much possible there wouldn't be any Apple platform at all, and I don't want that kind of world.

> though governing bodies may disagree!

That's why I am reacting so strongly. If people begin to apply your thinking too broadly (e.g. to businesses like Apple) it will lead to governing bodies behaving like that. Let's apply this kind of thinking to platforms that claim to be open.

Re: Undocumented arm64 ISA extension present on the Apple M1

#59

Post by rgovostes »

gcblkjaidfj wrote: post #39
rgovostes wrote: post #25

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…

Apple must support base LLVM functionality because it is the core of their extend-embrace-extinguish strategy. This says nothing that they will extend that offer to their undocumented secret sauce, as you imply.

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 existed.

Re: Undocumented arm64 ISA extension present on the Apple M1

#60

Post by egsmi »

rwmj wrote: post #46
ac29 wrote: post #38

Earlier quoted context omitted.

> How are they expecting that people will use these new instructions? Only through Apple-supplied closed source compilers and libraries? This sounds right. Forcing people to use Apple supplied and supported libraries allows Apple to make major changes in hardware without breaking compatibility (there are always edge cases, though).

If the compiler generates these instructions, won't old binaries break if Apple later make changes in the hardware? (For shared libraries it would be "ok" because the old binary could use the new library, as long as Apple didn't also break the ABI).

In theory that’s what bitcode protects against.

Today, that doesn’t save binaries not distributed through the store or ones you compiled yourself via other compiler chains.

It is possible to change that. One could even imagine it as part of the loading procedure.

https://lowlevelbits.org/bitcode-demystified/

Post reply on HN