23 ms·

Apple M1 foreshadows Rise of RISC-V

• noizejoy 6y ago
  With all the discussion about what the “big trick” is that makes the M1 seem to be such a breakthrough, I can’t help but wonder, if the M1 is more like the iPhone: The sum of a large number of small engineering improvements, coupled with a lot of component integration detail work, topped off by some very shrewd supply chain arrangements. Analogous to the iPhone being foreshadowed by the iPod without most experts believing Apple could make a mobile phone from that, the M1 was foreshadowed by the A1 for mobile devices with many(most?) experts not forecasting how much it could be the base for laptops and desktops. It seems, the M1 includes numerous small engineering advances and the near term lockup of the top of the line fab in the supply chain also reminds me of how Apple had secured exclusivity for some key leading edge iPhone parts (was it the screens?). So the M1 strikes me as the result of something that Apple has the ability to pull off from time to time. And that is rather hard to pull off financially, organizationally and culturally. And it more than makes up for some pretty spectacular tactical mis-steps (I’m looking at you, puck mouse, cube mac, butterfly keyboard). EDIT for typo
  • jolux 6y ago
    The first A-series chip was the A4, because it came out with the iPhone 4.
  • alwillis 6y ago
    So the M1 strikes me as the result of something that Apple has the ability to pull off from time to time. Perhaps you haven't been paying attention? Apple shipped 64-bit ARM processors for the iPhone at least a year before Qualcomm could do it for Android devices. The reaction to the A7 was similar to what we're seeing now with the M1—not possible, there's some trickery going on, etc. Apple is pretty good at this processor transition thing, going from 68k to PowerPC to Intel to ARM. And it more than makes up for some pretty spectacular tactical mis-steps (I’m looking at you, puck mouse, cube mac, butterfly keyboard). Except for the recent keyboard issues, you're literally talking about another era. I wouldn't put the shape of the mouse for the 1998 iMac in the same category as transitioning a $9 billion revenue product line to a radically different processor architecture.
    • dwighttk 6y ago
      > not possible, there's some trickery going on “...and even if they did it, it doesn’t matter” (though I guess not many are saying that about M1)
      • alwillis 6y ago
        Yes—there was a lot of “it won’t matter” talk when the A7 shipped.
    • hajile 6y ago
      > Apple shipped 64-bit ARM processors for the iPhone at least a year before Qualcomm could do it for Android devices. The reaction to the A7 was similar to what we're seeing now with the M1—not possible, there's some trickery going on, etc. That is because it is not possible to ship a top-end design for a new ISA in that amount of time. The more reasonable answer is they had been working on a new core design for some years before. AMD has hinted that their Zen design makes it relatively easy to swap the x86 frontend for an ARM frontend. Apple was considering buying MIPS around that time. I suspect they strong-armed ARM into accepting their ARMv8 proposal because it was good and because Apple buying MIPS would be disastrous for ARM's share price. At that point, it wasn't faster than possible, it was just designing the last part of the chip (or if both frontends were being worked on in tandem, cancelling one of them and focusing everyone on the other). This explains why ARM announced v8 and then took the full 4 years to ship their first low-power core (A53) and even longer to ship their bad first try at a high-performance core (A57 -- with the more baked A72 being superior in almost every way).
    • DonHopkins 6y ago
      Don't forget Apple's first transition from 6502 to 68k. That was pretty bumpy though.
      • alwillis 6y ago
        I was only talking about the Mac, which never used the 6502–that was the Apple II. The Apple IIgs did end up on the 65816.
  • simonh 6y ago
    Apple has used exclusive access to advanced hardware as a differentiator several times. With screens it was Retina. They funded the development and actually owned the manufacturing equipment and leased it to the manufacturing subcontractors. Also in 2008 they secured exclusive access to a then new laser cutting technology that they used to etch detail cuts in the unibody enclosures of their MacBooks, and then iPads. This enables them to mill and then precision cut the device bodies out of single blocks of Aluminium. They’ve also frequently bought small companies to secure exclusive use of their specialist tech, like Anobit for their flash memory controllers, Primesense for the face mapping tech in FaceID, and there are many more. For Apple simply having the best isn’t enough, they want to be the only people with the best.
    • FullyFunctional 6y ago
      They bought Intrinsity as well, leaving us wonder about the fate of Fast14.
    • vizzier 6y ago
      I believe this is the only consumer 5nm chip currently available as well. Ryzen gen 3 is still on 7nm. I'd be interested to see how well general purpose compute on the m1 vs ryzen gen 3 mobile will be.
      • leecb 6y ago
        The Huawei Mate 40 came out two months ago, and uses the Hisilicon Kirin 9000, which is also on TSMC's 5nm. It has about 30% more transistors and a higher clockspeed than the A14.
        • AsyncAwait 6y ago
          AMD has substantially more CPU/Microarch design experience.
        • 1123581321 6y ago
          Would you say that the comparison to the A13 from this article is fair? https://www.notebookcheck.net/HiSilicon-Kirin-9000-Processor-Benchmarks-and-Specs.505389.0.html https://www.notebookcheck.net/HiSilicon-Kirin-9000-Processor...
  • _ph_ 6y ago
    The sum of a large number of small engineering improvements, coupled with a lot of component integration detail work, topped off by some very shrewd supply chain arrangements. I think you precisely have it. There is no single magic reason the M1 is so good, just a lot of things coming together. They start with a better instruction set than x86, have of course the best process available, and perhaps the largest part, they have built up an increadible team over a decade. And they are extremely focussed in what they target. If anything, that is Apples "magic". They are not making a chip which is built in an abstract manner to be sold to random customers. They have exactly their needs in mind and execute towards those. In a sense AMD did that with the chips for the Playstation/XBox. Like the M1 it is basically a SOC. There optimized for great graphics performance. Unfortunately, those chips are not sold separately for building your own PC.
  • deleted 6y ago
    [deleted]
  • gchadwick 6y ago
    > The sum of a large number of small engineering improvements, coupled with a lot of component integration detail work, topped off by some very shrewd supply chain arrangements. I think the vertical integration they have is a major advantage too. I used to work at arm on CPUs. One thing I worked on was memory prefetching which is critical to performance. When designing a prefetcher you can do a better job if you have some understanding or guarantees as to the behaviour of the wider memory system (better yet if you can add prefetching specific functionality to it). The issue I faced is the partners (Samsung, Qualcomm etc) are the ones implementing the SoC and hence controlling the wider memory system. They don't give you detailed specs of how that works, nor is there an method where you can discuss with them appropriate ways to build things to enable better prefetching performance. You end up building something that's hopefully adaptable for multiple scenarios and no one ever gets a chance to do some decent end to end performance tuning. I'm either working with a model of what the memory system might be and Qualcomm/Samsung etc engineers are working with the CPU as a black box trying to tune their side of things to work better. Were we all under one roof I suspect we could easily have got more out of it. You also get requirements based upon targets to hit for some specific IP, rather than requirements around the final product, e.g. silicon area. Generally arm will be keen to keep area increase low or improve performance / area ratio without any huge shocks on overall area. If you're apple you just care about the final end user experience and the potential profit margin. You can run the numbers and realise you can go big on silicon area and get where you want to be. With a multi-company/vendor chain each link is trying to optimise for some number they control, even if that overal has a negative impact on the final product.
    • fluffy87 6y ago
      Nvidia makes arm processors, GPUs and SoCs, so this integration will be good for them if the arm sale is approved.
    • socialdemocrat 6y ago
      Very interesting comment. I mean you see some of the same things with companies like Tesla also pushing vertical integration. A lot of the examples you see are similar to what you talk about. You can cut down on the friction between different parts. I remember an example of software controlling a blinking icon on the dashboard, where this was a 10 minute code change for Tesla but a 2-3 month update cycle for a traditional automaker due to the dashboard hardware coming from a supplier.
  • scottlocklin 6y ago
    I haven't studied it carefully, but it sure looks like 90% of the performance improvement is using a big cache, which is a totally obvious thing to do. Also the big x86 guys have more or less been asleep at the wheel for almost a decade. My go to example: my 2011 x220 sandybridge stinkpad is faster than my 2017 kaby lake mbp. 2005 machines (I dunno, Lakeport?) aren't even in the same ballpark as modern machines. Had that pace continued up to current year, the M1 chip would be a stinker. As it is, AMD is close and could smoke M1 in next generation 5nm chips, restoring order to the universe.
    • CrazyStat 6y ago
      >As it is, AMD is close and could smoke M1 in next generation 5nm chips, restoring order to the universe. Comparing next gen to current gen is a strange way to do things. Apple will also have a next gen M chip.
      • NathanOsullivan 6y ago
        AMD has a public roadmap, and (assuming they execute) their next CPU in 2021 will be 5nm. Apple do not of course, but TSMC have stated they expect 3nm to be produced in volume in 2H22 which tells us we have at least one more round of Apple Silicon on 5nm. In 2021 we will presumably see Apple Silicon parts with increased core counts and desktop TDP This will be our first chance to see how the best of ARM goes against the best of X86 in like-for-like configurations.
    • whynotminot 6y ago
      > I haven't studied it carefully, but it sure looks like 90% of the performance improvement is using a big cache, which is a totally obvious thing to do. Also the big x86 guys have more or less been asleep at the wheel for almost a decade. Dude, has Intel called you yet? You've got some serious CTO chops.
  • Zenst 6y ago
    In some ways it is the environment the M1 was born from that helped. mobile space CPU's focus upon low power usage and that has seen many core software tasks get dedicated instructions and why you end up with the M1 in some tests utterly trouncing competition as it has dedicated hardware catering for the common niche things that software ends up doing - the hardware video encoding being a small area, but deep down, more than that. This along with advances in software/hardware integration and being able to synergies that at a level nobody else can. The way to think of it is - if Intel did an operating system from scratch, it would tap the CPU extremely well compared to others due to them knowing the internals better and fully. Then add the ability for them to see that adding some dedicated hardware to replace some software instruction combinations and you start to see a tightly integrated team of CPU and Operating system/software. One area that I've always wished CPU's would take would be a dedicated core or two for the OS that is completely isolated from the other cores, which would be for the software/applications you run. Now if those ran about two different architectures - darn that would be the inner geek in me appeased.
    • africanboy 6y ago
      The project HydrOS aimed to build an Erlang operating system that way: one core for the OS, one scheduler per core other than the OS one. Unfortunately it looks the project is now abandoned
      • Zenst 6y ago
        Thank you, not heard of that, had a look https://www.youtube.com/watch?v=8OyRFbf6MDk https://www.youtube.com/watch?v=8OyRFbf6MDk Seems the main/only dev moved onto other things and it stagnated.
    • stoat_meniscus 6y ago
      The PS3 did something like this. One processing unit of the Cell processor was reserved for the OS while the rest could be used for games.
    • setpatchaddress 6y ago
      What would your goal be? I think locking a modern, general-purpose OS to a small number of cores would artificially constrain performance, assuming a reasonable scheduler.
  • xorcist 6y ago
    > by the iPod without most experts believing Apple could make a mobile phone Except for all the people practically begging Apple to make a phone for years, except all the analysts who wrote essays on how computer companies could make successful phones, except for all the fanboys making fan-art of phones with that big circular wheel.
  • pmlnr 6y ago
    Or... in 10 years, we'll have another round of Meltdown, Spectre, etc, because of the big tricks.
  • api 6y ago
    I don't buy it. I think there is in fact one "trick," which is shedding the X86 decode bottleneck. People always make the point that the X86 decoder is only ~5% of the die. Sure, that's true, but keep two things in mind: (1) While it's only 5% of the die, it runs constantly at full utilization. The ALU is also only a small percentage of the die (5-10%). How hot does your CPU get when you're running the ALU full blast? Now consider that there is a roughly ALU-sized piece always running full blast no matter what the CPU is doing because X86 instructions are so complex to decode. Not only does this give X86 a higher power use "floor," but it means there's always more heat being dissipated. This extra heat limits thermal throttling and thus sustained clock speed unless you have really good cooling, which is why the super high performance X86 chips need beefy heatsinks or water cooling. (2) It apparently takes exponentially more silicon to decode X86 instructions with parallelism beyond 4 instructions at once. This limits instruction level parallelism unless you're willing to add heat dissipation and power, which is a show stopper for phones and laptops and undesirable even for servers and desktops. People make the point that ARM64 (and even RISC-V) are not really "RISC" in the classic "reduced" sense as they have a lot of instructions, but that's not really relevant. The complexity in X86 decoding does not come from the number of instructions or even the number of legacy modes and instructions but from the variable length of these instructions and the complexity of determining that length during pipelined decode. M1 leverages the ARM64 instruction set's relative decode simplicity to do 8X parallel decode and keep a really deep reorder buffer full, permitting a lot of reordering and instruction level parallelism for a very low cost in power and complexity. That's a huge win. Moreover there is nothing stopping them from going to 12X, 16X, 24X, and so on if it's profitable to do so. The second big win is probably weaker memory ordering requirements in multiprocessor ARM, which allows more reordering. There are other wins in M1 like shared memory between CPU, GPU, and I/O, but those are smaller wins compared to the big decoder win. So yes this does foreshadow the rise of RISC-V as RISC-V also has a simple-to-decode instruction set. It would be much easier to "pull an M1" with RISC-V than with X86. Apple could have gone RISC-V, but they already had a huge investment in ARM64 due to the iPhone and iPad. X86 isn't quite on its death bed, but it's been delivered a fatal prognosis. It'll be around for a long long time due to legacy demand but it won't be where the action is.
    • imtringued 6y ago
  • ogre_codes 6y ago
    > The sum of a large number of small engineering improvements, coupled with a lot of component integration detail work, Exactly. ARM has been progressing faster than Intel. For the past 8 years or so, Apple has had the fastest ARM CPU out there on the iPhone/ iPad. Apple has sucked up TSMC's 5nm production. They've integrated a pile of relevant coprocessors into the CPU and put fast RAM on the package. The SSD is lightning fast and SSD encryption is done via a dedicated coprocessor. It's not one magic trick, it is countless bits of engineering, manufacturing, and purchase choices.
  • jonas21 6y ago
    > the near term lockup of the top of the line fab in the supply chain also reminds me of how Apple had secured exclusivity for some key leading edge iPhone parts (was it the screens?). Yes, Apple managed to lock up most of the global supply of capacitive touchscreens for about a year after the iPhone came out. The iPhone wasn't the first phone to use a capacitive touchscreen, but for a while, it seemed like it was because nobody else could produce devices with them in large volumes. People used to dismiss Tim Cook as "just" a supply chain guy. But I think it's become clear that supply chain management is at least as important to Apple's success as anything on the design or marketing side.
