7 ms·

In the undergraduate level computer architecture class I just finished, it was pretty much stated as fact that the simpler design and fixed instruction format o

• adamnemecek 9y ago
  > Why are x86/64 processors used for most high performance applications then? Modern Intel cpus are actually risc under the hood. https://en.m.wikipedia.org/wiki/Microcode https://en.m.wikipedia.org/wiki/Microcode
  • beached_whale 9y ago
    I have a naive understanding, but the compilers had to do a lot more work with the RISC systems. Also, is anything really your classic RISC any longer? Lots of new instructions and instructions that take a lot longer than 1 cycle are there. Anecdotally when looking at the assembly for Intel or Arm, they are often very close.
    • wolfgke 9y ago
      > Anecdotally when looking at the assembly for Intel or Arm, they are often very close. First: Modern ARM chips (i.e. what you will typically find in a mobile phone) support three instruction sets: A32, T32 (Thumb-2 on modern ARM chips) and A64 (if you don't know what they mean, google it up). So it hardly makes sense to talk of "ARM assembly" if you don't specify which instruction set you mean. I know there is UAL, which in some sense unifies the instructions of A32 and T32 on assembly level. There are very central differences that you will observe when looking at the disassembly of all ARM instruction sets vs. x86-32 or x86-64. - Typical x86 ALU instructions have 2 operands. Typical ARM ALU instruction will have 3. This is very typical for CISC vs. RISC instruction sets. Side note: A compiler often does register allocation by graph coloring. If 3-operand instructions are used this is an NP-hard problem. On the other hand if 2-operand instructions are used, we obtain a chordal graph, for which the graph coloring problem can be solved in polynomial time: https://en.wikipedia.org/w/index.php?title=Chordal_graph&oldid=777964476 https://en.wikipedia.org/w/index.php?title=Chordal_graph&old... - x86 ALU instructions also accept a memory both as source and destination (side note: if we add a register to the value at a memory address, on modern x86 cores this is mapped to 3 mu ops: load value, add, storeobly value). On the other hand (typical for RISC) ARM is a load-store architecture. So ALU instructions don't accept memory address contents as operands - instead one has to load the content of the address into a register first, do the ALU instruction and use a store instruction to store the result in memory. Side note: On x86 "{alu_instruction} r/m, r" (e.g. add [edx], eax) is atomic with respect to interrupts, e.g. when an interrupt occurs either this instruction has been executed completely or not at all. You want to make it also atomic with respect to code executing on other cores? Just add a LOCK prefix. - Even in 32 bit mode ARM already offers many registers (16 GPRs) and in A64 even 32. x86-32 only offers 8 and x86-64 16. Having more and orthogonal registers is typical for RISC vs. CISC. Thus ARM's call convention uses registers for passing the parameters (again very typical for RISC) and uses a link register for passing the return address. x86-32 instead typically passes return address and parameters on the stack (I know that under 32 bit Windows there also exists the __fastcall call convention that uses registers for passing parameters, too. But this is an exception). But admitted: under x86-64 on the Linux and Windows call convention they also use registers for passing parameters. - At least A32 and T32 cannot directly call functions that are too far away from the current instruction. So the linker has to insert veneers, which make this possible. One of course will not find veneers on x86. - It is not easy to access memory addresses relative to the instruction pointer on x86-32 (under x86-64 it is easily possible), while on ARM it is. So ARM assembly code will often contain small const variable values next to the function. One hardly sees such code on x86-32 (though on x86 it is not really necessary, since there are instructions that put some arbitrary constant into a register; A32 and T32 on the other hand allow only to encode some kind of constants, bases on a rather complicated scheme that I will not explain here; so this trick is rather helpful for writing ARM code). TLDR: Better look again at the disassembly carefully.
      • nullc 9y ago
        > on the other hand allow only to encode some kind of constants, bases on a rather complicated scheme that I will not explain here; Oh, it's not that bad: It codes an 8-bit value and a 4-bit circular shift-by-2-bits.
        • pm215 9y ago
          Also non-ancient ARM chips add the movw and movt instructions so you can load a 32 bit constant simply in 2 insns rather than having to play games with sequences of arithmetic insns or use a constant pool.
          • wolfgke 9y ago
            I accept this point and admit to be a little bit biased, since I learned a lot about ARM disassembly by reverse engineering code that runs on an ARMv5 ("ancient" by your standards) core.
• astrodust 9y ago
  Why did VHS prevail when Betamax was a superior format? Why did TCP/IP come out on top when other more capable protocols existed at the time? Why did the FAT filesystem end up becoming so wildly popular? x86 took over because of a number of factors, and over time improvements made it more RISC like internally. Read up on modern CPU design to see how RISC, CISC or whatever is just an API of sorts to the internal workings of the CPU. The two philosophies have become so blurred few people even use the term RISC or CISC any more. It's irrelevant.
  • mikeash 9y ago
    VHS won because Betamax initially couldn't fit an entire movie into one tape. VHS's quality was inferior, but it was superior in that it didn't require changing tapes partway through. By the time Betamax was able to fit a movie onto one tape, it was too late. Often when an "inferior" technology wins, it's because you're focusing too narrowly, and the winner is outright better in some way. For x86, Intel's process and design expertise overcame the shortcomings of the ISA, and then some. You're not necessarily buying x86, but rather buying the best silicon that happens to speak x86.
    • astrodust 9y ago
      I don't think you're disagreeing with me here. The "worse is better" principle often boils down to a few fundamentals: "A functioning program is always better than a non-functioning one" and "an understandable product or specification is always better than one that cannot be understood". Intel also made, and probably still does make RISC chips. The i960 and i860 are just two examples. https://en.wikipedia.org/wiki/Intel_i860 https://en.wikipedia.org/wiki/Intel_i860 They never took off on any appreciable scale. > You're not necessarily buying x86, but rather buying the best silicon that happens to speak x86. Or more specifically, you're buying the best chip that runs your existing software and works with the toolset you're familiar with. This is why Intel's Itanium project was doomed from the day they announced it. Nobody was going to re-write everything to work with their new instruction set. It's notable that Apple managed to go from 68K to PPC to x86 to x64 almost seamlessly, but they did that at the expense of backwards compatibility. You can run many Windows apps from the 3.1 days in current versions of Windows without emulation, but you can't run Mac software from the 68K days without it. Two different approaches. The Intel world is ruled, if not held hostage to backwards compatibility concerns. "Better" means "more traditional".
• EvgeniyZh 9y ago
  Because it's RISC under the hood
• RcouF1uZ4gsC 9y ago
  In addition, we seem to be going back to a more CISC like model. RISC was appealing when you could have simple instructions and take advantage of that to get high clock speeds. Now, that avenue is gone. Now, may CPU's are adding special instructions (for example AES or SHA acceleration instructions) or wide instructions (SSE, AVX, etc). We are likely to see more in the future, and may see specialized instructions to speed up neural nets.
  • deepnotderp 9y ago
    Neural nets are honestly best suited to a ZISC type architecture... In any case, specialized deep learning chips should be on their way. Not to toot my own horn here, but we're one of the hopeful deep learning chip startups, I'd be happy to answer any more questions or perhaps elaborate on why I think ZISC is better for neural nets.
    • dom0 9y ago
      It's almost always better to have a dedicated chip implement some algorithm, if it makes economic sense to do so. From hard drive controllers to Google's TPU.
      • deepnotderp 9y ago
        Deep learning processor != an ASIC If you burned an ASIC for a single type of network architecture, then that would be something else.
        • CalChris 9y ago
          The TPU is an ASIC. The result is called a Tensor Processing Unit (TPU), a custom ASIC we built specifically for machine learning. https://cloudplatform.googleblog.com/2016/05/Google-supercharges-machine-learning-tasks-with-custom-chip.html https://cloudplatform.googleblog.com/2016/05/Google-supercha...
          • 9y ago
• pcwalton 9y ago
  > Why are x86/64 processors used for most high performance applications then? Because (1) you can overcome those issues by throwing enormous manpower at them; (2) the business success of Windows, coupled with Intel's patent portfolio to keep out competitors, historically generated enough revenue to fund that manpower. (There are signs that this may not sustain itself forever, with Intel's failure in mobile and the performance disappointment of Kaby Lake, but regardless of how well the strategy will continue to perform in the future, it worked for decades.)
  • dom0 9y ago
    Regarding single-threaded performance it just seems increasingly likely that we finally hit the wall of what the current technology is able to support. I don't expect major advances here until other manufacturing tech is used.
