7 ms·
Maybe this is a bit of a side topic, and I'm a layman, but I'm interested to know why the M1 chip is able to perform so surprisingly better? And why Intel or o
by supernova87a 6y ago
Maybe this is a bit of a side topic, and I'm a layman, but I'm interested to know why the M1 chip is able to perform so surprisingly better? And why Intel or others can't just come up with a similar design, if it's clear from the specs/die images what's being done?
Is it years of work to figure out the placement of CPU/GPU/memory units on the die, routings, and come up with new instruction sets? I imagine this wasn't new physics, Apple was just using contract fabs, right?
What's the secret sauce that let them pull this off, and fend off others?
Edit, oh, this is somewhat answered below in https://news.ycombinator.com/item?id=25093313 https://news.ycombinator.com/item?id=25093313
- ksec 6y agoIntel's current design are 1-3 years late depending on which roadmap and sector you are counting. Caused by their 10nm delay. Intel had Tigerlake / WillowCove Design but they cant ship it. They also have Golden Cove. If you have put the design they were suppose to be using now, on a IPC basis Intel might still be in the lead.
- petra 6y agoSo basically given the same process, all companies have almost a similar offering?
- atty 6y agoDisclaimer: I’m a chip design enthusiast and not a professional, but this is how I understand things right now. If you read the anandtech article describing the A14/M1 chips, it seems that the ARM ISA lets Apple do some things that are either exceptionally hard or impossible on x86, like making individual cores much “wider” in terms of instruction decode, allowing the A14/M1 cores to do significant parallel execution. This allows their cores to be significantly more efficient in terms of instructions per clock cycle. To be clear this isn’t just the benefits of ARM - Apple is far ahead of other ARM designers as well. On the other hand, the wider the execution pipeline, generally the slower the cores have to be clocked (Im actually not sure why this is, to be honest). This is part of how Intel is able to produce chips in the 5.0+ GHz range. So it’s not that every designer converges to the same design (internally, they’re quite different). Instead, what’s happening is that all the relevant trade offs (pipeline width and depth, ISA, fab tech, power targets, etc) are leaving competitors within an order of magnitude in performance. And the question of who’s going to take the lead is a question of who’s executing best on all these fronts, and who’s currently got a lot of talent working on areas that will see continued improvement. But whatever happens, I wouldn’t bet against Apple. Their team has been delivering improvements like clockwork, year over year for quite a long time now.
- f6v 6y agoWhat about other ARM chips?
- nolok 6y agoOther ARM chips are aiming for smartphone/tablet and are more than enough for this. No one using samsung latest top phone is thinking "if only that phone was 15% faster ! this is a major issue". No one makes ARM chips for laptop, because of the chicken and egg issue. Windows on ARM going mainline could change it.
- beagle3 6y agoAmazon’s Graviton2 (originally from Annapurna Labs) is apparently delivering significant efficiency on the server side. Laptops will be there soon enough even without windows.
- HeadsUpHigh 6y agoHopefully without windows. It would be nice if we could get our own little *nix corner.
- treesknees 6y agoWe've seen some of this already, for example with Microsoft's SQ1/SQ2 SoC manufactured with Qualcomm for the Surface Pro X series of laptops. They already emulate x86 well enough to run apps compiled for 32bit x86, and they should be coming out with 64bit support soon. Once Microsoft is shipping these layers within Windows, it's only a matter of time before the use of ARM CPUs in more laptops takes off.
- robotnikman 6y agoDoes windows on ARM support emulation of x86 apps? Probably the biggest advantage for windows right now is tat you can run apps from 20 years ago perfectly fine, and of course the large library of playable games built over the years.
- trepetti 6y agoIt has really been cascading process delays dating back to 2014 when 14 nm got pushed back when Broadwell was supposed to launch, too.
- supernova87a 6y agoWhat takes time to bring a chip to market? As in the question, if you know exactly what needed to be designed (in concept), how long would it take you to have a fab turning out units? Is it the work to figure out how to lay down the component blocks on the die and all the circuit routing? Is it figuring out how to assemble the power-efficient components from the Arm library? Does that take years? Is it the instruction set? Is it the planning for manufacturing capacity? I'm just curious to know what the actual work and division of labor / time is to "make a chip". I would love to know for example: -- Initial design, 10 people, 1 year -- Prototype runs, 5 people, 6 months -- Final design, 5 people, 1 year -- etc etc. -- Acquiring fab capacity / manufacturing hardware, 10 people, 1 year -- etc etc. But sounds like there's no way Intel or others can just "leapfrog" even if they knew what needed to be done and could abandon their prior choices.
- ksec 6y ago>But sounds like there's no way Intel or others can just "leapfrog" even if they knew what needed to be done and could abandon their prior choices. At best It take one year to build a Fab. It takes another one just to plan to built it. That is assuming you get the regulation approval with zero delay. Building a Fab means absolutely nothing if you cant get the process to yield. Look at Samsung Foundry in the past 3- 5 years. Intel's Leapfrog chances was their Intel Custom Foundry. Had they not mess that one up they would have a Fighting chance. Even if they had a Design that Leapfrog Apple's M1 today, it would still be let down by their 10nm SuperFin Process.
- imhoguy 6y agoI would quote Orwell here: "Who Controls the Past Controls the Future". It is about lack of control over legacy killing the progress. The power of Intel is "proven" legacy, but building completely new architecture is expensive and prone to adoption failure (Itanium?) when Intel has no control over OS (Windows), apps or virtualization software. Then Apple has control over all that: they can make hardware (scaled up mobile HW), change their OS to support it (iOS bits), support past apps (Rosetta), enforce support in new apps (compiler, LLVM, certification).
- mmphosis 6y agoApple is now Full-Stack. It's turtles all the way down to the CPU!
- beagle3 6y agoItanium was a really bad architecture for the time (and possibly still is). It was a bet that sufficiently smart compilers would be available, but they weren’t available in time. They aren’t even available today 20 years down the line in a form that would have justified Itanium if they were available then. It wouldn’t have mattered if Intel controlled the OS or not - it just wasn’t competitive. There’s nothing you can learn from it about Apple - who delivered an ultra competitive, likely even when emulating Intel architecture in software.
- nickik 6y agoThis is not really the case. Most Intel servers run linux, Intel has nearly complete control over linux in a practical sense. They can put developers in it and update the OS and unless its a very user hostile feature it will go into the mainline kernel and be everywhere. The same goes for compiler and so on. Intel could easily open up their boot and make the store there much better. The don't quite have the vertical control of Apple, but to say they are fundamentally hindered by their legacy is quite questionable. The fucked up improving their manufacturing.
- imhoguy 6y agoUnlikely. There is more Linux devices running as Android on ARM than any other processors. You I can run Termux on ARM Android with complete set of of GNU tools. Also ARM is supported natively by Debian and Ubuntu [1]. Once devs will sort out their new shiny ARM Macs whoes (Docker, other tooling) I smell there may be ARM server market rising soon. [1] https://help.ubuntu.com/lts/installation-guide/armhf/ch02s01.html https://help.ubuntu.com/lts/installation-guide/armhf/ch02s01...
- hyperpallium2 6y agoApart from cache, anandtech notes https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2 https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de... What really defines Apple’s Firestorm CPU core from other designs in the industry is just the sheer width of the microarchitecture. "Width" enables greater parallel execution of instructions.
- trepetti 6y agoOne of the interesting comments in that article was how they pinned limited width of x86 decode implementations on variable instruction length. There are obvious code density benefits to the x86 variable length approach (especially in immediate encoding), but I guess the need for realignment creates long critical paths on the frontend. I wonder if the more constrained variable instruction length of RV64GC (32- and 16-bit instructions only) will be able to similarly scale up to 8-wide instruction decode like Apple has been able to do with AArch64.
- klelatti 6y agoInteresting point. I guess as cache sizes go up instruction density becomes less important. Also Arm abandoned Thumb - which was relatively easy to decode - for AArch64 and I guess they must have done quite a lot of analysis before doing so.
- phire 6y ago64bit x86 squanders it's variable length advantage by being a 40 year old design that has been extended over and over again. Much of the opcode space is wasted with old single byte instructions that are rarely used these days. There are REX prefix bytes required everywhere to access all 16 registers. Modern instructions that are used all the time are hidden away behind prefix bytes. 64bit ARM is a complete redesign of the ARM instruction encoding, and they put a lot of thought into using the instruction space optimally. 32bit ARM also wasted a lot of it's instruction encoding space, but 64bit ARM is a massive improvement. Despite requiring roughly 10% extra instructions on average, the average arm64 is around the same size as the average x86 binary. Immediates aren't a huge problem. All 32bit immediates and many 64bit immediates can be encoded in 1-2 instructions. Anything that can't should probably just use a PC relative load. IMO, the much simpler instruction decoding massively outweighs the need for slightly more load bandwidth.
- deleted 6y ago[deleted]