• shmerl 6y ago
  > Instead of spending all that silicon on more CPU cores, perhaps we can add more coprocessors instead? Isn't it always a trade-off and some balance? You can add more specialized processors (ASICs) but that also takes away space from general purpose processing units on your die. So depending on the workload your co-processors might be useful or simply dead weight that's not utilized but takes away from the general purpose units that could be useful.
  • chrisseaton 6y ago
    > or simply dead weight What's wrong with dead weight? Is unpowered silicon a problem? Can't it sit there unused until the rare occasion it is used and still be practical?
    • shmerl 6y ago
      You have less general purpose cores to use, so you have less processing power in that sense.
      • chrisseaton 6y ago
        Why do you have to have less general purpose cores? If they're not powered up at the same time they're not competing for power or heat. They're competing for space but does that matter much when you're packaging chiplets?
        • shmerl 6y ago
          Because your space on the die is not infinite? More ASICs - less general purpose cores. Unless you expect die size to grow more and more.
          • chrisseaton 6y ago
            Die size is limited but package size can get pretty large without causing problems can't it? It obviously doesn't need to be infinite.
• tyingq 6y ago
  I'm missing the reason why RISC-V in particular is (claimed to be) so much better suited for building specialized co-processors. Are they talking about ISA extensions? Or maybe that the royalty free model makes it cheaper?
  • syntaxing 6y ago
    Same, I love the idea of RISC-V but I don’t really get how it’s better either from a technical standpoint. Would love to hear more about the main advantage of RISC-V against others.
    • socialdemocrat 6y ago
      RISC-V has a tiny basic instruction-set consisting of very simple instructions. That makes it possible to implement a RISC-V core on a very small silicon die. Smaller simpler cores make it easier to increase clock frequency as well as reduce watt usage. That gives RISC-V an advantage over the competition such as ARM, where any implementation will require a much larger and complex core to handle all the ARM instructions you must implement to be a valid ARM CPU.
    • FullyFunctional 6y ago
      I implement RISC-V for a living and for fun. Arm64 is a very good modern ISA. RISC-V is good too. Comparison with RISC-V must account for the much broader purpose of RISC-V, but just to focus on a few points (I'm not an Arm64 expert though): * RISC-V (RV64GC) have simpler instructions than Arm64. It's possible it would have a slight frequency advantage given the same implementation resources, but Arm64 might need slight fewer instructions. Notably, Arm64 have more addressing modes. Fusion and cracking makes this mostly a wash, but implementing a RV64 cores is a lot easier than an Arm64 (I speculate). * Arm64 has load pairs and store pairs; this is a significant advantage. * RISC-V has no flags and conditional branches directly compares operands. This look like a significant advantage in the code I have looked at and is easier to implement (no flag renaming etc.)
      • YorkshireSeason 6y ago
• dkjaudyeqooe 6y ago
  The broader point is that RISC-V provides the freedom and a practical ecosystem in which to innovate. Custom instructions may only be a small part of that.
  • Guthur 6y ago
    The PC platform has plenty of freedom for innovation, it's actually quite open, you can create what ever peripheral, addon, whatever you want on top of it. The problem is that if you want mass adoption of your fancy new bespoke offer it's quite a bit tricker no matter how good it is at doing it's thing, and that problem does not got away with different ISAs, probably harder to be honest.
    • socialdemocrat 6y ago
      You cannot innovate in how things are integrated however. You got to stick to the industry standards. Nor can you say innovate by switching the CPU architecture in your computer. A vertical integrated system like a Mac allows for much more innovation. In fact this is true for any vertical integrated system. If you look at Amiga, NeXT, SGI, SPARC and many others, they where always far ahead of the PC in terms of technology.
      • Guthur 6y ago
        Sure, you can create a closed vertically integrated system which will allow you the freedom to do what you want, but you've not created a platform for others to integrate with when you do. The point is those industry standards make the PC a more open platform, where multiple vendors can contribute innovation on the same common basis.
        • machello13 6y ago
          There's a huge number of developers out there who have managed to do just fine innovating on macOS and iOS.
• 29athrowaway 6y ago
  Has anyone tried to overclock a M1 processor yet?
  • mhh__ 6y ago
    I'm also curious whether they're vulnerable to spectre (any variant)
    • jcranmer 6y ago
      Every superscalar processor in the past several decades is vulnerable to some Spectre variant. The Apple A1s were also susceptible to one of the Meltdown variants, not sure if that one is fixed in the M1.
    • alwillis 6y ago
      I'm also curious whether they're vulnerable to spectre (any variant) I seriously doubt it—that was nearly 3 years ago. According to an Ars Technica article, ARM dealt with the issue far better than Intel or AMD [1]: "ARM's response was the gold standard. Lots of technical detail in a whitepaper, but ARM chose to let that stand alone, without the misleading PR of Intel or the vague imprecision of AMD. For the array bounds attack, ARM is introducing a new instruction that provides a speculation barrier; similar to Intel's serializing instructions, the new ARM instruction should be inserted between the test of array bounds and the array access itself. ARM even provides sample code to show this." [1]: https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-heres-what-intel-apple-microsoft-others-are-doing-about-it/ https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre...
      • mhh__ 6y ago
        New AMD chips are still vulnerable, I wouldn't be so sure.
• webwielder2 6y ago
  Is 2021 the year of RISC-V on the desktop?
  • phire 6y ago
    In a way, yes. Sifive is actually shipping the first RISC-V desktop form-factor motherboard early next year.
    • the_duke 6y ago
      Important to note that this board is basically a developer kit for adapting software or implementing drivers, not something intended for actual users. It's way too expensive/underpowered for that. Actual end user desktop/laptop/phone SoCs are probably years away (apart from specialised cores). I'd very much love to eventually have something like a Risc-V edition PineBook and PinePhone though.
      • brucehoult 6y ago
        It's hard to tell at this point, but it should be close to or even overall better than Pi 4 / Pi 400 performance -- worse CPU (but better than Pi 3+), but better and more RAM and better I/O e.g. M.2 SSD. And whatever real GPU you want to put on it instead of the fairly low end one on the Pi 4 -- SiFive are demonstrating their board with the Radeon RX580, a 150W $300 GPU but lower end ones should work fine too. All at a much higher price than a Pi, of course, but similar to x86 PCs. Compared to x86 PCs the CPU performance is probably around 2001 or so Pentium III or PPC G4 but, again, with everything else (16 GB DDR4 RAM, M.2 SD, GPU of your choice) current generation.
  • oblio 6y ago
    I can't tell if you're joking or not.
  • kzrdude 6y ago
    M1 is being delivered now, so it would be less of a guess to say that 2021 is the year of ARM on the (mainstream) desktop. With Raspberry pi 400, there's another desktop computer for the same prediction.
• webwielder2 6y ago
  Why do people ascribe broader ARM implications to the M1? Apple uses the ARM instruction set to make an amazing CPU. It could probably make one with the x86 set too. It doesn’t mean everyone else making ARM processors will suddenly get much better. Not to mention that Apple’s very similar A series has already been around for years.
  • johnbender 6y ago
    Worth noting that the ISA is more than a set of instructions it’s also a semantics for those instructions. For example the concurrent semantics of ARM processors permits a much larger array of optimizations on the per thread level which is good for performance.
  • cpuguy83 6y ago
    They can't make an x86 one because Intel holds the rights on it and only AMD has a license to do this (there is a history here). Also I wouldn't be surprised if one actually could not build anything like M1 (at that power usage) w/ x86.... Intel certainly hasn't been able to.
    • RuggedPineapple 6y ago
      The history is actually pretty simple. Originally it was because the US government requires a second source for any components and so Intel had to license it to somebody to supply the US government. Then later AMD's 64 bit instructions became the standard, so Intel needed the license for the 64 bit extensions and AMD needed the x86 base and so they just decided to cross-license and call it good.
      • gonzo 6y ago
        You seem to have not mentioned the lawsuit and clean room effort.
        • RuggedPineapple 6y ago
          Which lawsuit? The mid-late 2000's one after all this history? Or the 1991 one that was about intel seeking ways to squeeze out AMD from it's license? The first one isn't really relevant to this and the second one could have been more direct but AMD having a license and then getting another later as part of the deal on x86-64 does allude to behind the scenes shenanigans.
• rswail 6y ago
  It's an interesting argument. From a software perspective it's like building in a standard interpreter (eg lua) and extending it with a library that talks to your application. So you get the benefit of a standard interpreter (lua or RISC-V ISA) that you can use standard tooling on, plus the appropriate extension for your use-case.
• angry_octet 6y ago
  Although I think the premise of the article is wrong, it is nicely written. A major nitpick: unified memory is being massively over hyped. There is a reason GPUs have their own memory bus -- contention. CPU/GPUs fighting over access to memory causes massive disruption to very parallel computation. Even if Intel/nVidia resolved their fight over inter-CPU connectivity or we're talking POWER and nVidia using NV-LINK, you still need extra memory ports to keep things fed. The more cores and the faster the GPU the more memory bandwidth required. I expect to see future Mac Pro M1 series machines with multiple CPU sockets -- at which point memory isn't unified any more, and all the regular CC-NUMA tricks will be used. But it won't be a big deal.
  • forrestthewoods 6y ago
    > unified memory is being massively over hyped. There is a reason GPUs have their own memory bus -- contention. CPU/GPUs fighting over access to memory causes massive disruption to very parallel computation. Not sure I totally agree with this. Game console have unified memory architecture and it’s a beloved feature. It greatly simplifies things and allows the CPU to far more easily use results computed by the GPU with complicated sync commands or frame delays. Maybe unified architecture is less valuable for non-interactive programs. I’m not sure. This is a fair bit outside of my wheelhouse. Memory access is definitely one of the biggest bottlenecks. So I fully agree with the general concern. And you may even be right that the unified architecture isn’t that interesting. But I’m not so sure it’s the problem you think it is.
    • angry_octet 6y ago
      It does indeed make it easier to code. But you may have noticed that Xbox X has moved to having different speed memories with different memory controllers, even if logically contiguous and uniformly accessible. The CPU pool has a narrower bus and can't be used for graphics objects -- you have to queue for copy to the graphics pool. The driver then schedules a deconflicted copy. The PS5 architecture also has different speeds -- but the slow access is to SSD! It has manual management of streaming resources from SSD to RAM, but also allows direct SSD reads -- but that is a trick, because the SSD controller has a huge RAM cache too. So I'd say we're actually moving away from UMA in general. I think that memory aware scheduling is going to be the next win -- online learning to understand memory access patterns and scheduling compute and cache fill. Fancy cache algorithms used to take too much logic (and slow cache fill logic down), but for SSD->RAM you can do lots of prediction based on program state.
• Animats 6y ago
  Not clear what RISC-V has to do with the Apple M1. Also not clear what benefit RISC-V would have for "coprocessors". GPUs and various machine learning speedup devices are massively parallel devices, intended to run small, specialized programs in parallel on multiple specialized execution units. Also note that the real win of the Apple M1 is lower power consumption. In terms of basic compute speed, there are Intel products that are roughly comparable. But they use more much more power. This is more about battery life than compute power. (Also heat. Apple laptops have had a long-standing problem with running too hot, from having too much electronics in a thin fanless enclosure. The M1 gets them past that.) The hardware video decoder is probably to make it possible to play movies with most of the rest of the machine in a sleep mode. The CPU is probably fast enough to do the decode in software, but would use more power than the video decoder.
  • webmobdev 6y ago
    > Also not clear what benefit RISC-V would have for "coprocessors". As the article states, the architects of RISC-V recognized that co-processors that assist the CPU to do more and more specialised repetitive tasks will be the norm. Thus, RISC-V was designed in a way to accommodate such co-processors, with limited instruction sets that make its CPU design simpler. The Apple ARM processor is also similar - the ARM system-on-chip they have designed is highly customised with many co-processors all optimised for the macos / ios platform. Apple's SoC contains a GPU, an image processing unit, a digital signal processing unit, Neural processing unit, video encoder / decoder, a "secure enclave" for encryption / decryption and unified memory (RAM integrated) etc. (Note that this is not a unique innovation - many ARM SoCs like these already exist in different variations. In fact, it's what made ARM popular.) Obviously, when a system software or application uses these specific units of an SoC to process specific data, they may be faster than a processor that doesn't have these units. And Intel and AMD processors currently don't have these specific units integrated with their CPU. Anyway, the point the article is making that the RISC-V architects recognized that such co-processors will be the norm in the future, and thus the author is predicting that RISC-V will become more popular, now that the M1 acts a showpiece for the architectural idea the RISC-V wants to popularise.
    • 6y ago
