Jim Keller: Arm vs x86 vs RISC-V - Does it Matter?

what's your minimum specification in terms of that constant idea you've you've spoken about um cpu instruction sets in the past um and one of the biggest requests for this interview i got was around your opinion about cpu instruction sets um you know specifically how we deal with fundamental limits on them how we pivot to better ones you know and what's your skin in the game in terms of your arm versus x86 versus risk five i think at one point you said most compute happens on a couple of dozen op codes so iso doesn't matter am i remembering that correctly it's a very sad story yeah yeah yeah yeah no it's not even a couple of dozen eighty percent of the execution is like six instructions you know load store add subtract compare and branch you pretty much covered it you know if you're writing in you know pearl or something you know maybe maybe you call and return are more important than compare and branch but you know instruction sets only matter a little bit right you can lose 10 or 20 because you're missing instructions or you know for a while we thought variable length instructions were really hard to decode but we keep figuring out how to do that you basically predict where all the instructions are in tables and once you have good predictors you can predict that stuff well enough so fixed length instructions seem really nice when you're building little baby computers but you're building like a really big computer the predictor to figure out where all the instructions are isn't dominating the die so it doesn't doesn't matter that much and when risk first came out an x86 was half microcode so if you look at the die half the chip was a rom there may be a third or something and the risk guys could say there's no rom and a wrist chap so we get more performance but now the rom is so small you can't find it actually the adder is so small you can hardly find it right so what limits computer performance is predictability and the two big ones are you know instruction predictability and branch predictability and and data locality and now the new predictors are really good at that they're big like the predictors are way bigger than the adder right and that's where the you get into the the cpu versus like gpu or ai engine debate yeah like the gpu guys will say look there's no branch predictor because we do everything in parallel so the chip is way more adders and subtractors and that's true if that's the problem you have but they're they're crap at running c programs yeah it's yeah it's all about crafting the software or the compile time right if you can do that well then and then gpus were built to run shader programs on pixels so you're given like 8 million pixels and so you know the big gpus now have 6 000 threads so you can cover all the pixels with each one of them running you know a thousand programs per per frame but it's sort of like you know an army of ants carrying around grains of sand whereas big ai computers they have really big matrix multipliers and like a much smaller number of threads essentially that do a lot more math because the problem is inherently big whereas whereas you know the shader problem was the problems were inherently small because there were so many pixels so there's genuinely three different kinds of computers cpus gpus and ai and then nvidia is kind of doing the tweener thing where they're using a gpu to run ai and they're trying to enhance it and some of that's obviously working pretty well and some of it's obviously fairly complicated and so yeah so it's an interesting and this happens a lot like like general purpose cpus when they saw the vector performance of gpus added vector units and sometimes that was great because you only had a little bit of vector computing to do but if you had a lot a gpu might be a better solution so many people are asking you what do you think about arm versus x86 you know which one has the legs which one you know applies to performance do you do you care much um i care a little like here's what happened so when x86 first came out it was super simple and clean right and then at the time there was multiple 8-bit architectures x86 the 80 6800 6502 i programmed probably all of them way back in the day and then x86 oddly enough was the open open version right they stay licensed at the seven different companies and then that gave people opportunity to put in tape but intel surprisingly was both licensed it in one long run but then they went to 16 bits and 32 bits and then they added virtual memory virtualization security then 64 bits and then more features so what happens to an architecture is as you add stuff you know you keep the old stuff so it's compatible so when arm first came out it was a clean 32-bit computer and compared to x86 it just looked like you know way simpler and easier to build but then they added a 16-bit mode and the it instruction which is awful and a kind of a weird floating point vector extension set with overlays and a register file and then 64 bits which partly cleaned it up and they added you know there was some special stuff for security and booting and you know so it slowly got more complicated now risk five shows up and it's it's the shiny new cousin right because there's no legacy and it's actually an open instruction set architecture and and people build in universities where they didn't have time or interest to add too much junk like some architectures have so relatively speaking just because of its pedigree and age it's early in the life cycle of complexity and it's a pretty good instruction set they did a fine job so if i was just going to say i want to build a computer really fast today and i want it to go fast risk 5 is the easiest one it's the simplest one it's got all the right features it's got the right top eight instructions you know that you actually need to optimize it doesn't have too much junk so yeah so mod instruction sets have too much bloat especially the old ones because they're not too much legacy baggage construction sets that have been iterated and added to will have too much bloats yeah that's what always happens right so as you keep adding things like you know the engineers have to struggle right you have this really good design there's 10 features so you add some features to it the features all make it better but they make it more complicated and as you go along every new feature you add gets harder to do because the interactions for that feature and everything else gets terrible and and the marketing guys and you know the the old customers will say don't delete anything but meanwhile they're all playing with the new fresh thing that's you know only does 70 of what the old one does but it does it way better because it doesn't have all these problems right so this is you know i've talked about diminishing return curves there's a bunch of reasons for diminishing returns but one of them is the complexity of the interactions of things slow you down to the point where something simpler that did last would actually be faster and that's happened many times it's it's some result of complexity theory and you know human nefariousness i think so do you ever see a situation where x86 gets broken down and something just gets reinvented or will it just remain sort of legacy and then just new things will pop up like risk five two well well then was a fairly you know clean slate that obviously had to carry along baggage for this and that but you know they deprecated a lot of like you know the old 16-bit modes and bats there's a whole bunch of junk that disappeared and sometimes if you you're careful you can say all right i need to support this legacy but it doesn't have to be performant and i can isolate it from the rest of the client emulator and stuff yeah emulate it or support it and we used to build computers such you know you had a front end you know fetch dispatch execute load store l2 cache and if you looked at the boundaries between them you'd see like a hundred wires doing random things that you know were dependent on exactly what cycle of you know or what phase of the clock it was now the interfaces tend to look like it's like construction boundaries i send an instruction from here to there and you know and then i have a protocol that says ax so the computer inside doesn't look like a big mess of stuff connected together it looks like eight computers hooked together that do different things there's a fetch computer and the dispatch computer and the integer execution computer and the floating point computer and if you do that properly you can change the floating point without touching anybody else and again that's that's less of an instructions that thing than what was your design principle when you build it and then how did you do it and were you faithful to that because the thing is you get to a problem you say boy if i could just add these five wires between these two boxes i could get rid of this problem but every time you do that every time you violate the abstraction layer you've created a problem for future gym future gym like like i've done that so many times it's like if you'd solved it properly it would still be clean but you know at some point you always have to hack a little bit and then that over time that kills you [Music] [Laughter] [Music] you

Channel: TechTechPotato: Clips 'n' Chips

Views: 32,627

Keywords: ian, cutress, techtechpotato, jim keller, jim keller interview, jim keller amd, jim keller intel, jim keller tenstorrent, what is jim keller doing now, jim keller zen, jim keller cove, jim keller ian cutress, jim keller techtechpotato, anandtech, people skills, jim keller engineering, engineering, arm vs x86, arm vs x86 vs risc-v, intel vs amd, intel vs apple, jim keller abstraction, abstraction, company culture, building teams, beyond euv, AI chip design, beyond silicon

Id: yTMRGERZrQE

Length: 10min 10sec (610 seconds)

Published: Fri Jul 09 2021

Reddit Comments

[u/wiki_me]

Anybody want to provide a short summary? any notable highlights?