X86 vs. Arm
- Thread starter Cmaier
- Start date
Yoused
up
I was looking at a discussion at TOP that got me to thinking about what IPC really means, by comparison. In order to optimize throughput compilers targeting x86 trend toward the most efficient instructions, which makes their code output look more RISC like. Therefore, the real-world IPC numbers should be fairly comparable. Some ARM instructions do the work of two or three x86 instructions and vice versa.
Is there a statistical analysis that makes a useful comparison of instruction weight (that would include frequency-of-use by weight)?
Is there a statistical analysis that makes a useful comparison of instruction weight (that would include frequency-of-use by weight)?
- Posts
- 5,286
- Reaction score
- 8,435
What do you mean by “weight?”
Yoused
up
Amount of work done,
- Posts
- 5,286
- Reaction score
- 8,435
Hard to know how to measure that. Does a MUL instruction do more work than an ADD instruction? Some people would say yes, some would say no.
Yoused
up
I just learned that a recent version of ARMv9 includes the equivalents of x86 rep movs and rep stos, but without the D flag ( forward-only ).
I am of mixed feelings about this. It does fit cleanly into the instruction set coding and is somewhat more flexible than the x86 versions. With out-of-order execution and memory access, I could see how such operations might not bottleneck a processor (other code would flow around them, possibly with a retire-pipeline mod that would let them sit in place until a memory barrier is encountered). 64-bit ARM added a divide instruction, which is multi-cycle, so this would not be that far out of bounds, and it would almost certainly execute faster than code.
Still, it kind of feels like it breaks a rule.
I am of mixed feelings about this. It does fit cleanly into the instruction set coding and is somewhat more flexible than the x86 versions. With out-of-order execution and memory access, I could see how such operations might not bottleneck a processor (other code would flow around them, possibly with a retire-pipeline mod that would let them sit in place until a memory barrier is encountered). 64-bit ARM added a divide instruction, which is multi-cycle, so this would not be that far out of bounds, and it would almost certainly execute faster than code.
Still, it kind of feels like it breaks a rule.
Which rule? ARM is a pragmatic ISA, if something can be implemented in a performant way by the CPU and would result in net efficiency increase, it’s a great candidate for addition. Personally, I believe that writing custom software loops for something as crucial as memory copies is insanity. Have you seen modern optimized memcpy() implementations? They are often hundreds of instructions long. A CPU will almost always know the best way to implement large memory copies. The only times you should copy “manually” is if the amount of data is very small or you need to influence the cache in some specific way.
Yoused
up
It seems non-RISC-like, especially with the P/M/E setup (which probably means that compilers will not be casually dropping it into code streams), but I guess ARM is not really all that RISC-like since v8+. The ISA and its backing architecture spec do remain consistent and easily decoded, though.
- Posts
- 5,286
- Reaction score
- 8,435
”risc-like” is a moving target. The best indicator that I think still generally works is that In RISC architectures, most instructions work with registers and you usually cannot access memory without something like a LOAD/STORE. Even in the 1990’s, there were enough exceptions to every other “RISC rule” that it was more of a “I know RISC when I see it” sort of situation. People were even making up names for “real” RISC ISA’s (like “spartan RISC”).