• dblechoc 6y ago
  Found a typo: Coprocessor as special purpose processors ~> Coprocessor are special purpose processors
• enos_feedler 6y ago
  I think the narrative around instruction set is a bit overblown. I was a chip architect for the shader core at a major GPU company. I worked on simulators and modeling performance for next generation chips where we changed the ISA for each family of chips. The big reason why Apple Silicon is so damn fast is because they were able to shape the design at modeling time exclusively around Mac system level workloads. At best, Intel would have some subset of traces come from Apple for important traces to optimize for. Combine getting to narrow traces down exclusively for one platform, and heterogeneous design space (cpu + coprocessors) and you can really tune a monster.
  • skavi 6y ago
    Does optimizing for a single system really improve performance significantly in general purpose computing benchmarks like SPEC? IIRC, the M1 also does fairly well with virtualized Linux.
    • kbumsik 6y ago
      It does. The point is how Apple could use so much silicon space for the CPU in the SoC. Most AP and CPUs are designed to be general purpose as possible, so there are some spaces used for unnecessary interfaces. But Apple could use those spaces for CPU. Also Apple could increase the die size without thinking about profit in chip production because they earn money from their devices, so by selling SoCs like others. No other companies can do silicon business like Apple.
      • beagle3 6y ago
        That doesn’t sound reasonable to my (electrical engineer but 15 years since last involvement in processor design) ears. Intel has enough product lines that there are no “unnecessary interfaces”; what were the unnecessary interfaces in the Intel chip used by Apple? Similarly, so does Qualcomm and the tens of other of ARM licensees - any mass market design can find or customize a core with no meaningful dead weight. It may be a contributing factor, but I have not seen anything to indicate it’s very important. I give the “many small things done right” theory much higher likelihood - just as in the case if the iPhone, there wasn’t any specific thing that wasn’t done before - except for a winning combination.
