Apple is the one company out there that does not need to care one way or the other what Nvidia does. ARM was created as a joint effort between Acorn, VLSI, and Apple. Apple has a perpetual license and can basically do whatever they want with the architecture for their own products. The strangest thing about this is trying to imagine a use case where Risc-V makes sense but a low-end ARM chip does not...
When Apple bought NeXt, they also bought its agnostic attitude towards architectures. macOS compiled on Intel chips for years in secret before they publicly unveiled the transition. I'm pretty sure iOS compiled on Intel since its earliest days, and macOS ran on ARM for close to a decade before the current transition.
All that to say that Apple is able and willing to cross-compile for long-term strategic reasons. I don't expect anything particular to come of this for a decade at least; if anything its probably just keeping abreast of developments in the RISC-V ecosystem that could be useful on their own chips.
Apple gave everyone a copy of OPENSTEP 4.2 at an event, then released a few developer previews of Rhapsody for Intel hardware. I don’t think it was too shocking that OS X was being built on Intel hardware no matter what the story from Apple is.
May be they have we do not have details though. But even if they have the original you are nit sure one day you may have a patent or later development that you need. And all architecture has bottleneck. All.
One day may hear qm even.
If they are not studying they are stupid like Kodak (which basically invent and lead in digital photography).
What the real surprise is apple cannot package well something invented somewhere and move the pain point out (like iphone, like low end computing of m1 etc).
I wonder -- if Nvidia takes ARM in a direction they don't like (doesn't match Apple workloads -- maybe a gaming focus or something), in the very least Apple will stop benefiting from being part of that ecosystem. In that case, they might as well go to Risc-V, right? It is at least hypothetically possible that the community will produce something they find useful, and being on Risc-V would ease integration.
Apple kicked Nvidia out of its product line a long while ago, after Nvidia tried to collect licensing fees on every iPhone sales for their GPU IP. They launched their legal actions with Samsung first, and it backfired spectacularly. [1]
I believe there are some higher ups who would not welcome at all a Nvidia takeover of ARM, and that's putting aside potential increases of licensing fees, or other actions.
I'm sure they have a plan B in place should that happen. Whether those hiring are it or not, I don't know.
They already have an ARM license and the vast majority of ARM processors in existence are Cortex-M class microprocessors (i.e ARM pretty much owns the target market for RISC-V at the moment).
This means they're not looking at RISC-V for any technical reason (for which Cortex-Ms generally outperform RISC-V) but rather for strategic reasons (i.e. dependency on ARM/Nvidia).
Things you do for strategic reasons you tend to do in a half-arsed way. You know that you're only porting to an architecture to act as a negotiating lever, so you assign a small team of cheap engineers to the task.
They already have a ton of those. There are 12 or so coprocessors in the M1, some of them multicore. Most are Apple's own small 64-bit core design (Chinook), but there are 3 or 4 Cortex-M3s too.
Apple have proven they can change architecture on a whim now. Would be interesting if an Apple RISC-V gave them 20%+ more performance/better SIMD design/smaller die size? What do people think of the likely reasons, isn’t ARM good enough and then it’s about the actual implementation to deliver the performance. Is RISC-V inherently better?
RISC-V isn't an architecture you'd want to run a computer on. They'd want to use it for various embedded processors that are either on die or off die. For example adding a RISC-V based co-processor on to an apple silicon chip.
Alternatively they could also be doing it as a backstop in case ARM gets bought by NVidia and NVidia tries to shut them out. They can threaten RISC-V against them.
There was an article on HN where someone called RISC-V a bit too RISCy. ARM has instructions that combine things that are commonly combined, which increases code density and requires fewer instruction decoders (as well as possibly instruction combine logic if there are micro/macro-ops) for the same performance.
RISC-V had better code density than anything a few years back. Cant say how it competes with the latest though.
It does have some weird instruction encodings though. They intended it to be fixed 32bit instructions, but then that changed and its let with some odd things because of it. I'd like to see immediate data come after the instruction.
In 32 bit, Thumb2 aka ARMv7 has slightly better code density than RISC-V.
In 64 bit, RISC-V has by far the most dense code compared to ARM, x86, POWER or any other widely used 64 bit ISA.
ARM dropped their 2-byte encodings going from 32 to 64 bit, which hurts them a lot. i386/i686 was reasonably dense, but amd64 needs a lot of REX prefix bytes which increases the code size.
RISC-V was always designed to allow for variable instruction lengths. The base instruction set is fixed-length 32 bit -- 30 bit really, as the two LSBs are always '11'. Values of the two LSBs other than '11' were always intended for 16 bit instructions.
Encodings with all 1s in the "major opcode" field are reserved to indicate future instructions longer than 32 bits. It's very likely that the first such instructions defined will be 48 bit instructions with 32 bit immediate data. However until now, RISC-V core designers have been strongly resisting adding instructions longer than 32 bits even though software people want them. It might look cleaner to load a 32 bit literal using a single 48 bit instruction instead of two 32 bit instructions, but it might not make for a faster computer.
That is an implementation detail of the processor hardware, and not of the instruction set, unless you have some details on why RISC-V cannot be implemented this way.
It is absolutely a property of the instruction set. In the meantime, I remembered two prominent examples: ARM has compare-and-branch instructions and load / store with offset and scaling instructions. There is no way to get the benefits of less decoding and possibly combining (possibly also reduced register pressure and shorter dependency chains - no intermediate address calculations or comparison status registers) without changing the instruction set.
Thanks for the correction. RISC-V actually seems to have the most efficient way to do conditional branches of all common ISAs (according to its instruction set reference document, heh).
But about the more complex ARM load/store opcodes, the point stands that instruction fusion does not simplify decoding or increase code density the way a pre-fused instruction does.
"pre-fused" instructions use up a lot of opcode space that might be better used for other things.
Complex addressing modes help code size if you've got just a single access to an array element in some straight line code, but they're seldom needed in loops because most of the calculation is best moved outside of the loop leaving just a simple pointer increment inside the loop.
No, there are certainly ISA related performance factors.
RISC-V compressed instructions are easier to decode than x86 but you still need to detect boundaries and mux instructions to their proper lanes. And if you don't you have problems with i-cache pressure.
In theory instruction fusion can do a lot to increase backend instruction density. But to equal other ISAs RISC-V have to be fusing triplets instead of just pairs and that's a quadratically harder problem.
It's not the end of the world but I don't think it's an accident that x86, on of the simplest CISC ISAs, and ARM, one of the most complex RISC ISAs, ended up being dominant.
Not knowledgeable in the area, but from what I gather RISC-V is not as performant as ARM or Intel/AMD. Yes it can run at faster clock speeds due to its simplicity, but the flip side is that it requires more instructions (and more memory and more cache) to do the same job.
Besides, there don't seem to be good multicore architectures for RISC-V, that's probably the biggest show stopper in this age of multicore computing.
I don’t think lack of good multicore designs would be a showstopper for Apple. They have a team that could change that, and can afford to spend a few billions on doing it.
> but the flip side is that it requires more instructions (and more memory and more cache) to do the same job.
The opposite is true. RISC-V has a compressed-instructions extension that makes its code density competitive with x86, ARM64 has nothing like that. Add the earlier-mentioned improvements due to it being a clean, from-scratch redesign and a 20% improvement in performance per watt given similar process node and microarchitecture is very much in the ballpark.
The compressed instructions are not fixed length, so decoding in parallel is severely restricted. No high performance RISC-V machine would use that extension.
They are not fixed length (usual instructions are 4 bytes, compressed are 2), but iirc you can easily tell the length using a single bit in the opcode, so it shouldn’t be that bad. It’s much closer to fixed-length than real variable-length, like with x86.
Regardless, any amount of variability restricts parallelism. You can’t split the instruction stream ahead of time into equal portions to hand to many separate decoding units.
Finding out the insn length is a trivial part of decode, unlike in other architectures. If x86 can profitably use "separate decoding units", RV+C will be able to do it to a far greater extent.
With x86, the decoding is SERIAL. You must manually inspect every single byte to see how many are chained together for a particular instruction (from 1 to 15). With RISC-V compressed, there are only two instruction lengths and the beginning of the instruction tags how long it is.
To my knowledge, all the most high-performance RISC-V cores use compressed instructions.
While decoding a given x86 instruction is serial, since about 2000 metadata has been added to the L1 instruction cache indicating which bytes start an instruction. So you can start decoding multiple instructions in parallel.
Doing the same might be useful on a very wide RISC-V decoder. Not needed for 3 or 4 wide though. This is not very expensive, needing only 1 bit per 16 bits of instruction cache data (6.25% overhead), as RISC-V instructions can only start on 2 byte boundaries. This is quite small compared to the 25% to 30% code size you typically save from using both 2 and 4 byte instructions (30% to 50% more instructions in a cache of fixed size).
x86 also uses cache of the micro-ops generated from each instruction, to avoid decoding recently-used instructions at all. That's completely unnecessary with simple instruction encodings such as RISC-V.
I assume you’re talking about HAT (head on tails).
The only way to mark in cache is to analyze the incoming streams which still uses significant power and can itself be bottlenecked. As I recall, there’s also occasional waste space on x85 because there’s so many length options.
With RISC-V, chunks parse faster because you can skip (eg) 512 bytes and I believe only the last two bytes need to be inspected to ensure it’s sliced and potentially padded correctly. At that point, I don’t know that any other scheme is needed.
All the fast ARMv8 implementations use uop cache and fast RISC-V implementations will do the same as they gain an even bigger advantage.
> The opposite is true. RISC-V has a compressed-instructions extension that makes its code density competitive with x86, ARM64 has nothing like that.
Earlier Arm versions had compressed instructions (Thumb) but ARM64 dispensed with it for (likely) performance reasons.
> earlier-mentioned improvements due to it being a clean, from-scratch redesign
RISC-V appeared in 2010 and ARM64 which was a complete redesign was announced in 2011
> 20% improvement in performance per watt
Citation?
Reality is that there isn't a RISC-V core you can buy today with the performance of the leading Arm designed cores. Apple could probably architect one but no evidence that RISC-V would give better performance for application cores.
> Reality is that there isn't a RISC-V core you can buy today with the performance of the leading Arm designed cores
There's plenty of ARM cores in other performance classes. It's easy to compare like for like and see what the gain is (in area and power) for similarly-fabbed and similarly-architected chips.
> Earlier Arm versions had compressed instructions (Thumb) but ARM64 dispensed with it for (likely) performance reasons.
That's apples and oranges. To use thumb, you have to switch modes on the chip. You can't mix and match them and I think you can't even have both types in flight at the same time (I might be wrong there).
Each RISC-V compressed instruction is tagged as a short instruction, so no mode switching is needed (though the total number of possible compressed instructions is reduced as a result of the tag).
Compressed instructions have a full-sized counterpart that they (theoretically) expand into, so once you get past the decoder, there is only one instruction type.
This is also interesting in how it affects fused instructions. A lot of people say that instructions X and Y could be fused into instruction Z instead, but if X and Y have 16-bit versions, then you basically get the same length as the 32-bit instruction Z.
Cache pressure is interesting too. x86 is something like 15% more dense than ARMv8. This matters because cache size matters for power, complexity, and cycles. Even without fused instructions and other "necessary optimizations", comparisons show RISC-V code to be around 15% more dense than x86. This means that RISC-V effectively holds around 30-35% more instructions in the same sized I-Cache. This means that 24kb I-Cache in RISC-V would have about the same hit rate as 32kb of I-Cache in ARMv8 (assuming equally accurate predictors and prefetchers). Alternatively, someone could implement that same 128kb and enjoy a higher hit rate and gain throughput by avoiding reaching out to L2 cache (which is 5-10x slower).
We may not know the absolute performance limit of RISC-V yet, but these kinds of details seem to indicate that the limits may well be higher than ARMv8/9.
My point was that Arm was completely familiar with the concept and took a conscious decision not to include it in Arm64. I am absolutely certain that they would have tested various approaches before coming to this decision.
I agree 100% that there are interesting pros and cons from a performance perspective but you have no actual evidence that it gives performance gains anywhere near the numbers being quoted.
I love RISC-V for many reasons but prefer to have debates grounded in evidence on things like performance.
> My point was that Arm was completely familiar with the concept and took a conscious decision not to include it in Arm64. I am absolutely certain that they would have tested various approaches before coming to this decision.
I don't think there is any evidence to back up this assertion.
A major goal was the ability to run both 32-bit and 64-bit code on the same machine. A requirement for this is a more unified decoder. A decoder that uses variable instruction length is a very different design.
Even if it were more performant, it would likely have not been considered due to other design considerations.
Sure Arm didn’t test alternative approaches before launching a brand new 64 bit architecture. Sounds entirely reasonable. (Actually I have a video somewhere of Richard Grisenthwaite discussing this precise decision).
And Aarch32 compatibility made it impossible to design a variable width decoder for Arm64. Of course.
You’re making performance claims on the basis of a back of an envelope analysis with no actual evidence to back it up. As I said RISC-V is great but claims like this need to be backed up with actual evidence.
If backward compatibility is king, the only analysis needed would be "dual decoders is too complex".
There seems to be a conceit here where ARM designers must have made all the right choices and anyone who disagrees is just wrong. Even if some analysis was done, that doesn't mean everything is always considered or that the tradeoffs made are the best ones.
If you have a link, I'd love to watch.
In any case, Intel is using the SiFive P550 for their upcoming Horse Creek platform. The P550 beats A75 in spec power for both float and int performance while using less than half of the die area (I'm more dubious on that last claim because I'm not completely sold on feature parity). Their stated performance actually puts P550 more in line with A76 for performance. At 8.65/GHz, that's close to i9-10900K at 11.08/GHz though far from A14 at 21.1/GHz (those numbers from Anandtech).
That's plenty fast enough to show that the RISCV architecture choices performs well. If they are accurate about the die savings, that's undoubtedly a huge boost in performance per watt too.
> If backward compatibility is king, the only analysis needed would be "dual decoders is too complex".
So AArch32 has a variable width decoder but it was too complex to build one into AArch64. That makes no sense at all.
I'm making no claims at all that Arm made the right choices - just that they actually made a choice and it's very unlikely they would have left huge amounts of performance on the table.
Rather that if you're going to make claims for RISC-V materially exceeding Arm performance you need to have some evidence beyond back of an envelope cache size analyses to back it up.
And sorry a copy pasted SiFive press release from Ars with some odd claims on die area doesn't count as evidence.
I don't have any skin in this competition and like RISC-V a lot. I just don't like these spurious claims like the 20% in the thread above.
> So AArch32 has a variable width decoder but it was too complex to build one into AArch64. That makes no sense at all.
This isn’t true. They had a MODAL decoder. It either grabbed 4 bytes or 2 bytes, but never both intermixed. This modal switch was actually the big reason why performance suffered so much with thumb. Such a switch means in effect that you just treat thumb as additional 32-bit addressing modes where the first 16 bits are don’t cares (and optimize to turn that half off in thumb mode).
Intermixed instruction lengths require looking at 16-bit chunks and deciding if they stand alone or if they belong together. It also causes a less dramatic multiple decoder issue where you can accidentally cut instructions apart in the middle and send half to two different decoders.
“Nobody ever got fired for choosing IBM.” CST looked to have huge performance gains, but when AMD actually bet everything on it, they nearly went bankrupt before they could turn things around.
ARM either had a solid delivery of their new ISA in 2011, or MIPS 64 was going to kill them. You may not remember, but at that time Google had first-class support for MIPS in Android and Apple was rumored to be in talks to buy MIPS outright.
Betting their tenuous dominant market share on risky propositions would be a fool’s errand —- doubly so for a soft IP company. It would also give a talking point to Intel that ARM was moving in their direction as proof x86 was a real competitor.
Instruction size advantages aren’t “back of the envelope”. There are papers on the topic if you care to look. Those papers compare real world instruction counts in non-trivial, real world software. The cache comparison is very real in those applications. The effects of increasing cache size are well studied and well known. You’re arguing that we don’t really know if gravity works the same on planets in other solar systems.
Sure, marketing copy isn’t everything. Intel’s not stupid and I’d say their engineers are easily some of the best. They could have gone with ARM any time they liked (they used to design ARM chips). They could have chosen one of several other designs or decided to wait for another generation. I may not trust their marketing copy completely, but I doubt Intel is just looking at marketing copy. I doubt Intel is throwing doubt about the future of x86 into the mix over a huge nothing.
Uhhh .. while overall I agree more with you and less with klelatti, you appear to have missed Thumb2, introduced in 2003.
Original Thumb was 16 bit opcodes only, and you could switch modes in a program between Thumb mode and ARM mode but not mix 16 and 32 bit instructions together.
With Thumb2, 32 bit opcodes (completely different to original ARM opcodes) were added to the original Thumb 16 bit opcodes, and you can freely intermix them, just as you can with RISC-V with the C extension.
With ARMv7 Thumb2 is the standard execution mode used on iPhones and Android and so forth. While ARM's Cortex-A application processors continue to implement original ARM mode, the Cortex-M series is Thumb2 only (except the M0(+), which is Thumb1 plus just a couple of 32 bit instructions).
I'm personally surprised that ARM dropped 16 bit opcodes in their 64 bit ISA -- I was right from when I first read the manual in 2012. It hurts code density a lot. They pretty much managed to match x86_64 and maybe they thought that was the only competition they would have and it was good enough.
It's true that fixed length instructions simplifies very wide decoders. But ARM has not after ten years built a core with a very wide decoder. Only Apple has. And having two lengths doesn't hurt much, especially when you can tell which length you have from examining just a couple of bits in the instruction (two bits in RISC-V, three bits in Thumb2). It's certainly much much easier than x86 where you have to decode a potentially unlimited number of prefix bytes, several opcode bytes, AND a possible modrm byte just to figure out how long the instruction is.
Even x86 is a solved problem. For cold code you have to do it the hard way, but for frequently executed code in loops or common subroutines you can just add a few extra bits to each byte (or block) in the instruction cache storing the length of each instruction calculated the last time it was executed. As instructions are limited to 15 bytes, in the simplest (but most wasteful) implementation you need to add 4 bits to each byte indicating the length of the instruction that starts there. But adding a single bit to each byte indicating whether an instruction starts there would do the job too.
Solved problem, basically.
That extra bit makes the instruction cache 12.5% bigger, but this is more than made up for by the 25% to 30% code size reduction from having 16 bit instructions available.
And with only two instruction lengths it's probably not even necessary.
The development of A64 took four years. Arm was completely familiar with 16 bit opcodes having used them in thumb for years. There would have been extensive testing of the impact of various ISA decisions - including use of 16 bit opcodes - in the course of that development. But it’s obviously possible to prove that they made a major mistake and left significant performance on the table in a couple of paragraphs in a HN comment!
Sorry, yet again there is no current real world evidence that RISC-V can outperform Arm64 by the 20% quoted in the parent comment. And with that I'm done!
And here we again have the assertion that ARM engineers think very hard and therefore never make mistakes.
Do you think Intel engineers don't think very hard? Oops, Pentium 4. Oops Itanium. And that was after Pentium Pro wiped the floor with DEC, Sun, MIPS and the rest.
Rather its vanishingly unlikely they would discard an ISA feature that was one of the reasons for Arm's success (Thumb was key in ARM7TDMI getting into Nokia etc) casually and without a great deal of analysis of real world code.
And there is no evidence whatsoever of an advantage of the order of 20% that the original comment stated.
Pointing to Intel's errors (the disasters of iAPX432 and Itanium are probably more pertinent) really just highlights how consistently Arm have got ISA design right over the years.
ARM have got a long list of discarded or ignored technologies too.
They've had several attempts at SIMD, and even when they did SVE it turned out that the "Scalable" didn't extend down to microcontrollers like RISC-V's V extension does and they've had to introduce the slightly different and incompatible MVE as well to cover that.
It will be interesting to see what happens in a few years when some applications start to want vector registers longer than 4096 bits, the upper limit by design of SVE's scalability.
And then there are things such as Jazelle and T2EE.
I firmly believe -- and have since it was announced in 2012 -- that the fixed length nature of aarch64 will eventually prove to be a mistake. Code density is important.
They could do a mode like Thumb in the ARM7TDMI (which I have a ton of experience with), but it was Thumb2 in the Cortex series which really propelled ARM to their current heights. There is no room in the aarch64 encoding to do a Thumb2. It would need an entirely new ISA encoding.
I think what probably happened is ARM managed to roughly match the (pretty awful) code density of x86_64 with a fixed length encoding and decided that was good enough as x86_64 was the only competition they were going to face in the 64 bit space.
I believe that if you’re going to accuse someone of making a huge mistake - especially someone with a lot more experience - then you’d better have some solid evidence to back it up.
You may think and believe these things but you still have no actual evidence for these or for the performance claims being made in this thread.
> Besides, there don't seem to be good multicore architectures for RISC-V, that's probably the biggest show stopper in this age of multicore computing.
That's just a matter of investment into the architecture rather than an intrinsic characteristic of the instruction set. There were no good x86 or ARM architectures until various companies decided to make them happen.
No, it's simply that RISC-V is relatively new, we've seen a bunch of small slower cores come out first, they're easier and quicker to design, the bigger faster ones are coming they just take more time to design
Bigger and faster cores are also expected to include extensions that are yet to be standardized, so waiting is absolutely the right move. There are draft architectures (including multiple versions of the openly-available Berkeley Out of Order Machine "BOOM") that are expected to have quite compelling results once fabbed.
The most important of those extensions will all be ratified as part of the RVA22 profile before the end of the year -- including Vector, Bitmanip, Cache control, Scalar crypto, and I think possibly pointer masking (a big big security thing).
A number of companies will already have chips designed and ready to go using draft versions of those extensions. Any minor changes during the public review period will be able to be incorporated very quickly, with chips taping out possibly before New Year.
The time to hire programmers to write the software is well before you have chips sitting in the warehouse (or sold in products), not after.
I don't know if you noticed, but ARM also only makes relatively small and slow cores. Apple made something called the "M1" which uses ARM's instruction set but isn't small and slow.
If Apple turned the M1 team to making a RISC-V core, it would perform just as well.
I think it is too risky at the moment, but in the future anything could happen. RISC-V still has a lot of undefined portions, and because of the way the architectural design is run in the open, it has a committee that is supposed to meet to evaluate proposals about fundamental parts of the architecture, things like memory management, what kind of arithmetic units and floating point units, what kind of instructions are in the instruction sets etc. If you look at the spec there are a lot of basic instructions that are "stubs" - basically they have the instruction names, but no implementation yet - and this is for quite basic parts of the instruction set. Individual RISC-V vendors/manufacturers are "designing their own" and trying to flesh it out, but in many cases they are not standard and may very well be proprietary.
I see this job posting as Apple recognizing that it is early in the game and that they'd really like to "set the direction" of RISC-V in a way that helps them (which only makes sense)
RISC-V is a long game - probably will yield rewards in about 10 years.
But no. You would not want a PC built on RISC-V now (and the question now is "which" RISC-V, the one with memory management or the one without?) - even for embedded boards, for example Beagle Board recently cancelled their BeagleV board https://beaglev.org/blog/2021-07-30-the-future-of-beaglev-co...
not saying that Beagle is leaving Risc-v but most likely they want to use a different instruction set flavour of Risc-v and the current landscape is just too unstable (ie different hardware manufacturers have "different" Risc-v's and software won't run on one kind vs another kind)
> If you look at the spec there are a lot of basic instructions that are "stubs" - basically they have the instruction names, but no implementation yet
The "stub" parts of the spec are for yet-to-be-ratified extensions, there's a number of those in the pipeline including 'V' for vector compute and 'B' for bit manipulation. Those are indeed quite useful for general purpose compute, but one can hope that they'll take far less than 10 years to ratify.
"B" is already well into the 45 day Public Comment stage which is the last step before ratification. "V" is expected to enter that shortly. The "Scalar Crypto" extension entered the Public Comment stage a few days ago.
> in case ARM gets bought by NVidia and NVidia tries to shut them out.
Tries to shut them out how? Apple has a perpetual license to the instruction set, and the implementation is custom, it doesn't use ARMs reference designs.
I assume that perpetual license still has some per-unit or share-of-revenue price?
In which case, Apple might consider switching to RISC-V as a way to save money. Or they might make noises about switching to renegotiate a lower price.
Anandtech's story on what the likely annual royalties are, as a percentage of what the market price for the chip would be:
ARM7/9/11 1.0% - 1.5%
ARM Cortex A-series 1.5% - 2.0%
ARMv8 Based Cortex A-series 2.0% and above
Mali GPU 0.75% - 1.25% added on
Physical IP Package (POP) 0.5% added on
It also mentions the simpler way of saying it. Half of ARM's revenue comes from royalties. So it stands to reason that you could halve your costs if you moved to a royalty free part with the same up-front cost.
> Apple have proven they can change architecture on a whim now.
They might have made it look easy, but switching architectures is still a huge engineering effort which would have taken many, many years of planning and problem solving.
(I'm actually more impressed at how they in-place-migrated every iDevice (like, a billion of them?) to the new APFS filesystem without any hassle to the end user).
I doubt they'd want to pivot right away from ARM64, but I could see them using RISC-V for embedded and controller chips or for low power devices to extend their ecosystem.
Having a RISC-V bench also means they have a backup plan in case something bad happens to the ARM ecosystem.
Ford or GM sell vehicles with engines taylored to customer needs. Given the volumes of chips Apple ships to the end customer, why can't they offer 6 kinds of chip architecture like the choice in colored metal finish? Why does it have to be one chip's ISA one generation at a time?
In your colored car analogy all cars use the same fuel. An Apple computer with a different chip arch will use different software. Yes fat binary are a thing but anyway all different archs should be tested separately. This is a real bummer especially for small dev shops.
My Apple mouse has an ARM processor as does my Apple keyboard. Even some Apple cables have an embedded ARM processor. If they are paying a per chip or per core royalty to ARM then they might just be looking to avoid those costs.
AFAIK they have a perpetual architectural license dating back to their ownership of ARM, so they don't have to pay to re-up their right to develop their own ARM designs, but the do pay a per-chip royalty.
Apple/VLSI didn't get involved until the late 80's / ARM6 (1992) timeframe as they were interested in using it for the Newton -- at the same time Acorn was declining due to UK schools adopting PCs and they spun ARM off in 1990 as a separate company, ARM Holdings (Advanced RISC Machine).
Its no secret that Apple are one of the biggest players when it comes to in-house R&D in the IT world.
So if you were them, would you not put some resources into keeping on top of potentially useful processors such as RISC-V so you have something up your sleeve if you need it for a project ?
Just like they had a skunk works team whose job was to ensure OS X could be compiled to a different processor than what was currently in use. That's why the switch from PowerPC to Intel was able to be done as quickly as it was. Apple funded a team whose work might never have been needed. It would seem the same thing was in place for Intel->ARM as well. So it totally makes sense this is being done.
Well, honestly, Apple already did the hard work years ago when they created OS X itself based on NextStep and used a derivative Mach microkernel. Now, Apple ofc has pushed a lot on top of that but that is platform specific so they call it a hybrid kernel but this is the true legacy of Steve Jobs.
This allowed them to have a pretty tight product line using similar OSs with different user spaces and those needs. It isn't revolutionary on a technical front, that is what all that work was working towards at the colleges that developed them. But it was in fact forward thinking from a product and pricing perspective that a company would make a bold move and incorporate that when we had a lot of PC companies sticking to one arch ride or die style at the time.
I wouldn’t be surprised if they still maintain a fork that runs on PPC as insurance. OS X/macOS has had multi-ISA support internally since it was just a codename project. And likely always will.
I think this is similar to research work in general. Definitely not for everyone but it can be very attractive for certain people.
If I were on the team I’d imagine my motivation would be ensuring huge platform transitions are successful.
- They’ve happened often enough it’s a valuable effort for people (like me) who feel comfortable/at home in a maintainer role.
- All of the ISA changes have been widely praised as smooth transitions.
- The Intel transition was part of what saved Apple.
- All of the software transitions that have been followed through on (i.e. not the several failed “modern OS projects” before OS X) have been similarly successful, if a bit less smooth.
- All of those things together have been a huge factor in Apple’s overall success in the last two decades.
Doing obscure work that may never see the light of day is probably as motivating as your interest in the work itself and how much you value whatever else it (might) support.
I wouldn’t be surprised if this turns out to be for better noise cancellation in AirPods (or something like that). Apple is certain to be using RISC-V somewhere in the sea of ancillary components to any of its platforms…
The wording seems to point to the flexibility of the RISC-V ecosystem being the attraction here.
I've never believed that Apple could do what they want with the Arm ISA because they were a founding shareholder - they will be bound by a license agreement in the same way that other licensees are.
RISC-V gives them the opportunity to add interesting ISA extensions for particular computational workloads.
Edit: Whoever downvoted please tell me why I'm wrong on this - genuinely interested if there is evidence to the contrary!
When we talk about cores on a device we usually think of the application processors that'll be running our own code. But any modern SoC will have tons of other cores. Things like controlling voltage and clock speed, the security enclave, the baseband processor, Apple's matrix co-processor. Since these only run Apple's code switching over the ISA can be done with relatively little fuss compared to the x86/ARM transition. And since each of these is essentially only running a very limited range of firmware they can benefit far more from a extensible, customizable, "only pay for what you use" ISA than the application processor would. I'd also expect Apple to be making their own private extensions for their specific use cases.
I guess more than half ( if not all ) of the comments here haven't actually read the article? It is very specific
> Apple is currently looking for experienced programmers with detailed knowledge of the RISC-V Instruction Set Architecture (ISA) and Arm's Neon vector ISA for its Vector and Numerics Group (VaNG) within its Core Operating Systems group. Apple's VaNG is responsible for developing and improving various embedded subsystems running on iOS, macOS, watchOS, and tvOS.
The Job description even goes on to the task.
>The programmer will work in a team that’s “implementing innovative RISC-V solutions and state of the art routines. This is to support the necessary computation for such things as machine learning, vision algorithms, signal and video processing,” the job description says.
This is specific to RISC-V Vector Extension. And specific to certain type of workload.
121 comments
[ 3.1 ms ] story [ 283 ms ] threadAll that to say that Apple is able and willing to cross-compile for long-term strategic reasons. I don't expect anything particular to come of this for a decade at least; if anything its probably just keeping abreast of developments in the RISC-V ecosystem that could be useful on their own chips.
One day may hear qm even.
If they are not studying they are stupid like Kodak (which basically invent and lead in digital photography).
What the real surprise is apple cannot package well something invented somewhere and move the pain point out (like iphone, like low end computing of m1 etc).
Apple TV … what a surprise failure. And Copland …
Perpetual license doesn’t mean lifetime free use of intelectual property, I guess.
Apple has beaten ARM to production with pretty much every v8 release (though I think neither use most 8.5 or 8.6 features yet).
I believe there are some higher ups who would not welcome at all a Nvidia takeover of ARM, and that's putting aside potential increases of licensing fees, or other actions.
I'm sure they have a plan B in place should that happen. Whether those hiring are it or not, I don't know.
[1] : https://www.reuters.com/article/us-nvidia-samsung-elec-idUSK...
This means they're not looking at RISC-V for any technical reason (for which Cortex-Ms generally outperform RISC-V) but rather for strategic reasons (i.e. dependency on ARM/Nvidia).
This doesn't seem to be that.
Alternatively they could also be doing it as a backstop in case ARM gets bought by NVidia and NVidia tries to shut them out. They can threaten RISC-V against them.
Why not, too risky? Joking aside can anyone explain why this is the case? Is it the classical risc vs cisc debate?
It does have some weird instruction encodings though. They intended it to be fixed 32bit instructions, but then that changed and its let with some odd things because of it. I'd like to see immediate data come after the instruction.
In 64 bit, RISC-V has by far the most dense code compared to ARM, x86, POWER or any other widely used 64 bit ISA.
ARM dropped their 2-byte encodings going from 32 to 64 bit, which hurts them a lot. i386/i686 was reasonably dense, but amd64 needs a lot of REX prefix bytes which increases the code size.
RISC-V was always designed to allow for variable instruction lengths. The base instruction set is fixed-length 32 bit -- 30 bit really, as the two LSBs are always '11'. Values of the two LSBs other than '11' were always intended for 16 bit instructions.
Encodings with all 1s in the "major opcode" field are reserved to indicate future instructions longer than 32 bits. It's very likely that the first such instructions defined will be 48 bit instructions with 32 bit immediate data. However until now, RISC-V core designers have been strongly resisting adding instructions longer than 32 bits even though software people want them. It might look cleaner to load a 32 bit literal using a single 48 bit instruction instead of two 32 bit instructions, but it might not make for a faster computer.
But about the more complex ARM load/store opcodes, the point stands that instruction fusion does not simplify decoding or increase code density the way a pre-fused instruction does.
Complex addressing modes help code size if you've got just a single access to an array element in some straight line code, but they're seldom needed in loops because most of the calculation is best moved outside of the loop leaving just a simple pointer increment inside the loop.
RISC-V compressed instructions are easier to decode than x86 but you still need to detect boundaries and mux instructions to their proper lanes. And if you don't you have problems with i-cache pressure.
In theory instruction fusion can do a lot to increase backend instruction density. But to equal other ISAs RISC-V have to be fusing triplets instead of just pairs and that's a quadratically harder problem.
It's not the end of the world but I don't think it's an accident that x86, on of the simplest CISC ISAs, and ARM, one of the most complex RISC ISAs, ended up being dominant.
Besides, there don't seem to be good multicore architectures for RISC-V, that's probably the biggest show stopper in this age of multicore computing.
The opposite is true. RISC-V has a compressed-instructions extension that makes its code density competitive with x86, ARM64 has nothing like that. Add the earlier-mentioned improvements due to it being a clean, from-scratch redesign and a 20% improvement in performance per watt given similar process node and microarchitecture is very much in the ballpark.
x86 CPUs can barely decode in parallel, partly because the outputs of parallel decoders have to be synced up.
A RISC-V core to rival the M1 wouldn’t use instruction compression.
With x86, the decoding is SERIAL. You must manually inspect every single byte to see how many are chained together for a particular instruction (from 1 to 15). With RISC-V compressed, there are only two instruction lengths and the beginning of the instruction tags how long it is.
To my knowledge, all the most high-performance RISC-V cores use compressed instructions.
Doing the same might be useful on a very wide RISC-V decoder. Not needed for 3 or 4 wide though. This is not very expensive, needing only 1 bit per 16 bits of instruction cache data (6.25% overhead), as RISC-V instructions can only start on 2 byte boundaries. This is quite small compared to the 25% to 30% code size you typically save from using both 2 and 4 byte instructions (30% to 50% more instructions in a cache of fixed size).
x86 also uses cache of the micro-ops generated from each instruction, to avoid decoding recently-used instructions at all. That's completely unnecessary with simple instruction encodings such as RISC-V.
The only way to mark in cache is to analyze the incoming streams which still uses significant power and can itself be bottlenecked. As I recall, there’s also occasional waste space on x85 because there’s so many length options.
With RISC-V, chunks parse faster because you can skip (eg) 512 bytes and I believe only the last two bytes need to be inspected to ensure it’s sliced and potentially padded correctly. At that point, I don’t know that any other scheme is needed.
All the fast ARMv8 implementations use uop cache and fast RISC-V implementations will do the same as they gain an even bigger advantage.
Earlier Arm versions had compressed instructions (Thumb) but ARM64 dispensed with it for (likely) performance reasons.
> earlier-mentioned improvements due to it being a clean, from-scratch redesign
RISC-V appeared in 2010 and ARM64 which was a complete redesign was announced in 2011
> 20% improvement in performance per watt
Citation?
Reality is that there isn't a RISC-V core you can buy today with the performance of the leading Arm designed cores. Apple could probably architect one but no evidence that RISC-V would give better performance for application cores.
There's plenty of ARM cores in other performance classes. It's easy to compare like for like and see what the gain is (in area and power) for similarly-fabbed and similarly-architected chips.
That's apples and oranges. To use thumb, you have to switch modes on the chip. You can't mix and match them and I think you can't even have both types in flight at the same time (I might be wrong there).
Each RISC-V compressed instruction is tagged as a short instruction, so no mode switching is needed (though the total number of possible compressed instructions is reduced as a result of the tag).
Compressed instructions have a full-sized counterpart that they (theoretically) expand into, so once you get past the decoder, there is only one instruction type.
This is also interesting in how it affects fused instructions. A lot of people say that instructions X and Y could be fused into instruction Z instead, but if X and Y have 16-bit versions, then you basically get the same length as the 32-bit instruction Z.
Cache pressure is interesting too. x86 is something like 15% more dense than ARMv8. This matters because cache size matters for power, complexity, and cycles. Even without fused instructions and other "necessary optimizations", comparisons show RISC-V code to be around 15% more dense than x86. This means that RISC-V effectively holds around 30-35% more instructions in the same sized I-Cache. This means that 24kb I-Cache in RISC-V would have about the same hit rate as 32kb of I-Cache in ARMv8 (assuming equally accurate predictors and prefetchers). Alternatively, someone could implement that same 128kb and enjoy a higher hit rate and gain throughput by avoiding reaching out to L2 cache (which is 5-10x slower).
We may not know the absolute performance limit of RISC-V yet, but these kinds of details seem to indicate that the limits may well be higher than ARMv8/9.
I agree 100% that there are interesting pros and cons from a performance perspective but you have no actual evidence that it gives performance gains anywhere near the numbers being quoted.
I love RISC-V for many reasons but prefer to have debates grounded in evidence on things like performance.
I don't think there is any evidence to back up this assertion.
A major goal was the ability to run both 32-bit and 64-bit code on the same machine. A requirement for this is a more unified decoder. A decoder that uses variable instruction length is a very different design.
Even if it were more performant, it would likely have not been considered due to other design considerations.
And Aarch32 compatibility made it impossible to design a variable width decoder for Arm64. Of course.
You’re making performance claims on the basis of a back of an envelope analysis with no actual evidence to back it up. As I said RISC-V is great but claims like this need to be backed up with actual evidence.
There seems to be a conceit here where ARM designers must have made all the right choices and anyone who disagrees is just wrong. Even if some analysis was done, that doesn't mean everything is always considered or that the tradeoffs made are the best ones.
If you have a link, I'd love to watch.
In any case, Intel is using the SiFive P550 for their upcoming Horse Creek platform. The P550 beats A75 in spec power for both float and int performance while using less than half of the die area (I'm more dubious on that last claim because I'm not completely sold on feature parity). Their stated performance actually puts P550 more in line with A76 for performance. At 8.65/GHz, that's close to i9-10900K at 11.08/GHz though far from A14 at 21.1/GHz (those numbers from Anandtech).
That's plenty fast enough to show that the RISCV architecture choices performs well. If they are accurate about the die savings, that's undoubtedly a huge boost in performance per watt too.
https://arstechnica.com/gadgets/2021/06/sifives-brand-new-p5...
https://www.anandtech.com/show/16780/intel-to-create-riscv-d...
So AArch32 has a variable width decoder but it was too complex to build one into AArch64. That makes no sense at all.
I'm making no claims at all that Arm made the right choices - just that they actually made a choice and it's very unlikely they would have left huge amounts of performance on the table.
Rather that if you're going to make claims for RISC-V materially exceeding Arm performance you need to have some evidence beyond back of an envelope cache size analyses to back it up.
And sorry a copy pasted SiFive press release from Ars with some odd claims on die area doesn't count as evidence.
I don't have any skin in this competition and like RISC-V a lot. I just don't like these spurious claims like the 20% in the thread above.
This isn’t true. They had a MODAL decoder. It either grabbed 4 bytes or 2 bytes, but never both intermixed. This modal switch was actually the big reason why performance suffered so much with thumb. Such a switch means in effect that you just treat thumb as additional 32-bit addressing modes where the first 16 bits are don’t cares (and optimize to turn that half off in thumb mode).
Intermixed instruction lengths require looking at 16-bit chunks and deciding if they stand alone or if they belong together. It also causes a less dramatic multiple decoder issue where you can accidentally cut instructions apart in the middle and send half to two different decoders.
“Nobody ever got fired for choosing IBM.” CST looked to have huge performance gains, but when AMD actually bet everything on it, they nearly went bankrupt before they could turn things around.
ARM either had a solid delivery of their new ISA in 2011, or MIPS 64 was going to kill them. You may not remember, but at that time Google had first-class support for MIPS in Android and Apple was rumored to be in talks to buy MIPS outright.
Betting their tenuous dominant market share on risky propositions would be a fool’s errand —- doubly so for a soft IP company. It would also give a talking point to Intel that ARM was moving in their direction as proof x86 was a real competitor.
Instruction size advantages aren’t “back of the envelope”. There are papers on the topic if you care to look. Those papers compare real world instruction counts in non-trivial, real world software. The cache comparison is very real in those applications. The effects of increasing cache size are well studied and well known. You’re arguing that we don’t really know if gravity works the same on planets in other solar systems.
Sure, marketing copy isn’t everything. Intel’s not stupid and I’d say their engineers are easily some of the best. They could have gone with ARM any time they liked (they used to design ARM chips). They could have chosen one of several other designs or decided to wait for another generation. I may not trust their marketing copy completely, but I doubt Intel is just looking at marketing copy. I doubt Intel is throwing doubt about the future of x86 into the mix over a huge nothing.
Original Thumb was 16 bit opcodes only, and you could switch modes in a program between Thumb mode and ARM mode but not mix 16 and 32 bit instructions together.
With Thumb2, 32 bit opcodes (completely different to original ARM opcodes) were added to the original Thumb 16 bit opcodes, and you can freely intermix them, just as you can with RISC-V with the C extension.
With ARMv7 Thumb2 is the standard execution mode used on iPhones and Android and so forth. While ARM's Cortex-A application processors continue to implement original ARM mode, the Cortex-M series is Thumb2 only (except the M0(+), which is Thumb1 plus just a couple of 32 bit instructions).
I'm personally surprised that ARM dropped 16 bit opcodes in their 64 bit ISA -- I was right from when I first read the manual in 2012. It hurts code density a lot. They pretty much managed to match x86_64 and maybe they thought that was the only competition they would have and it was good enough.
It's true that fixed length instructions simplifies very wide decoders. But ARM has not after ten years built a core with a very wide decoder. Only Apple has. And having two lengths doesn't hurt much, especially when you can tell which length you have from examining just a couple of bits in the instruction (two bits in RISC-V, three bits in Thumb2). It's certainly much much easier than x86 where you have to decode a potentially unlimited number of prefix bytes, several opcode bytes, AND a possible modrm byte just to figure out how long the instruction is.
Even x86 is a solved problem. For cold code you have to do it the hard way, but for frequently executed code in loops or common subroutines you can just add a few extra bits to each byte (or block) in the instruction cache storing the length of each instruction calculated the last time it was executed. As instructions are limited to 15 bytes, in the simplest (but most wasteful) implementation you need to add 4 bits to each byte indicating the length of the instruction that starts there. But adding a single bit to each byte indicating whether an instruction starts there would do the job too.
Solved problem, basically.
That extra bit makes the instruction cache 12.5% bigger, but this is more than made up for by the 25% to 30% code size reduction from having 16 bit instructions available.
And with only two instruction lengths it's probably not even necessary.
Sorry, yet again there is no current real world evidence that RISC-V can outperform Arm64 by the 20% quoted in the parent comment. And with that I'm done!
Do you think Intel engineers don't think very hard? Oops, Pentium 4. Oops Itanium. And that was after Pentium Pro wiped the floor with DEC, Sun, MIPS and the rest.
ARM engineers are mortal too.
Rather its vanishingly unlikely they would discard an ISA feature that was one of the reasons for Arm's success (Thumb was key in ARM7TDMI getting into Nokia etc) casually and without a great deal of analysis of real world code.
And there is no evidence whatsoever of an advantage of the order of 20% that the original comment stated.
Pointing to Intel's errors (the disasters of iAPX432 and Itanium are probably more pertinent) really just highlights how consistently Arm have got ISA design right over the years.
They've had several attempts at SIMD, and even when they did SVE it turned out that the "Scalable" didn't extend down to microcontrollers like RISC-V's V extension does and they've had to introduce the slightly different and incompatible MVE as well to cover that.
It will be interesting to see what happens in a few years when some applications start to want vector registers longer than 4096 bits, the upper limit by design of SVE's scalability.
And then there are things such as Jazelle and T2EE.
I firmly believe -- and have since it was announced in 2012 -- that the fixed length nature of aarch64 will eventually prove to be a mistake. Code density is important.
They could do a mode like Thumb in the ARM7TDMI (which I have a ton of experience with), but it was Thumb2 in the Cortex series which really propelled ARM to their current heights. There is no room in the aarch64 encoding to do a Thumb2. It would need an entirely new ISA encoding.
I think what probably happened is ARM managed to roughly match the (pretty awful) code density of x86_64 with a fixed length encoding and decided that was good enough as x86_64 was the only competition they were going to face in the 64 bit space.
Except it's not.
You may think and believe these things but you still have no actual evidence for these or for the performance claims being made in this thread.
> Betting their tenuous dominant market share on risky propositions would be a fool’s errand —- doubly so for a soft IP company.
> It would also give a talking point to Intel that ARM was moving in their direction as proof x86 was a real competitor.
Sorry you're just making stuff up now. I'm happy to engage on a real comparison of the pros and cons of each architecture but this just isn't correct.
That's just a matter of investment into the architecture rather than an intrinsic characteristic of the instruction set. There were no good x86 or ARM architectures until various companies decided to make them happen.
A number of companies will already have chips designed and ready to go using draft versions of those extensions. Any minor changes during the public review period will be able to be incorporated very quickly, with chips taping out possibly before New Year.
The time to hire programmers to write the software is well before you have chips sitting in the warehouse (or sold in products), not after.
If Apple turned the M1 team to making a RISC-V core, it would perform just as well.
I see this job posting as Apple recognizing that it is early in the game and that they'd really like to "set the direction" of RISC-V in a way that helps them (which only makes sense)
RISC-V is a long game - probably will yield rewards in about 10 years.
But no. You would not want a PC built on RISC-V now (and the question now is "which" RISC-V, the one with memory management or the one without?) - even for embedded boards, for example Beagle Board recently cancelled their BeagleV board https://beaglev.org/blog/2021-07-30-the-future-of-beaglev-co...
not saying that Beagle is leaving Risc-v but most likely they want to use a different instruction set flavour of Risc-v and the current landscape is just too unstable (ie different hardware manufacturers have "different" Risc-v's and software won't run on one kind vs another kind)
The "stub" parts of the spec are for yet-to-be-ratified extensions, there's a number of those in the pipeline including 'V' for vector compute and 'B' for bit manipulation. Those are indeed quite useful for general purpose compute, but one can hope that they'll take far less than 10 years to ratify.
"B" is already well into the 45 day Public Comment stage which is the last step before ratification. "V" is expected to enter that shortly. The "Scalar Crypto" extension entered the Public Comment stage a few days ago.
Tries to shut them out how? Apple has a perpetual license to the instruction set, and the implementation is custom, it doesn't use ARMs reference designs.
In which case, Apple might consider switching to RISC-V as a way to save money. Or they might make noises about switching to renegotiate a lower price.
It also mentions the simpler way of saying it. Half of ARM's revenue comes from royalties. So it stands to reason that you could halve your costs if you moved to a royalty free part with the same up-front cost.
Cars?
They might have made it look easy, but switching architectures is still a huge engineering effort which would have taken many, many years of planning and problem solving.
(I'm actually more impressed at how they in-place-migrated every iDevice (like, a billion of them?) to the new APFS filesystem without any hassle to the end user).
Having a RISC-V bench also means they have a backup plan in case something bad happens to the ARM ecosystem.
Apple can pivot architectures, but I don't think they do it lightly.
We were all speculating that the PA Semi acquisition was about faster and cooler PPCs and here we are.
https://en.wikipedia.org/wiki/ARM_architecture#History
Apple/VLSI didn't get involved until the late 80's / ARM6 (1992) timeframe as they were interested in using it for the Newton -- at the same time Acorn was declining due to UK schools adopting PCs and they spun ARM off in 1990 as a separate company, ARM Holdings (Advanced RISC Machine).
So if you were them, would you not put some resources into keeping on top of potentially useful processors such as RISC-V so you have something up your sleeve if you need it for a project ?
This allowed them to have a pretty tight product line using similar OSs with different user spaces and those needs. It isn't revolutionary on a technical front, that is what all that work was working towards at the colleges that developed them. But it was in fact forward thinking from a product and pricing perspective that a company would make a bold move and incorporate that when we had a lot of PC companies sticking to one arch ride or die style at the time.
If I were on the team I’d imagine my motivation would be ensuring huge platform transitions are successful.
- They’ve happened often enough it’s a valuable effort for people (like me) who feel comfortable/at home in a maintainer role.
- All of the ISA changes have been widely praised as smooth transitions.
- The Intel transition was part of what saved Apple.
- All of the software transitions that have been followed through on (i.e. not the several failed “modern OS projects” before OS X) have been similarly successful, if a bit less smooth.
- All of those things together have been a huge factor in Apple’s overall success in the last two decades.
Doing obscure work that may never see the light of day is probably as motivating as your interest in the work itself and how much you value whatever else it (might) support.
Google is easily bigger, and Samsung will stomp both.
Apple's engineering is known to be very conservative. And it's certainly more of quality over quantity spirited.
I knew people who worked in Apple's Shenzhen RnD centre myself.
I've never believed that Apple could do what they want with the Arm ISA because they were a founding shareholder - they will be bound by a license agreement in the same way that other licensees are.
RISC-V gives them the opportunity to add interesting ISA extensions for particular computational workloads.
Edit: Whoever downvoted please tell me why I'm wrong on this - genuinely interested if there is evidence to the contrary!
> Apple is currently looking for experienced programmers with detailed knowledge of the RISC-V Instruction Set Architecture (ISA) and Arm's Neon vector ISA for its Vector and Numerics Group (VaNG) within its Core Operating Systems group. Apple's VaNG is responsible for developing and improving various embedded subsystems running on iOS, macOS, watchOS, and tvOS.
The Job description even goes on to the task.
>The programmer will work in a team that’s “implementing innovative RISC-V solutions and state of the art routines. This is to support the necessary computation for such things as machine learning, vision algorithms, signal and video processing,” the job description says.
This is specific to RISC-V Vector Extension. And specific to certain type of workload.
[1]:https://electrek.co/2021/08/20/tesla-dojo-supercomputer-worl...