5 ms·

Why are x86/64 processors used for most high performance applications then? Well, you should start from this and then work backwards because it's just an empir

Why are x86/64 processors used for most high performance applications then? Well, you should start from this and then work backwards because it's just an empirical fact that x86_64 is fast and that RISC isn't. There are many reasons for that, none of them fair, but in the end, it's still just a fact. Yes, RISC-V is simple+elegant. If that's what you want, great. True, RISC-V is open source. If that's what you need, awesome. Now weigh those qualitative features against the cold hard $1B/year that Intel invests in making the mess that is x86 run fast. Add to that the billions that ARM+Samsung+NVidia+Apple+... spend on making ARM fast. It's not a fair fight. It really isn't. But know this. If RISC had anything tangible, any fundamental advantage, then we'd be living in a RISC world by now and we aren't (Patterson+Ditzel was 37 years ago). If you want to think worse is better, sure. Whatever. If you want to call ARMv8 MIPS-ish, that's your constitutional right. Skylake is a superscalar, speculative, out-of-order, renaming, hyperthreaded multicore beast. You may program it in x86 but those instructions get translated+cached as μops, very wide microinstructions. BTW, anyone who thinks that μops are actually RISC under the hood severely needs to re-read The Case for the Reduced Instruction Set Computer and then say, Inside Nehalem [1] or Micro-operation cache: A power aware frontend for variable instruction length ISA [2]; microprogramming (vertical+horizontal) predates RISC by decades [3]. These μops are wide, 150+ bits. Ain't nothing reduced about that. In 2017, believing in RISC is only slightly more acceptable than believing in Mill. Moreover, I say this as someone who went to Berkeley and read Patterson+Ditzel in 252. I should preach the religion. [1] http://www.realworldtech.com/nehalem/ http://www.realworldtech.com/nehalem/ [2] https://www.researchgate.net/profile/Ronny_Ronen/publication/3337434_Micro-Operation_Cache_A_Power_Aware_Frontend_for_Variable_Instruction_Length_ISA/links/00b7d5270fd6e29740000000/Micro-Operation-Cache-A-Power-Aware-Frontend-for-Variable-Instruction-Length-ISA.pdf https://www.researchgate.net/profile/Ronny_Ronen/publication... [3] https://people.cs.clemson.edu/~mark/uprog.html https://people.cs.clemson.edu/~mark/uprog.html