• blackrock 6y ago
  The end of x86 is nigh. Nobody really buys a Mac for Intel CPUs. Just like nobody buys an iPhone for Intel CPUs.
  • pacetherace 6y ago
    That's taking it a bit too far. Now that Apple has shown multiple times that software can be used to bridge the transition from one architecture to another, I have a feeling that x86 will also take a similar route of revisiting the ISA to scale up the performance while supporting legacy ISA through software.
• snvzz 6y ago
  Reasonably well written article, but silly conclusion. There's no benefit from using ARM as the main CPU, relative to RISC-V, given an appropriate set of RISC-V extensions. Yet licensing fees and a smaller market for cores on ARM give RISC-V the advantage.
  • socialdemocrat 6y ago
    It is a question of relative advantage. RISC-V has in relative terms much stronger benefit used in co-processors than ARM. That will drive RISC-V adoption in this area. However for general CPUs the RISC-V is not as obvious, although we have seen some early claims of some really efficient RISC-V implementation with much higher clock frequency than ARM at lower watt usage. So sure, when we no more, it may turn out that RISC-V is also the superior choice for main CPU. But at the moment, that is more of an unknown. If we for the moment only assume a slight advantage to RISC-V over ARM, then ARM will stay ahead of the game, because it is already entrenched. People have lots of tooling and software for ARM. You don't switch to a whole new CPU architecture without clear benefit. But there is an interesting argument/speculation to be made about what happens in the wider PC industry in response to M1. By the time PC makers start getting serious to meet the challenge from M1, it may have become apparent that higher performance RISC-V are possible. Thus it could possibly encourage Apple competitors to attempt to leapfrog Apple by going towards RISC-V instead as main CPU. But nothing happens without Microsoft, so who knows. A lot of coordination needs to happen.
    • snvzz 6y ago
      >If we for the moment only assume a slight advantage to RISC-V over ARM, then ARM will stay ahead of the game, because it is already entrenched. Licensing costs and NVIDIA's ARM purchase --hostile company with plenty of lawsuits with current ARM licensees-- will offset the (non-existant beyond Apple and a few Windows netbook experiments) entrenchment ARM has on the desktop. >People have lots of tooling and software for ARM. You don't switch to a whole new CPU architecture without clear benefit. There's been a lot of effort put into tooling for RISC-V over the last few years, with more ongoing. The RISC-V foundation member list is not to be ignored. There's strong corporate and government backing behind RISC-V. The existing licenses won't disappear, but whether new cores and/or new ISA revisions from ARM will get licensees post-NVIDIA purchase is anybody's guess. Mid/Long term, I just don't see ARM stand a chance against RISC-V.
