Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple M1 Microarchitecture Research

dougallj.github.io

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Apple M1 Microarchitecture Research

#41

Post by meepmorp »

lincpa wrote: post #32

My computer hardware architecture design was published on February 06, 2019. One or two years later, the Apple M1 chip adopted the "warehouse/workshop model" design and was released on November 11, 2020. Warehouse: unified memory Workshop: CPU, GPU and other cores Products (raw materials): information, data there's also a new unified memory architecture that lets the CPU, GPU, and other cores exchange information bet…

I realize it's not what you're referring to, but the context and terminology of your comment reminded me of this:

https://manybutfinite.com/post/the-thing-king/

Re: Apple M1 Microarchitecture Research

#42

Post by arghwhat »

btown wrote: post #40
hajile wrote: post #33

Earlier quoted context omitted.

Intel'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.

Could 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?

No, 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.

Re: Apple M1 Microarchitecture Research

#43

Post by arghwhat »

EricE wrote: post #38
kergonath wrote: post #35

Earlier quoted context omitted.

Yeah but Qualcomm... They’re perfectly happy sitting in their arses if there’s nobody to kick them around, and they’re just a nuisance generally. I hope I’m wrong, but they won’t have direct competition from Apple because it looks unlikely that M1 devices will run Windows. They seem to be more or less happy with being 2 generations behind Apple on phone SoCs. And they basically gave up on wearables. So instead of hav…

Huh? I ran Windows on my M1 MBA quite easily: https://www.microsoft.com/en-us/software-download/windowsins... It was under Parallels but I’m sure over time someone will figure out how to direct boot into it if that’s really important. Performance of the M1 running Windows and games either in Crossover (commercial WINE implementation - well worth the $40 for ease of use/installation) or the Windows 10 beta actually tu…

> Huh? I ran Windows on my M1 MBA quite easily

> It was under Parallels but...

You didn't, you run Windows on virtualized hardware which isn't interesting.

Might be useful for you, but not interesting.

Re: Apple M1 Microarchitecture Research

#44

Post by klodolph »

btown wrote: post #40
hajile wrote: post #33

Earlier quoted context omitted.

Intel'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.

Could 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?

I 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.

Re: Apple M1 Microarchitecture Research

#45

Post by mzs »

mhh__ wrote: post #3

Source for what a validation buffer is? Couldn't find a reference on google

There has been an update:

>… The M1 seems to use something other than an entirely conventional reorder buffer, which complicates measurements a bit. So these may or may not be accurate. (This paragraph previously said "it seems to use something along the lines of a validation buffer". I think the VB hypothesis has since been disproven. Various attempts to measure ROB size have yielded values 623, 853, and 2295 (see the previous link). My uninformed hypothesis is that this may imply a kind of distributed reorder buffer, where only structures that need to know about a given operation track them, and/or some kind of out-of-order retirement.)

https://github.com/dougallj/applecpu/commit/dc3c220f58f428b5...

Re: Apple M1 Microarchitecture Research

#46

Post by rbanffy »

klodolph wrote: post #44
btown wrote: post #40

Earlier quoted context omitted.

Could 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?

I 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.

Does the reorder buffer in x86 processors operate on the x86 instructions or the µOPs?

Re: Apple M1 Microarchitecture Research

#47

Post by foobiekr »

btown wrote: post #40
hajile wrote: post #33

Earlier quoted context omitted.

Intel'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.

Could 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?

The 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.

Re: Apple M1 Microarchitecture Research

#48

Post by JoshTko »

wooger wrote: post #27
kergonath wrote: post #19

That’s an impressive piece of work. I would love to know how far this is from the information in the actual internal documentation. It’s very nice to have some excitement about a mainstream CPU architecture again.

Just a pain that due to Apple's policies on keeping a big margin and lack of sharing technology means that the rest of the industry won't benefit from this. Still very hard to see not getting an M1 as my next laptop, especially if they continue to do sane things line remove the shitty touchbar.

Giving stuff away doesn't generate profits needed to invest in R&D.

Re: Apple M1 Microarchitecture Research

#49

Post by kergonath »

EricE wrote: post #38
kergonath wrote: post #35

Earlier quoted context omitted.

Yeah but Qualcomm... They’re perfectly happy sitting in their arses if there’s nobody to kick them around, and they’re just a nuisance generally. I hope I’m wrong, but they won’t have direct competition from Apple because it looks unlikely that M1 devices will run Windows. They seem to be more or less happy with being 2 generations behind Apple on phone SoCs. And they basically gave up on wearables. So instead of hav…

Huh? I ran Windows on my M1 MBA quite easily: https://www.microsoft.com/en-us/software-download/windowsins... It was under Parallels but I’m sure over time someone will figure out how to direct boot into it if that’s really important. Performance of the M1 running Windows and games either in Crossover (commercial WINE implementation - well worth the $40 for ease of use/installation) or the Windows 10 beta actually tu…

Yeah it can help in a pinch or for some specific workflows, but that's not a substitute.

I am hoping that my 2015 15'' MBP does not die before the next 15'' or 16'' are released. 32 GB (bare minimum) or 64 GB (for future proofing) and a better CPU would be great.

I don't have enough time to play even my backlog of Mac and Switch games. I wanted to build another PC for fun and to play, but I am not sure I will anymore.

Re: Apple M1 Microarchitecture Research

#50

Post by glangdale »

hajile wrote: post #33
glangdale wrote: post #30

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 po…

Intel'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.

There 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.

Post reply on HN