nialo 10y ago
In one of the Mill talks, I've long since forgotten which, someone asks Ivan Godard a question about RISC. His response is something like "there was a brief window in the eighties where if you had a RISC machine you could get the whole computer onto one chip." I don't enough experience to know if this is right, but it strikes me as a nice clean explanation. It also explains why x86 won since then, because a couple generations later it was possible to get the whole computer onto one chip with x86 as well. (I may have misquoted badly, in particular I'm not sure about the dates) (edit: I found the talk, it's the last couple minutes of this: https://www.youtube.com/watch?v=LgLNyMAi-0I https://www.youtube.com/watch?v=LgLNyMAi-0I)
- CalChris 10y ago
  Your dates sound about right. The eighties. Mead+Conway was just out and fabs of a certain size became accessible. The question then was what could you do with these fabs and transistor budgets? Berkeley+Stanford did RISC+MIPS. Clark did the Geometry Engine at Stanford+SGI. So what could you do with X transistors? But then X became stupid large. The 68000 (1979) had 40,000 transistors. Now the Apple A10 has 3.3-billion transistors. So you can imagine that architectural design assumptions dating from 1980 will need to be revisited.
  - rwallace 10y ago
    > The 68000 (1979) had 40,000 transistors. Where did you get that figure? I'm curious because the figure I've seen tossed around is 68,000 transistors (the story going that this is where the model number came from).
    - CalChris 10y ago
      It's much more likely (like infinitely more likely) that the 68000 name stems from the earlier 6800 8-bit product line. There's nothing definitive saying 68,000 transistors and I've read both 40,000 and 68,000. I believe that 68,000 was just marketing. FWIW, Motorola also employed 68,000 people in 1980 (approximately): https://www.motorolasolutions.com/content/dam/msi/docs/en-xw/static_files/history-motorola-annual-report-archive-1980-9p32mb-40.pdf https://www.motorolasolutions.com/content/dam/msi/docs/en-xw... The Geometry Engine had 40,000. https://books.google.com/books?id=gD4EAAAAMBAJ&pg=PA17&dq=68000+40,000+transistors+geometry+engine&hl=en&sa=X&ved=0ahUKEwiHoqGEl8_TAhUN2GMKHfcTAKAQ6AEIIjAA#v=onepage&q=68000%2040%2C000%20transistors%20geometry%20engine&f=false https://books.google.com/books?id=gD4EAAAAMBAJ&pg=PA17&dq=68...
- pkaye 10y ago
  My own understanding is more simple... people care mostly about application availability and x86 was chosen as the primary platform for Microsoft Windows so anything that didn't support the x86 instruction set was at a disadvantage. These days with interpreted or JIT compilation, things are less certain but those days running things on bare metal mattered.
foobiekr 10y ago
nicely said. though I think the Mill deserves more credit. Assuming that the team doesn't die or simply get acqui(patent)hired, they seem more likely to have material impact than RISCv which exists simply to swap out Arm.
- CalChris 10y ago
  Mill has had some their patents issued and their applications published which means there's something to read rather than listen to Godard's talks. http://patents.justia.com/assignee/mill-computing-inc http://patents.justia.com/assignee/mill-computing-inc I'm impressed at their doing something completely different and do wish them well. I know someone on the team but I'm impatient.
  - foobiekr 10y ago
    To me the most interesting part is that Mill has attracted a quite amazing amount of supportive interest from people who are talented, experienced and knowledgeable. Essentially a who's who of comp.arch...
    - tmccrmck 10y ago
      I don't read comp.arch so who - besides Godard and willvarfar - is involved?
nkurz 10y ago
Yes, RISC-V is simple+elegant. If that's what you want, great. True, RISC-V is open source. If that's what you need, awesome. Now weigh those qualitative features against the cold hard $1B/year that Intel invests in making the mess that is x86 run fast. I wonder how hard it would be for Intel to substitute an alternative decoder in place of the current x86/x64. Given the existing micro- and macro-fusion capabilities, is there anything that would prevent them from reusing the loop streamer and decoded instruction cache and entire back-end for a different instruction set? While there are probably legal issues with ARM or Power emulation (are there?), it seems like it wouldn't be too hard for them to quickly put together a high-performing hyperthreaded superscalar out-of-order alternative for RISC-V should they ever want to. BTW, anyone who thinks that μops are actually RISC under the hood severely needs to re-read ... Could you expand on this? I take you to be saying that Intel µops aren't really the same as classic RISC at all, but you seem to be the only person in this thread that holds this position. The majority appear to be saying straight-out that current Intel is actually RISC under the hood. Personally, I suspect that you are right, and that it would be useful for you to make this claim more forcefully. Or maybe I'm the only one that believes this, and I'm misinterpreting you?
- CalChris 10y ago
  Microprogramming is a technology which goes back to the 50s. CISCs were microprogrammed. The VAX was microprogrammed. It was the status quo circa 1980. RISC as a term really dates to 1980 (although the ideas go back to the 801 and Crays machines). The big idea of RISC was to avoid microprogramming and have a simple to decode ISA which was directly executed by a short simple pipeline. ld/st + lots of registers + C compiler. Awesome. Indeed in Patterson+Ditzel's version of Luther's 95 theses, they say: Microprogrammed control allows the implementation of complex architectures more cost-effectively than hardwired control They say this in the section Reasons For Increased Complexity. RISC is revolting from that complexity, from microprogramming, so how can μops be RISC if that's what they were revolting from? I think people say this because no one knows what microprogramming is anymore. You might read one paper in a graduate architecture seminar. And no one but no one writes microprograms. The decode stage of Haswell translates add RAX,RBX into a '150b' μop. If can you read Agner Fog and you'll know how many μops, what the latencies are, etc. These are empirically determined properties of the μop but that's it. You know the Decoded ICache characteristics. But you don't know the ISA. After all that's done, you're left with maybe a 14-pipestage data path. That's not RISC. Complicated instructions (AAA) get interpreted. That's not RISC. Multiple functional units can calculate 2+3 operand effective addresses. That's not RISC. This all is REALLY not RISC. μops are micro-instructions, not RISC instructions. BTW, the alternate decoder kinda wouldn't work so well because the microarchitecture, functional units, datapath, caches and registers are really set up for x86. Folks wanted something like that at Transmeta, a Java processor, but the HW was designed for x86.

nialo 10y ago

In one of the Mill talks, I've long since forgotten which, someone asks Ivan Godard a question about RISC. His response is something like "there was a brief window in the eighties where if you had a RISC machine you could get the whole computer onto one chip." I don't enough experience to know if this is right, but it strikes me as a nice clean explanation. It also explains why x86 won since then, because a couple generations later it was possible to get the whole computer onto one chip with x86 as well. (I may have misquoted badly, in particular I'm not sure about the dates) (edit: I found the talk, it's the last couple minutes of this: https://www.youtube.com/watch?v=LgLNyMAi-0I https://www.youtube.com/watch?v=LgLNyMAi-0I)

CalChris 10y ago
Your dates sound about right. The eighties. Mead+Conway was just out and fabs of a certain size became accessible. The question then was what could you do with these fabs and transistor budgets? Berkeley+Stanford did RISC+MIPS. Clark did the Geometry Engine at Stanford+SGI. So what could you do with X transistors? But then X became stupid large. The 68000 (1979) had 40,000 transistors. Now the Apple A10 has 3.3-billion transistors. So you can imagine that architectural design assumptions dating from 1980 will need to be revisited.
- rwallace 10y ago
  > The 68000 (1979) had 40,000 transistors. Where did you get that figure? I'm curious because the figure I've seen tossed around is 68,000 transistors (the story going that this is where the model number came from).
  - CalChris 10y ago
    It's much more likely (like infinitely more likely) that the 68000 name stems from the earlier 6800 8-bit product line. There's nothing definitive saying 68,000 transistors and I've read both 40,000 and 68,000. I believe that 68,000 was just marketing. FWIW, Motorola also employed 68,000 people in 1980 (approximately): https://www.motorolasolutions.com/content/dam/msi/docs/en-xw/static_files/history-motorola-annual-report-archive-1980-9p32mb-40.pdf https://www.motorolasolutions.com/content/dam/msi/docs/en-xw... The Geometry Engine had 40,000. https://books.google.com/books?id=gD4EAAAAMBAJ&pg=PA17&dq=68000+40,000+transistors+geometry+engine&hl=en&sa=X&ved=0ahUKEwiHoqGEl8_TAhUN2GMKHfcTAKAQ6AEIIjAA#v=onepage&q=68000%2040%2C000%20transistors%20geometry%20engine&f=false https://books.google.com/books?id=gD4EAAAAMBAJ&pg=PA17&dq=68...
pkaye 10y ago
My own understanding is more simple... people care mostly about application availability and x86 was chosen as the primary platform for Microsoft Windows so anything that didn't support the x86 instruction set was at a disadvantage. These days with interpreted or JIT compilation, things are less certain but those days running things on bare metal mattered.

foobiekr 10y ago

nicely said. though I think the Mill deserves more credit. Assuming that the team doesn't die or simply get acqui(patent)hired, they seem more likely to have material impact than RISCv which exists simply to swap out Arm.

CalChris 10y ago
Mill has had some their patents issued and their applications published which means there's something to read rather than listen to Godard's talks. http://patents.justia.com/assignee/mill-computing-inc http://patents.justia.com/assignee/mill-computing-inc I'm impressed at their doing something completely different and do wish them well. I know someone on the team but I'm impatient.
- foobiekr 10y ago
  To me the most interesting part is that Mill has attracted a quite amazing amount of supportive interest from people who are talented, experienced and knowledgeable. Essentially a who's who of comp.arch...
  - tmccrmck 10y ago
    I don't read comp.arch so who - besides Godard and willvarfar - is involved?

nkurz 10y ago

Yes, RISC-V is simple+elegant. If that's what you want, great. True, RISC-V is open source. If that's what you need, awesome. Now weigh those qualitative features against the cold hard $1B/year that Intel invests in making the mess that is x86 run fast. I wonder how hard it would be for Intel to substitute an alternative decoder in place of the current x86/x64. Given the existing micro- and macro-fusion capabilities, is there anything that would prevent them from reusing the loop streamer and decoded instruction cache and entire back-end for a different instruction set? While there are probably legal issues with ARM or Power emulation (are there?), it seems like it wouldn't be too hard for them to quickly put together a high-performing hyperthreaded superscalar out-of-order alternative for RISC-V should they ever want to. BTW, anyone who thinks that μops are actually RISC under the hood severely needs to re-read ... Could you expand on this? I take you to be saying that Intel µops aren't really the same as classic RISC at all, but you seem to be the only person in this thread that holds this position. The majority appear to be saying straight-out that current Intel is actually RISC under the hood. Personally, I suspect that you are right, and that it would be useful for you to make this claim more forcefully. Or maybe I'm the only one that believes this, and I'm misinterpreting you?

CalChris 10y ago
Microprogramming is a technology which goes back to the 50s. CISCs were microprogrammed. The VAX was microprogrammed. It was the status quo circa 1980. RISC as a term really dates to 1980 (although the ideas go back to the 801 and Crays machines). The big idea of RISC was to avoid microprogramming and have a simple to decode ISA which was directly executed by a short simple pipeline. ld/st + lots of registers + C compiler. Awesome. Indeed in Patterson+Ditzel's version of Luther's 95 theses, they say: Microprogrammed control allows the implementation of complex architectures more cost-effectively than hardwired control They say this in the section Reasons For Increased Complexity. RISC is revolting from that complexity, from microprogramming, so how can μops be RISC if that's what they were revolting from? I think people say this because no one knows what microprogramming is anymore. You might read one paper in a graduate architecture seminar. And no one but no one writes microprograms. The decode stage of Haswell translates add RAX,RBX into a '150b' μop. If can you read Agner Fog and you'll know how many μops, what the latencies are, etc. These are empirically determined properties of the μop but that's it. You know the Decoded ICache characteristics. But you don't know the ISA. After all that's done, you're left with maybe a 14-pipestage data path. That's not RISC. Complicated instructions (AAA) get interpreted. That's not RISC. Multiple functional units can calculate 2+3 operand effective addresses. That's not RISC. This all is REALLY not RISC. μops are micro-instructions, not RISC instructions. BTW, the alternate decoder kinda wouldn't work so well because the microarchitecture, functional units, datapath, caches and registers are really set up for x86. Folks wanted something like that at Transmeta, a Java processor, but the HW was designed for x86.