141–150 of 202 posts
I hate Apple for that. They very often use non-standard tech and we'll end up with Apple proprietary processors instead of the standard stuff x64/ARM64.
I see undocumented instruction extensions as a special case of private API: it buys Apple the freedom to change the underlying implementation in the future. As long as done in a manner that is not anticompetitive, I don't see the problem.
Like private APIs, they ultimately transfer power from consumers to Apple. They surely do have documentation internally, they just don’t want to commit to anything.
Is it inherently wrong for a hardware vendor to make a high-level C api the interface?
Earlier quoted context omitted.
To highlight where we're disconnected, my phrase: "cases that use these instructions will be compiled by Xcode" does not imply that Xcode comes equipped to translate user-provided code into these instructions; however, by use of Apple frameworks, Xcode could still regardless output binaries that use these instructions, without needing to provide us any manner to do so ourselves. I suspect most people aren't compiling…
Thanks for your explanation, I didn't take this into account
Earlier quoted context omitted.
From what I can tell reading this: the Accelerate framework from Apple seems to use custom instructions possibly unique to the M1 chip but potentially similar to Intel AMX. Accelerate is, as I sort of understand it- a way to do advanced math in a very quick / power efficient way. It is touted as deeply integrated with Apple processors from the day it launched and (I think) even recommended to be used over SIMD and th…
Say hello to Function Multi-versioning [0]. You tell the compiler to build a version for each march defined in the attribute. When that function is called a quick CPU check (via CPUID) is performed and if there's a version specific to the current CPU that will run instead of the more general implementation. ICC has supported this for a long time and it's widely used in Intel's MKL. LLVM also supports FMV but uses a s…
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…
Once you're done frolicking in the garden, tech outside can use some help. ICS and CUPS are a testament to how strange Apple is as a company. See also: libimobiledevice.org I hold that they're hands-down the worst company at marketing.
I don't understand the significance of this. Could someone who does add some context?
Like Intel, Apple has chosen to add some instructions to the processor which accelerate certain operations (in this case matrix operations). Unlike Intel, Apple has not yet chosen to actually document the M1 architecture. This is where a vertically integrated company like Apple (or IBM back in the day) can leverage "inside knowledge" about their chips to achieve performance that is not readily comparable (or reproduc…
TFA points out that this Apple AMX is similar to the existing Intel AMX, even (confusingly) using the same name.
Earlier quoted context omitted.
Like Intel, Apple has chosen to add some instructions to the processor which accelerate certain operations (in this case matrix operations). Unlike Intel, Apple has not yet chosen to actually document the M1 architecture. This is where a vertically integrated company like Apple (or IBM back in the day) can leverage "inside knowledge" about their chips to achieve performance that is not readily comparable (or reproduc…
"IBM vs Memorex": Memorex created a disk drive that was plug compatible with IBM mainframes. IBM of course refused to support any system that dared to use these drives. And sued Memorex for copying their design. Memorex counter-sued. This all forced the court to rule that reverse engineering was permissible. https://www.computerhistory.org/storageengine/memorex-introd...
I see undocumented instruction extensions as a special case of private API: it buys Apple the freedom to change the underlying implementation in the future. As long as done in a manner that is not anticompetitive, I don't see the problem.
After four different CPU ISA's (68000, powerpc, x86, ARM) an Apple ISA is next.
There's a tidy mathematical progression in Apple CPU architectures. 6502 (Apple 1,2,3): 1976 68k (Mac): 1984 (+8 years) PPC: 1994 (+10 years) x86: 2006 (+12 years) ARM: 2020 (+14 years) If the trend continues, we will see Apple's next architecture in 2036.
Earlier quoted context omitted.
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.