5 ms·

CISC operations like 'imul' and 'idiv' were perceived like curse words in the RISC world of the day, but they were actually a beacon of hope. When x86 architect

CISC operations like 'imul' and 'idiv' were perceived like curse words in the RISC world of the day, but they were actually a beacon of hope. When x86 architecture matured, those operations became super fast thanks to the hardware acceleration. So take it with a grain of salt when you hear someone claim that RISC is invariantly superior to CISC. Times and times again, the truth lies somewhere in the middle.

leni536 4y ago
Well, idiv being super fast is new to me, but I guess it's relative.
- cperciva 4y ago
  Integer division is sufficiently famously slow that people (and compilers) go to great lengths to avoid it... which makes it rare enough that there's very little point implementing it. If you really need integer division, you can typically optimize it by doing a FP iteration and then fixing up the approximate result.
  - Tuna-Fish 4y ago
    The worst case integer divide times on newest Intel/AMD cpus are 15/18 for 64bit and 12/13 for 32-bit. Both do early out for easy values at around 10 cycles. Integer division is still on the slower side operations on the machines, but the advice to avoid division at all costs is outdated. In comparison, the FP divide instructions are in the ~13/14 cycles, it would be hard for you to shuffle data to that side and back and not be slower. (And no, they are not doing this internally -- both have separate integer divide units.)
    - magicalhippo 4y ago
      These things change over time, but at least a fair chunk of recent Intel CPUs had idiv handled by the floating-point unit. That is, it couldn't do an idiv and a fdiv in parallel.
  - astrange 4y ago
    As long as they're pipelined, slow operations are okay as long as you have enough other work to fill the pipeline until their result comes back.
tenebrisalietum 4y ago
Really? Not sure why. MIPS had multiply and divide instructions; ARM had multiply instructions; I know SH-4 has at least multiply instructions. I don't think hardware multiplication is a RISC or CISC thing. The "reduced instructions" that RISC is concerned with chiefly involve code flow mechanisms such as linkage, flag behavior, and interfacing with memory. It doesn't mean you need to create all your math operations from increment and bitwise instructions. The RISC/CISC thing stopped being meaningful once ... A) processors went all-in on out-of-order execution (this means everything was split into uops and reordered and your instruction stream no longer represents what the CPU does much of the time) B) processors started having parallel vector instructions. An article was posted here on HN making the case for considering "Out of Order" a new paradigm and it made a lot of sense to me.
- garganzol 4y ago
  RISC crowd presented lower number of transistors as one of the top selling points back in the day. Simpler instructions => fewer transistors => less heat => more room for performance, at least on paper. MUL and DIV instructions are not exactly transistor count friendly, so they caused an expected contradiction at the RISC camp back in the day.
  - rst 4y ago
    Some first-generation RISC processors, e.g. MIPS R2000, shipped with hardware multiply and divide, or even optional floating point.
- eru 4y ago
  > A) processors went all-in on out-of-order execution (this means everything was split into uops and reordered and your instruction stream no longer represents what the CPU does much of the time) Yes. That's why it has become more and more ridiculous to claim that C is 'close to the metal'.

leni536 4y ago

Well, idiv being super fast is new to me, but I guess it's relative.

cperciva 4y ago
Integer division is sufficiently famously slow that people (and compilers) go to great lengths to avoid it... which makes it rare enough that there's very little point implementing it. If you really need integer division, you can typically optimize it by doing a FP iteration and then fixing up the approximate result.
- Tuna-Fish 4y ago
  The worst case integer divide times on newest Intel/AMD cpus are 15/18 for 64bit and 12/13 for 32-bit. Both do early out for easy values at around 10 cycles. Integer division is still on the slower side operations on the machines, but the advice to avoid division at all costs is outdated. In comparison, the FP divide instructions are in the ~13/14 cycles, it would be hard for you to shuffle data to that side and back and not be slower. (And no, they are not doing this internally -- both have separate integer divide units.)
  - magicalhippo 4y ago
    These things change over time, but at least a fair chunk of recent Intel CPUs had idiv handled by the floating-point unit. That is, it couldn't do an idiv and a fdiv in parallel.
- astrange 4y ago
  As long as they're pipelined, slow operations are okay as long as you have enough other work to fill the pipeline until their result comes back.

tenebrisalietum 4y ago

Really? Not sure why. MIPS had multiply and divide instructions; ARM had multiply instructions; I know SH-4 has at least multiply instructions. I don't think hardware multiplication is a RISC or CISC thing. The "reduced instructions" that RISC is concerned with chiefly involve code flow mechanisms such as linkage, flag behavior, and interfacing with memory. It doesn't mean you need to create all your math operations from increment and bitwise instructions. The RISC/CISC thing stopped being meaningful once ... A) processors went all-in on out-of-order execution (this means everything was split into uops and reordered and your instruction stream no longer represents what the CPU does much of the time) B) processors started having parallel vector instructions. An article was posted here on HN making the case for considering "Out of Order" a new paradigm and it made a lot of sense to me.

garganzol 4y ago
RISC crowd presented lower number of transistors as one of the top selling points back in the day. Simpler instructions => fewer transistors => less heat => more room for performance, at least on paper. MUL and DIV instructions are not exactly transistor count friendly, so they caused an expected contradiction at the RISC camp back in the day.
- rst 4y ago
  Some first-generation RISC processors, e.g. MIPS R2000, shipped with hardware multiply and divide, or even optional floating point.
eru 4y ago
> A) processors went all-in on out-of-order execution (this means everything was split into uops and reordered and your instruction stream no longer represents what the CPU does much of the time) Yes. That's why it has become more and more ridiculous to claim that C is 'close to the metal'.