• quelsolaar 6y ago
  The RISC-V has a terrible Instruction-per-Clock and thats where Arm shines over x86. The idea that's specialty hardware is an Apple invention and that you cant get that with x86, is also ludicrous. Take a x86 CPU from AMD or Intel and add a RTX 3090 and you have specialized hardware for ML, graphics, ray-tracing and video encoding/decoding that runs circles around an M1.
  • samat 6y ago
    Energy efficiency? Not so much in circles.
    • quelsolaar 6y ago
      Sure, if your goal is to get the longest running battery then you want something else, but this is also the problem with Apples design, it is designed to be low power. If you want the best graphics/ML/Compute/Ray-tracing/videoencoding/decoding and you are not running on a battery then the M1 is not for you. I think this is a big deal, because it will mean that all the innovation on the bleeding edge will happen on other platforms then the MAC. In WIN/Linux land loads of people are innovating, on hardware for all these things, OS features, applications, peripherals (Like VR). On the Mac side almost nothing can happen unless one company makes it happen. A single company have limited resources and most of all attention span. The problem with controlling everything and doing everything yourself, is that you have to be the best at everything. In the long run you will fail at something. My guess is that the GPU is where Apple will fall behind first, and where it will be most obvious. They simply dont have the muscle and inclination to go head to head with nVidia on GPUs.
      • yoz-y 6y ago
        The whole impressive thing about the M1 is that it is low power AND fast. With all other current gen processor you can only pick one. > They simply dont have the muscle and inclination to go head to head with nVidia on GPUs. I wouldn’t bet on this, Apple has a history of barging into markets and becoming tech leaders in them. Mainly because they have enough money and clout to attract the best talent in the areas.
