2 ms·
> It's far easier to split a CISC instruction into uops, than to attempt to detect the possibly near-infinite combinations of RISC instructions that effectively
by jabl 9y ago
> It's far easier to split a CISC instruction into uops, than to attempt to detect the possibly near-infinite combinations of RISC instructions that effectively do the same thing so that they can be fused together.
Er, it's not like macro-op fusion is some theoretical thing that isn't proven in practice. x86 cpu's have done it for quite a while for CMP+JMP, and compilers optimize for it by not putting other instructions between the CMP and JMP. That is, macro fusion doesn't scan through some huge window of instructions, it only works for neighboring instructions.
If you want to know more, I recommend reading through the slides that the parent poster linked, and the article link I posted in a sibling comment.
> Consider a round of AES, for example.
FWIW, there is ongoing work to add a crypto extension to RISC-V, so this isn't really an argument for or against RISC-V per se.
> Or for something simpler, a memory copy loop. On x86, the latter is 2 bytes (and has been since the 8086)
REP MOV* is a good example of what's wrong with CISC. It gets you good instruction density, I grant you that, but it also slower than alternative implementations using, say unrolled loops and vector instructions. Look into a modern memcpy() implementation and prepare to be horrified. If it were that easy to make REP MOV fast, one would have thought that Intel with their near-unlimited budget would have made it so.
- userbinator 9y agoLook into a modern memcpy() implementation and prepare to be horrified. If it were that easy to make REP MOV fast, one would have thought that Intel with their near-unlimited budget would have made it so. Look up "enhanced REP MOVS" (Ivy Bridge), and before that, "fast strings" (P6). It can copy entire cachelines at once and easily beats anything else except in tiny microbenchmarks where the negative effects of huge unrolled loops don't appear. In general, the historical performance of the string instructions is interesting and worth researching more...
- jabl 9y agoYes, and for Ice Lake they're introducing the yes-this-time-we-really-mean-it-fast-rep-mov, er, "fast short rep movs". Time will tell whether it beats a software implementation. But my point still stands, if you're developing a new ISA, does it really make sense to add dedicated string copy instructions, using opcode space, adding die area for microcode ROM's, design and verification costs etc., considering that even Intel with all their money can't make them an obvious win compared to a software implementation? But yes, both for x86 and RISC architectures, it's probably unwise to optimize memcpy() implementations by staring at microbenchmarks that do nothing else than memcpy() of different sizes, thus ignoring the I$ pollution that a monster implementation causes.