• deepnotderp 9y ago
  Heh. There is no true CISC anymore, everything is RISC under the hood with a CISC to RISC conversion layer.
• dom0 9y ago
  Because your course is based on outdated materials. In the 80s and 90s academia and high-end computing was taken by a RISC illusion. RISC architectures were simple and clean and easy to implement at higher performance than any CISC processor of the time, so people assumed that of course RISC would be the feature, right? Well, no. CISC, or, to be more truthful, x86 was a mass-market item with competing manufacturers with deep pockets (like Intel and AMD). In the mid 90s both Intel and AMD broke RISCs neck (though it was not immediately clear perhaps what a groundbreaking innovation this was): They introduced processors that translated x86 instructions to other instructions (µops) that were then scheduled and executed. Turns out, this is pretty efficient for a number of reasons (1- you get existing software 2- x86 code can be really dense; RISC had instruction bloat issues 3- decoding insns is only a very small part of what a CPU does and does only consume a minority in transistors 4- you can change the µops, they are an implementation detail, to best suit the exact core at hand; something impossible for RISC). This allowed x86 all benefits of what RISC previously had for itself. By ~2000 most RISC architectures were dead (Alpha, SGI, ...) with only POWER and SPARC surviving in their niche markets. In summary: The importance of the ISA was vastly overestimated by researchers, who assumed that this was a blocking issue to make x86 go faster. In the end, x86 won, because x86 had the bigger market with more money in it.
  • pcwalton 9y ago
    > By ~2000 most RISC architectures were dead (Alpha, SGI, ...) with only POWER and SPARC surviving in their niche markets. You forgot ARM, which is a major omission. > In the end, x86 won, because x86 had the bigger market with more money in it. It's not the end yet. :) x86's dominance in the future is hardly assured, and in fact if you measure by total number of microprocessors sold, x86 is a small niche--300-400 million sales per year compared to 15 billion ARM chips sold.
    • dom0 9y ago
      This thread is about high performance. I.e. desktop, workstation, server processors. > Why are x86/64 processors used for most high performance applications then? Also ARM, the architecture where most cores have between three and four distinct frontends, hardly qualifies as R ISC.
