3 ms·
It's interesting work. The results show a marked contrast with equivalent information for Intel (think uops.info, Agner Fog's work or even the Optimization Refe
by glangdale 6y ago
It's interesting work. The results show a marked contrast with equivalent information for Intel (think uops.info, Agner Fog's work or even the Optimization Reference Manual).
Most obvious is separating general purpose register stuff from SIMD. If you have a mixed workload, this means M1 is much wider in that sense (although note that the SIMD registers involved are 128b as opposed to up to 512b).
Intel's execution ports tend to be special flowers - there's almost always stuff that can be done and can't be done on any given port. So, of the execution ports (0,1,5,6) each one tends to have some special flavor that the others don't share - and there are often complex "oh, you can only do 2 of those or 3 of these". There's a very small list of operations (generally logic and LEA) that can be done on all of 0,1,5,6.
By contrast, most of the M1 things, you can do across every unit that is capable of doing it. Want to do 4 SIMD math ops? Go for your life! It's certainly easier to remember and understand.
I imagine the counterargument on the Intel side is that it's unlikely you need that many of some given operation - so they are saving area to not make every port omni-capable. This works pretty well (right up to the point it doesn't).
It will be interesting to see how the comparison between Intel and Apple plays out in the near future. M1 is a tour de force of balanced design, but I wouldn't count Intel out - especially if they can get their process mojo back (a lot of M1's current advantage is being able to invest transistors in a balanced and sensible way across the entire pipeline due to a better process).
- hajile 6y agoIntel's more likely argument is that they can't do that many because their decoders and ROB aren't wide enough to keep up. Given how huge their decode units are (about as big as all their integer ALUs), I don't know how x86 will actually solve this issue.
- btown 6y agoCould Intel adapt a Rosetta 2-style approach? Preprocess binaries to replace ancient instructions with modern equivalents, and be able to use smaller decode units? Would the gains be worth the translation requirements?
- arghwhat 6y agoNo, Intel needs to approach this from hardware alone. Apple has more freedom as they only have to worry about support from their own OS, and even only the latest revision.
- klodolph 6y agoI might call that the Transmeta approach. Back in the early 2000s, Transmeta offered x86-compatible systems that ran a proprietary VLIW core with software translation. The resulting system looked like an x86 system to the OS and was more power-efficient than contemporary x86 systems from other vendors. Intel has a perpetual license for all Transmeta patents and applications.
- rbanffy 6y agoDoes the reorder buffer in x86 processors operate on the x86 instructions or the µOPs?
- foobiekr 6y agoThe company that built the original Rosetta, actually apple branding on top of QuickTransit, actually could do x86 to x86 translation in their product and found that even when low hanging fruit was theoretically available it was challenging to extract. I don’t think the x86 stuff we are talking about is easy to extract. Instead this seems like something that wants an intermediate code + install time specializer a la mainframes.
- glangdale 6y agoThere are a couple distinct issues here - M1 is both wider than recent x86 but also more orthogonal. I'm not sure that decode is the bottleneck for all code - a lot of code could be played out of a pre-decoded uop cache or the LSD. People always return to decode as an explanation as it's an attractive RISC vs CISC morality tale. I also don't know how much of the decode unit is devoted to legacy support and MSROM, which doesn't necessarily have to scale the same way as the simple decoders.