Undocumented arm64 ISA extension present on the Apple M1
gist.github.com
gist.github.com
>Accelerate provides high-performance, energy-efficient computation on the CPU by leveraging its vector-processing capability. The following Accelerate libraries abstract that capability so that code written for them executes appropriate instructions for the processor available at runtime
Apple can't control random software people download off the Internet.
Is it inherently wrong for a hardware vendor to make a high-level C api the interface?
While AMX could be used for deep learning in a pinch despite the lack of support for common formats like fp16 and int8, I suspect Apple had some other use cases in mind as well. For example, 64-bit float support is expensive and generally useless for ML. However, they are useful (though not necessarily required) in problems such as bundle adjustment that may appear in the context of frameworks like ARKit.
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...
The tradeoff is not likely perceptible to developers since the compiler or runtime will decide if the net is small enough to run locally or whether it should be dispatched to the dedicated device (again, like L1 access for the majority of developers not writing inline assembly) - thus why it's not exposed. They (apple) could also do some very interesting things with it internally such as neural branch prediction and cache eviction based on contextual operations - again outside of the scope of what a developer would have access to.
Intel is doing the same in their upcoming x86 silicon with Intel Advanced Matrix Extension - I would expect this ISA to be heavily inspired by that.
Could someone who does add some context?
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 instructions. That enables the M1 chip to be faster in this case when developers use these instructions in their applications.
^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.
> 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.
"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 framework-provided binary code into their binaries, using static or whatever it's called these days and so I believe those usages will end up reserved for the frameworks — but since someone is certain to try and consider 'the binary output of Xcode' to include any frameworks referenced by it if it supports their point, I'm taking care to cover all possible cases where output of those instructions could occur without a translation phase using LLVM or etc.
There's certainly prior cases of Apple shipping branches of LLVM (most notably adding arm64 support, which took about half a year to merge in upstream), but the mere existence of these instructions is little evidence of any branch?
Or more typically the compiler will emit those instructions and everyone gets them for free.
Ninja edit: I’ve not seen how it was achieved until now, but a custom ISA extension isn’t wholly surprising.
Edit 2: as for why this is significant.. I’m not sure it is. It is interesting to know how Accelerate can pull off what it does though. IIRC there are other machine learning frameworks which take advantage of the neural engine- but Accelerate possibly doesn’t- despite having machine learning capabilities.
LLVM also supports FMV but uses a slightly different method to define it in code. IIRC there was an LLVM issue tracking work to support GCC's way of declaring FMV but I don't know if that landed yet.
Since the function's signature is the same between the multiple implementations the caller doesn't need to change of their code to get a free boost from features like AVX2 or these M1 instructions. When an M2 comes out with better vector instructions or something and a new Accelerate framework is released, anyone using the framework get a free performance increase without recompiling anything.
Historically (see IBM vs Memorex) obscuring your interfaces has been a losing proposition in the long term, even while delivering favorable margins in the short term. Unlike Intel which needs to get third parties to write software for their chips, Apple writes their own software and so it means they can hold on to their advantage while third parties (like the author of the post) reverse engineer what is going on.
It will be "historically significant" if Intel adds a feature to their chips in order to stay competitive with this development. The last time they did that was when AMD introduced Opteron. All in all, its basically just a puzzle that people who are interested in how things work get to work on in their spare time.
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...
TFA points out that this Apple AMX is similar to the existing Intel AMX, even (confusingly) using the same name.
Matrix processing comes in useful for AI/ML/CV-type applications. It's something GPUs are generally very good for.
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 product, everything you run is up to us, we won't document it, maybe we'll upstream the compiler, tough shit.
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.
I think it is likely that support for these instructions will be upstreamed to LLVM, and the teams involved in this monumental transition (which was announced like ~50 days ago) simply didn't put it at the highest priority on the list of things that developers need to know to get their apps working on Day 1.
A fair criticism is that some of the more technical documentation, such as on the Mach-O ABI, have disappeared from Apple's developer site, or been relegated to an unsearchable archive[2], so it's very reasonable to be skeptical of ISA extensions ever being documented there.
The developer site has always sucked though, and it seems to me they've declared bankruptcy and are rebuilding it on machine-generated docs and WWDC content for app developers. Occam's razor.
1: https://www.phoronix.com/scan.php?page=news_item&px=MTY0NzE
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, usually results in a “just mark it down as log noise”.
Has it always been this bad?
Simply put, if you want useful doco don't look at the latest version of the language. They literally stripped the useful notes and examples and it's now a straight API print out.
If you use stackoverflow (sarcasm) be prepared to constantly be using older versions of swift and translating them to the latest. Feel free to submit updates to them.
So it does help to understand what changed in the language versions. I think anything past Swift 3 is similar to today. Xcode does help a little telling you what you pasted makes no sense to a degree.
It's a very sad state of affairs I'm afraid.
The second rewrite was when I finally had an apple device, so I thought "I will do everything the apple way" - I used Swift and SpriteKit, and tried to do everything exactly how I thought the Apple people would like.
I then dropped that laptop, and was told it would cost more than the price of the laptop to repair, so I decided to do another rewrite - this time, using my linux laptop.
The experience of writing it in plain documented C, and using libSDL2 for most of the IO was far superior. Writing my own physics engine instead of using the SpriteKit one made the actual gameplay better (because it meant I could easily fudge physics a bit to make it more fun).
Only at the very end of the project did I then go through the painful process of making it happy with xcode, happy to build for iOS, and then finally happy with the Apple review process (including hacking my SDL build to remove bluetooth peripheral support so I didn't need to request unwanted permissions).
I now have an M1 Macbook Air, and I've briefly looked again at doing things the "apple way" (e.g. swiftui) and I'm coming to a similar conclusion.
I am also currently writing an app using SDL on Linux, which I have previously written in SwiftUI and it’s a lot of fun, but it’s just not comparable.
My SwiftUI version runs on the watch, the iPhone the TV and even in widgets with barely any modification. (And with much better fonts!)
The Linux version is fun, but it’s just not comparable in terms of the work the platform is doing for me.
What bothers me most is how their documentation for anything is a massive scrollfest[0], followed by links everywhere, yet the actual documentation still feels sparse enough that I almost exclusively try to just read the source code and make guesses. Rails docs sure aren’t going to win any design awards, but at least I can access everything on a single page![1]
[0] https://developer.apple.com/documentation/swiftui/view
[1] https://api.rubyonrails.org/classes/ActionController/LogSubs...
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.
You can just program using obj compatible objects in Swift if you like.
What’s so bad about it?
Intel will give you 800 pages on how to optimize for their current ISA (AMD will give you 45, but still)
LLVM and GCC are good enough (brilliant, even) for general purpose compilation, but for a (say) supercomputer which is guarded by guns having Intel on the phone can be worth it.
Beyond that, making a claim of a conflict of interest requires more than just "It seems like these words fit and sound right, to me." Because "Microprocessor company writes well optimized code for their microprocessors and sells it" hardly seems like a conflict of interest at all in this case, it literally seems like a company selling a product that goes with their existing product. Absolutely everybody does this, including AMD, IBM, Nvidia, Apple, etc. It is not a "conflict of interest" for Intel to both design a microprocessor and also sell code that works well on it. What might be a conflict of interest is if they said "We have an obligation to release these specifications, but also we can make lots of money off them if if we keep them private despite that existing obligation, so we'll just keep them private." Which is a much stronger claim. (In fact even the infamous "cripple AMD" legal SNAFU over ICC wasn't a conflict of interest, it was brought as an antitrust suit, AFAIK.) It's not like Twilio has a "conflict of interest" when they implement new features in their product portfolio, build them on Twilio's servers, and integrate them with other Twilio products.
In general, Intel is ahead of almost every other vendor when it comes to publicly-available information regarding performance optimization (first and third party), by a landslide.
1: https://www.anandtech.com/show/14859/apple-announces-new-iph...
I'm not sure if Apple plans to ever maintain AMX compatibility across CPU versions...
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.
Their investment in LLVM is very much an attempt to keep reproprietization on the table.
But it should be noted that the GPL violation you refer to was in 1989. Put in context, that was ~16 years before they started investing in LLVM, and they have done so continuously for the past ~15 years.
The JIT stuff they were doing with image filters for Core Image and Core Video and the IDE integration they were doing in Xcode could not be done in GCC at the time regardless of licensing without making massive changes, which would not have been accepted upstream.
GCC at the time was intentionally designed and implemented to make it hard to use parts of it independently, such as just using the parser to make a syntax tree for your IDE to use for highlighting or suggestions, or using the code generator in a JIT.
There had been suggestions and patches to make GCC more modular and separable, but they were rejected because being more modular would make it easier for proprietary software to interact with GCC components.
It was only after LLVM and clang started getting widespread use that GCC became more open to the idea of it becoming more flexible like LLVM.
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.
I wholeheartedly agree with that statement, but you are judging a company based on the actions of another company it acquired 7 years later.
It's not like it was some random startup they acquihired for a couple engineers.
And I assume that Apple has support for these instructions this whole thread is about in their toolchains, so if that's the same version that's in xcode, reproprietization is already happening.
Leaving reproprietization on the table is the whole point of non-copyleft open source.
There were alternatives to LLVM and patches to gcc that achieved the same. Apple option to bring llvm up by investing heavily in it has more to do with the licensing than technical aspects.
Most of Apple's extinguished open source projects are ones they started themselves and then abandoned.
Because printing is just so unsexy in general, and tends to get neglected everywhere.
The vast majority of people are not enamored with technology for technologies sake. These are tools. Does the tool do what I want with the least amount of friction? That’s what they care about.
Also how does Apples stance on one product in any way change the device you are using to post in any way? Are Apple thugs coming to your house destroying non-Apple tech? Of course not!
It always amuses me how Apple can simultaneously be irrelevant due to their market share and also be the greatest threat to open computing by their temerity at daring to have different computing models.
If you don’t like their computing model then don’t use it. Railing that they aren’t supporting your vision lockstep is pretty freaking arrogant.
Their market position is strong because they provide value that people desire. The market is not a zero sum game. Apples mere existence does diminish your computing experience. Indeed Apples existence and continually pushing computing in new areas has benefited everyone in the last 40 years - whether you use Apple or not. Just think where computing would be of the attitude that you were only a real computer user if you assembled it - at the component to board level, not just bolting pre-mad parts to a pre-made case - persisted? People criticized Apple for selling complete computers with the Apple II.
Your complaint isn’t that different.
And that is exactly the point you miss.
You are happy and don't care if Apple is open or not. Good for you.
Some of us are not.
And if you do not care whether Apple is open or not, what does it really matter to you if some of us advocate for more openness and transparency from them? It's important to us.
Everything you want exists already - it’s just not provided by Apple.
Why do you care about what they do?
Reminds me of http://www.sandraandwoo.com/2016/06/09/0793-an-offer-you-can...
Alternatively, try to learn more about it by reverse engineering, which is what this article is all about.
Just because Apple are boiling the frog doesn't make it a good thing.
Hence the term boiling the frog. If everyone bakes their bread like this, and they definitely wish they could, that would be bad.
> Hence the term boiling the frog
Tell that to the frog!
I actually kind of agree with the first part. It would be bad if everyone behaved like them.
However I think the only thing that will cause that to happen is if the government gets involved in regulating what software can be sold.
If you don't like/agree/see value in this persons comment then why are you engaging with them? That's how silly your position sounds.
Now back to the substance of your comment.
>Or maybe different people have different needs and don’t care if every device is “open”.
How could "not open" be a need of someone?
>These are tools. Does the tool do what I want with the least amount of friction? That’s what they care about.
How does an Apple engineer documenting the design add friction in any way to what you're doing?
> Indeed Apples existence and continually pushing computing in new areas has benefited everyone in the last 40 years - whether you use Apple or not.
Apple has helped popularize the smartphone as a consumer device to consume music/media, do light business on (emails, IM, documents, etc) and do a few minor creative tasks digitally such as drawing, music, etc. They do get a lot of credit for that. They have also co-created an application platform for other businesses to sell software. But then they robbed 30% of their sales too - They get negative credit for being so greedy.
Your argument that they have "continually pushed computing" is a bit of a stretch. Give us your best argument/examples/facts.
This should not come as a surprise, it has always been Apple's default stance.
Apple has been, is, and will very likely always be a closed ecosystem.
They might sometimes appear or pretend to be open, but it's essentially good PR/marketing (e.g. stash Unix underneath a closed-source stack, call yourself open source and proceed to lure all the open source devs to the platform).
Apple also had detailed info on their hardware. The Apple II reference manual had schematics, mapped it to the PCB, described what each part did, described 6502 assembly and had an assembly listing of the monitor ROM. The only thing missing to build a copy, I think, was an assembly listing of the Basic interpreter.
The phone book edition of Inside Macintosh also had info on the hardware, but a lot less of it.
https://developer.amd.com/resources/developer-guides-manuals...
They do not ship an assembler though.
Microsoft was taken to court over undocumented APIs in Win 3.x that gave their own software an unfair advantage. This is why the Win32 documentation exists today.
It’s worth noting that Microsoft is still in that position. Apple just isn’t.
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.
Intel has their Lakefield chips which use the same big.LITTLE configuration but their first large release chips will be Alder Lake next year.
My concern is less with Intel and AMD's ability to implement the cores as much as Microsoft's ability to implement a scheduler. They never came to grips with the weirdness of AMD's Bulldozer architecture.
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 have the expertise to do it. Probably TI too if they wanted to reenter the CPU market.
Nvidia would be my favourite post the Arm acquisition but they probably have their eye on other markets.
I’m curious what projects you work on!
If that's not the world you are interested in, what are you even doing owning a Mac? Apple does not try to be all things to all people the way e.g. Microsoft has.
I would like consumers to have at least semblance of freedom. You have to consider that for most consumers, almost everything mentioned in this thread from top to bottom is complete Greek to the average person buying a computer.
This particular question (Documenting stuff), is the cherry on top. The Sundae itself is Apple's locked-in approach to their ecosystem. The result of the Epic squabble is much more important for example, similarly I don't think it's a good thing that Apple can force Stadia to be non-native (If you were a lifelong Apple customer would you know there was any alternative?).
The world is only going to get more technological - thanks to things like the cloud, the Orwells of the future will be writing about technology.
As a final remark, I believe there should be broad but shallow regulation for the whole sector, Apple are just the most obvious example.
Generally no. But it's something that worth an attempt, no matter how clueless the attempt is, something positive may come out of it. Here's an attempt to implement a free and open source standard cell library using the 1-micron process from the 80s.
If they can’t be trusted, they don’t need to add opcodes.
It's similar to how Microsoft doesn't make all APIs on Windows public and uses non-public ones for various reasons--except this is in hardware.
It's possible the undocumented ISA is used to speed up x86 emulation and might be kept secret due to intellectual property concerns or similar.
Why would they? They sell hardware, not really software.
I really wish they (or any one with modern fast CPU and motherboard designs) would sell hardware only bare-bones with no OS or even bootloader, but history shows a mass market won't support that.
I don't know why, but they are already doing it with browsers on iOS: https://docs.house.gov/meetings/JU/JU05/20190716/109793/HHRG...
Are there any WebKit functions that Apple allows Safari to use but that competing browsers are not permitted to use?
WebRTC for videoconferencing, Intelligent Tracking Protection, Fullscreen API
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 .
https://www.statista.com/statistics/382260/segments-share-re....
(within this, you probably want to break out 5/6 of the services revenue and tack it onto iOS, and then treat the remaining 1/6 sliver as applying to the mac).
This is honestly one of the biggest peace-of-mind things for being an apple customer, and it's definitely a big cultural trope within their support network as well. You pay your "union dues" by buying the hardware, and then "you're in". There's no money to be made after that fact, so there are an enormous number of small interactions after that that are fully trustworthy - for example, unlike many internet-ad-revenue companies, you're not worried about being profiled or having your info sold to advertisers. You're also not worried about "product collapse based on shaky revenue streams" - one thing that's always been scary about using various consumer apps is there are a fair number of programs out there that just have really shaky revenue models, so it's scary to commit to them because a lot of them eventually have to pivot, or sell out, or otherwise do something brutal to stay alive. When using some of apple's hardware, you know if it's selling decently, the business is stable and certain rugs won't get pulled out of under you.
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."
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 anything, not write any documentation, or not even allow 3rd party software at all. If you don't like it, don't buy their overpriced premium products - it's not for you. I wouldn't want my own company to be forced to do/not do stuff, so of course I don't wish that upon Apple. There are enough entirely open computing platforms that are VERY cheap to obtain and easy to use, perhaps that would be a better choice for you.
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.
> 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.
It's not about EEE it's about Apple taking this attitude in the first place.
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)
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)
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).
There’s no publicly available compiler, proprietary or not, that produces binaries that use the instructions.
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.
Apple does not provide any support for using directly their undocumented ISA extensions, or their undocumented GPU, NPU etc.
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 raised with.
I also used to use Android, but the "look how many advanced, poorly integrated and under maintained things I can do by myself" concept didn't stay appealing for very long.
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.
- 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).
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.
iOS devices have had a file system users can at least save and retrieve from for years now.
The mobile app landscape has changed from the gold rush early last decade, and I rarely install anybody's. I empathize with the developers still trying to make it there, but its not a user's problem.
The protocols that Apple chooses to promulgate work really well.
Flagship games work really well.
The garden has gotten really big, I can't see the walls anymore but little bad gets in.
Computers do what I want them to, here. They don't do what I want them to do outside of here. For context, I jump into a Windows instance, or routinely put compute instances in the cloud.
1) Not all of us are like that. Admittedly I'm very far in the other camp: I run Linux as a desktop OS, and have done so for most of the past 20 years. For much of that I even ran Linux on Apple hardware (because I really did love their hardware), but a few years ago finally gave up due to the increasing frequency of undocumented things that don't work. But there are many of us (less extreme than I am, who would otherwise be content to run macOS and iOS) who absolutely do not buy in to a world where they don't truly own their devices.
2) There's a pervasive worry around here that Apple's approach will catch on, the end result being that full control over your own hardware and software will be a near impossibility. (Or, you'll be able to have it, but then be denied access to things like streaming media, and government and financial apps, a trade off people shouldn't have to make.) I think that's a very real possibility in the longer term, and I think the end result of that is total surveillance and a world where corporations decide what we're allowed to do with technology. And I think for this reason there can be a bit of hostility toward people such as yourself who are happy in the Apple walled garden and seem unconcerned about the future implications of this kind of computing model.
As an aside, I also reject the idea that it's necessary that the user give up agency over their devices in order to be protected from malware. A walled garden -- no matter how far away the walls are -- is not a requirement to keep bad stuff out.
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 product like this exist? Easy. Russia needs them for military hardware because they're not going to put Intel in their defense radar systems. The manufacturer has a niche to sell to.
Instead of being 5 years behind, Apple's closed and undocumented ISA is 2 years ahead. How much moreso, if the Russian CPU can survive in the market, can they.
The M1 is a CPU for global consumer products.
This is by far the most charitable characterization of this monetization scheme I've seen so far. Some would argue this is actually in place to ensure that purchases go directly through Apple each time (i.e. a one-to-one of customers to hardware purchases), rather than through a cloud provider who may purchase hardware once and allow thousands of customers to access it. c.f. Apple's restrictions on subletting use for no less than a single day per "machine".
0: a very low bar in this case, given the existence of things like Intel Management Engine, but it would be much the same if they insisted on something less justifiable like running all the CPU pins at 12-volt logic levels
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.
They provide a very wide coverage library set that works on all supported platforms optimally. You interact with AMX through those libraries, and direct usage is considered unsupported. Apple may completely change it with the next iteration, where they can just change those libraries and every arm's-length application will get those benefits for free.
Apple sells whole systems. They aren't selling CPUs for third parties, and there is no reason they need to encourage their own proprietary extensions. Indeed, it would be more evil if they were asking people to pepper their own code with this, instead of just using libraries that abstract you from the magic.
As a tiny, tiny vendor in the computing space -- as HN often assures us -- I'm not seeing the great evil many are claiming.
(indeed, of course this is downvoted but I chuckle that another comment implores that Apple is evil because this will lead to code and binaries that only work on Apple devices. Which is quite literally exactly the opposite of what Apple is doing, which is forcing use through optimized libraries, abstracting from their own proprietary extensions. People just love bitching)
How is this different from normal matrix operations?
We've been calculating matrixes for time eternal, but AMX has just recently become a thing. Intel just introduced their own AMX instructions.
I don't see the need for an effort such as a matmul-dedicated instruction-set elsewhere? What's your guess?
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.
That being said, I would really like to see the Mill make it to Silicon - even if it doesn't work in the end, it's much more interesting to me than RISC-V.
I assume RISC-V appeal is because it's open and thus allows people to explore (proprietary) implementations while maintaining compatibility at the ISA level.
If I understand correctly you cannot do this with Mill either.
Their work looks very interesting, but I'm not drawn in writing an fpga implementation or work on a toolchain for it, since I know any success may be impeded by patents
Meaning they can do anything they want on an ARM base, they're already not beholden to any third-party designer or roadmap, which is what hampered them with both PPC and x86 (I'm not old enough to remember the 68k and really know why they moved off of it).
The only reason they'd have to move away from ARM is if the ISA ends up preventing them from doing something, somehow.
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.
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.
This is wrong and detrimental to the whole industry, including users.
Apple would have created a shitty internet if they were in charge at the time.
To be honest, Microsoft did pretty nasty things during their era, but I think that Apple would have been so much worse.
* Metal was launched two years before Vulkan
* Lightning was invented two years before USB-C