• tjalfi 9y ago
  AMD and Intel can afford to spend a large amounts of money on design because x64 chips are sold at high margins in high volume. If you are interested in the economics of the chip business, [0] is a great Usenet post by John Mashey[1]. [0] https://groups.google.com/forum/message/raw?msg=comp.arch/9TQ6f9auA-4/o1yM0QMYM70J https://groups.google.com/forum/message/raw?msg=comp.arch/9T... [1] https://en.wikipedia.org/wiki/John_Mashey https://en.wikipedia.org/wiki/John_Mashey Edited to remove a duplicate footnote.
• CalChris 9y ago
  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 9y 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)
• p0nce 9y ago
  > Why are x86/64 processors used for most high performance applications then? x86/64 processors features very refined hardware prefetcher, caching system, jump prediction. Such processors will run average code runs more effectively than it deserves.
• rdc12 9y ago
  It is also worth making note, that Intel (and to a lesser extent AMD), have had a fair amount of advantage by being further ahead in chip fabrication technology, having more transistors has played a major role in how Intel kept it's status.
• thetinguy 9y ago
  You are correct. RISC did win. Modern x86 micro architectures are RISC under the hood. CISC instructions are implemented in microcode. https://en.wikipedia.org/wiki/Microcode https://en.wikipedia.org/wiki/Microcode
• brianwawok 9y ago
  Sad huh? You paid big money to learn outdated stuff. Cool to know the story but don't trust what a career prof spouts. Often it's not actually true.