• deleted 6y ago
  [deleted]
• GeekyBear 6y ago
  Some of the things that make Apple's ARM implementation so performant, taken from Anandtech's excellent A14 deep dive. https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2 https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de... Extremely wide instruction decode: >Featuring an 8-wide decode block, Apple’s Firestorm is by far the current widest commercialized design in the industry. IBM’s upcoming P10 Core in the POWER10 is the only other official design that’s expected to come to market with such a wide decoder design Other contemporary designs such as AMD’s Zen(1 through 3) and Intel’s µarch’s, x86 CPUs today still only feature a 4-wide decoder designs (Intel is 1+4) A very deep reorder buffer: >A +-630 deep ROB is an immensely huge out-of-order window for Apple’s new core, as it vastly outclasses any other design in the industry. Intel’s Sunny Cove and Willow Cove cores are the second-most “deep” OOO designs out there with a 352 ROB structure, while AMD’s newest Zen3 core makes due with 256 entries, and recent Arm designs such as the Cortex-X1 feature a 224 structure. Exactly how and why Apple is able to achieve such a grossly disproportionate design compared to all other designers in the industry isn’t exactly clear, but it appears to be a key characteristic of Apple’s design philosophy and method to achieve high ILP (Instruction level-parallelism). A huge number of execution units: >On the Integer side, whose in-flight instructions and renaming physical register file capacity we estimate at around 354 entries, we find at least 7 execution ports for actual arithmetic operations. These include 4 simple ALUs capable of ADD instructions, 2 complex units which feature also MUL (multiply) capabilities, and what appears to be a dedicated integer division unit. The core is able to handle 2 branches per cycle, which I think is enabled by also one or two dedicated branch forwarding ports On the floating point and vector execution side of things, the new Firestorm cores are actually more impressive as they a 33% increase in capabilities, enabled by Apple’s addition of a fourth execution pipeline. The FP rename registers here seem to land at 384 entries, which is again comparatively massive. The four 128-bit NEON pipelines thus on paper match the current throughput capabilities of desktop cores from AMD and Intel, albeit with smaller vectors. Massive low latency Level 1 caches: >128KB L1 Data cache for which we can test for, however following Darwin kernel source dumps Apple has confirmed that it’s actually a massive 192KB instruction cache. That’s absolutely enormous and is 3x larger than the competing Arm designs, and 6x larger than current x86 designs The huge caches also appear to be extremely fast – the L1D lands in at a 3-cycle load-use latency. AMD has a 32KB 4-cycle cache, whilst Intel’s latest Sunny Cove saw a regression to 5 cycles when they grew the size to 48KB. Massive L2 Cache: >On the L2 side of things, Apple has been employing an 12MB structure that’s shared between their four big cores. This is an extremely unusual cache hierarchy and contrasts to everybody else’s use of an intermediary sized private L2 combined with a larger slower L3. Apple here disregards the norms, and chooses a large and fast L2. In comparison Zen 3 has 512 KiB L2 per core, and Tiger Lake has 1.25 MiB L2 per core. Another point tweeted by the author of the above piece but not in the above article... Much more accurate branch prediction: >Finally doing perf counters on a dedicated test bench... 9900K having 60% worse branch misprediction than Apple's A12. https://twitter.com/andreif7/status/1307420010177007625 https://twitter.com/andreif7/status/1307420010177007625 There's more going on with the M1 design than "it's ARM/RISC".
• gchadwick 6y ago
  I don't really see the advantage of using RISC-V as the ISA for a specialised processor. Yes you can have some tooling advantages because the basic stuff is done for you but such ISAs are often hyper specialised. You may not want everything in the RV32I/RV64I (the basic RISCV instruction set) and you'll certainly want a whole bunch of stuff that isn't in an existing extension and you may want to do things in a way that's fundamentally incompatible with the existing ISA (maybe you want flags or condition codes, maybe you want a giant register file with indirect addressing, auto increments and weird memory addressing modes, maybe you want variable length instructions or fixed width that's greater than 32 bit etc). The complexity is in the specialised stuff anyway so having a RISC-V base is unlikely to save you a huge amount of effort. The author attempts to point to Nvidia as an example > Because RISC-V has such a small and simple instruction-set it beat all the competition, including ARM. Nvidia found they could make smaller chips by going for RISC-V than for anybody else. They also reduced watt usage to a minimum. As I understand it Nvidia's use of RISC-V was for controller cores, its not the main ISA doing the important work (i.e. Whatever they use for the shader cores in a GPU). I suspect they chose RISC-V primarily because there were no arm cores that precisely fit their requirements, so RISC-V gives the opportunity for a custom design that does. So yes RISC-V is great when you have a need for a CPU that doesn't fit nicely with what arm already provides. In a coprocessors these are likely to provide control and coordination. You'll still want to build a custom ISA for the custom accelerator side of it.
  • simonh 6y ago
    > As I understand it Nvidia's use of RISC-V was for controller cores, its not the main ISA doing the important work… Isn’t that exactly the use case the article is talking about?
    • gchadwick 6y ago
      Not as I read it: > Going for custom proprietary instruction-sets is thus not a good idea (In reference to why you'd use RISCV for co-processors in general) I'm arguing the custom ISA is essential to building the co-processor (or at least makes it easier). The fact your application is super specialised means the existing RISC-V software ecosystem doesn't really help you. Nvidia's use of RISC-V is incidental, not a key part of their GPU architecture.
• strenholme 6y ago
  ARM has been eating away at Intel for a while now, the same way Intel ate away at the mainframe and minicomputer market in the 1980s and the MIPS/Sparc/HPPA/Alpha workstation market in the 1990s. While the mainframes and minis ate the low-cost PCs for lunch in the 1980s, and the $20,000 workstations of the 1990s had far better performance than a 386 (or even 486 did), PCs were cheaper and more widely available. It was the economies of scale and the standardization on x86_64 that made the PC the performance king in the first 2000s decade. Intel (and, of course, AMD) x86 did not have the best ISA but they, because of economies of scale, had the best fabs which let them outperform anything else. While Intel was dominating with raw performance in the first 2000s decade, embedded chipsets slowly coalesced around the ARM ISA, a process which was accelerated by Apple choosing ARM for the iPhone (Nokia also used ARM in a lot of their phones). Moore’s Law finally stopped working for Intel and they stopped being able to outfab everyone else in the mid-to-late 2010s; a 2012 x86 chip has about the same performance as, say, a 2017 x86 chip. Intel saw the writing on the wall with people using non-Intel ISAs for phones, and tried to make an Atom chip which would work in a phone; it was a flop. Nobody wanted the x86 ISA unless they needed it in systems which ran legacy applications. With the Raspberry Pi moving up from only suitable for specialized embedded applications to having near-desktop level performance, and with Apple finally making an ARM chip which is competitive (and in some cases superior) to Intel’s desktop chips, and with legacy x86 Windows applications being in many cases replaced with webpage and smart phone applications, it looks the industry as a whole is finally moving past x86 and its bloated instruction set. This is a much needed breath of fresh air for the computer industry. I like the M1 because I like that we now have mainstream non-x86 desktop/laptop computers again. I think RISC-V has a lot of potential, and I am interested in what comes of it in the 2020s, whether it blooms like the ARM did, or if it goes the way of the HPPA, Alpha, or Sparc.
  • sharpneli 6y ago
    > Nobody wanted the x86 ISA unless they needed it in systems which ran legacy applications. It wasn't fast/efficient enough. If it had been faster or with better power consumption it would've been fine. There was a massive push to get Android studio to automatically compile X86 binaries for you etc. But why would you put an Atom in your phone if it means it's slower and worse battery life? That's the reason it flopped. ISA change is a hindrance for switching, but it can be overcome. Even if Intel had sold Atom chips with ARM ISA and identical performance to the X86 variant it would have still flopped due to the poor performance and efficiency.
• aWidebrant 6y ago
  Putting a CPU core in your hardware accelerator seems more useful when it's stuck on the wrong side of a memory bottleneck. That way, you could run longer programs in local accelerator memory before you have to take the hit of communicating with the rest of the system. Apple's M1 seems designed to give all types of cores equally fast access to the same memory pool. At that point, it might make more sense to make your accelerator cores as simple as possible and program them from the CPU. I guess what's really not clear to me is why, if you're building your main CPU on ARM, you would pick RISC-V for your programmable accelerators in the same SoC, rather than using one of the smaller ARM cores available.
  • socialdemocrat 6y ago
    It is mentioned in the article. ARM has a much larger and complex instruction set which means you need to have a larger silicon real-estate. E.g. for a minimal core with similar features, cache etc, a RISC-V CPU would take half the die space of ARM. Half the size is 4x cheaper, as cost grows exponentially with die area.
    • brucehoult 6y ago
      Minimal cores don't have caches :-) Looking at press releases from various customers of Andes and SiFive, it seems that a minimal 2-stage RV32E is about half the size of Cortex-M0+ (which has a very crippled instruction set compared to other 32 bit ARMs), and 3-stage RV32IMC is 1/3 the size and power consumption of Cortex M3. Using 64 bit RISC-V instead of 32 bit doesn't double the size, as the instruction decode and control logic don't change, so 64 bit RISC-V is smaller than 32 bit ARM. 64 bit ARM is of course a totally different ISA to 32 bit ARM, and is massively complex with hundreds and hundreds of required instructions -- you can't subset it. FPU is compulsory. NEON SIMD is compulsory. I don't even know what the size and energy use comparison is between minimal 64 bit RISC-V and minimal 64 bit ARM. 10x? 20x? It's got to be something like that.
• sigzero 6y ago
  He's entitled to his opinion. I don't see the M1 foreshadowing anything for the RISC-V.
• Zenst 6y ago
  Not all is bad, the whole aspect of the M1 bringing alternative CPU architectures to the front mindset outside the mobile landscape is good. Remember ARM been around for years but has lacked in some area's of code development and been a back-seat passenger in so many avenues and drivers being one of those that stands out. Now the push to cope with two architectures more will be more prominent in design of software as well as support. That all ends up laying the foundations that will only go to help alternative CPU architectures more over the one x86 size fits all that many avenues have and are still based around. We have been slowly reaching a plateau in CPU performance and been case of adding many cores and riding the process node for that performance leap as more space for more cores at same power limits. That has almost already plateaued and now seeing lower power usage as already have enough cores, start to become more viable for desktop. So many timing factors do start to play out now and RISC V or whatever others are out there will now have a better chance to compete upon a playing field in which their worst case would be good enough for many tasks and their best case would be able to shine and not be held back as unable to scale as easily due to limitations as those limitations eroding away, albeit slowly it is a case that we are slowly by surly seeing things move in the right directions. As an aside, I'd perversely love a CPU that had multi architecture cores on-board - even if was two CPU's architectures on the same SOC core. That all said, still waiting for ECC memory to become more mainstream consumer wise.
• Symmetry 6y ago
  I don't think things will work out this way at all. The best DSP coprocessors generally use a VLIW instruction set and no amount of extensions will turn RISC-V into that. The best graphics coprocessors use a SIMT instruction set and no extension will make RISC-V into that. The best media decoding and encryption corpocessors use a fixed function pipieline without any instructions at all and so there's no way they could have one ISA or another. In software you can have very low development cost by using existing open source tools hidden behind nice abstraction layers. Hardware design doesn't have such nice abstraction layers and while IP blocks exist designing one has a certain irreducable cost which won't be reduced that much by using a RISC-V design. But the performance penalties of trying to use a general purpose ISA, even one with extensions, are very real and won't be enough to make the savings worthwhile.
  • qlk1123 6y ago
    > The best DSP coprocessors generally use a VLIW instruction set and no amount of extensions will turn RISC-V into that. Please check P extension. > The best graphics coprocessors use a SIMT instruction set and no extension will make RISC-V into that. Please check V extension. > Hardware design doesn't have such nice abstraction layers and while IP blocks exist designing one has a certain irreducable cost which won't be reduced that much by using a RISC-V design. RISC-V is still in its early stage, but all these concerns have been considered seriously. The foundation hosts many different Task Group to tackle all possible needs. > But the performance penalties of trying to use a general purpose ISA, even one with extensions, are very real and won't be enough to make the savings worthwhile. Only time will tell.
    • Symmetry 6y ago
      > Please check P extension. That doesn't seem to have anything to do with software scheduled general parallel execution of instructions. Letting you have a branch, an arithmetic operation, and a load in the same instruction for example. > Please check V extension SIMD is not the same as SIMT. SIMT doesn't handle divergent flow control well compared to a general purpose computer. However it does do it better than SIMD, even predicated SIMD, in important ways. I think that trying to come up with one ISA that can handle every use case is liable to be just as successful as coming up with one programming language that can handle every use case.
• stefan_ 6y ago
  What is this goddamn obsession with trying to make RISCV anything and everything? It's a very mediocre instruction set architecture that is used because it's, and this is the most important part, royalty free, and this also helps, there is lots of free enthusiastic labor that builds support for it into bintools, gcc and so on so you get a working toolchain without spending coin.
  • socialdemocrat 6y ago
    Could you elaborate on why you think RISC-V is a mediocre instruction-set architecture? I would rather say it is genius: https://erik-engheim.medium.com/the-genius-of-risc-v-microprocessors-b19d735abaa6 https://erik-engheim.medium.com/the-genius-of-risc-v-micropr... RISC-V has learned a lot from the mistakes of previous ISAs and made sure the instruction-set fits both low power consumption solution as well as high performance solutions. All sorts of benchmark tests show that RISC-V from a theoretical standpoint would execute programs faster. You can tell this by analysis how how many instructions are needed for different programs for different architectures. And how many clock cycles are needed per instruction etc.
  • brucehoult 6y ago
    Who says RISC-V is mediocre? Here's the opinion of probably THE most important ARM engineer of the 1990s and 2000s, Dave Jaggar who developed the ARM7TDMI, Thumb, Thumb2. https://www.youtube.com/watch?v=_6sh097Dk5k https://www.youtube.com/watch?v=_6sh097Dk5k Check at 51:30 where he says "Are there any ARM snipers? No .. I would Google RISC-V and find out all about it. They've done a fine instruction set, a fine job [...] it's the state of the art now for 32-bit general purpose instruction sets. And it's got the 16-bit compressed stuff. So, yeah, learning about that, you're learning from the best."
• andy_threos_io 6y ago
  So when will Apple switch to RISC-V 2030? :P