6 ms·

There are also AFIAK a few "deprecated" instructions that are implemented for backward compatibility but do not perform well on modern cores or have much better

by api 10y ago

There are also AFIAK a few "deprecated" instructions that are implemented for backward compatibility but do not perform well on modern cores or have much better modern alternatives. These would be things like old MMX instructions, cruft left over from the 16-bit DOS days, etc. X86 is crufty. Of course all old architectures are crufty, and using microcode it's probably possible to keep the cruft from taking up much silicon. There are also instructions not universally available. A typical compiler will not emit these unless told to do so or unless they are coded in intrinsics or inline ASM.

nneonneo 10y ago
Good examples of (essentially-deprecated) instructions include the rep prefixed instructions for string operations (modern library code for string operations typically involve a mixture of SSE, full-word loads and unrolled loops for speed); the "loop" instruction (compilers usually generate explicit loops for flexibility); pretty much all the BCD arithmetic instructions (since programming languages don't typically use BCD anymore), and many other such examples. The x86 architecture is chock-full of rarely-used legacy instructions that are mostly carried around for compatibility these days.
- cfallin 10y ago
  > the rep prefixed instructions for string operations ... are actually preferred over a hand-written vectorized loop on Ivy Bridge and up (see [1] section 3.7.7, "Enhanced REP MOVSB and STOSB operation (ERMSB)"). It's indicated by a CPUID feature flag bit (edit: grep for "erms" in /proc/cpuinfo to see this). The reason is that microcode knows more about the dcache microachitecture, load/store units, special features (weak ordering with fence at end? [2]), etc., than you do, and can be specially optimized for the particular design. There's a slight cost to transitioning to microcode and back (to ordinary hardware-decoded instructions), of course, so for small operations it might not be a win. The section cited above shows ERMSB as ~break-even vs. 128 bit AVX on Ivy Bridge from 128 bytes up to 2KB, and about 2% faster above that. [1] Intel 64 and IA-32 Architectures Optimization Reference Manual (order #248966-026), April 2012. http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf http://www.intel.com/content/dam/doc/manual/64-ia-32-archite... [2] http://stackoverflow.com/questions/33480999/how-can-the-rep-stosb-instruction-execute-faster-than-the-equivalent-loop http://stackoverflow.com/questions/33480999/how-can-the-rep-...
  - olegolegovich 10y ago
    Do you have benchmarks, supporting "~break-even vs. 128 bit AVX on Ivy Bridge from 128 bytes up to 2KB" as I have not found it to be the case at least on Haskell (my benchmarking code is @ https://bitbucket.org/olegoandreev/scratch/src/dd7ab9008c59c8254dd5bdb4becae20457214c3f/memcpy-test/?at=default https://bitbucket.org/olegoandreev/scratch/src/dd7ab9008c59c...).
    - cfallin 10y ago
      I was just quoting the cited PDF ("the section cited above shows..."), which the author(s) did on Ivy Bridge. I haven't benchmarked it myself. It would be interesting to see how the most common cores today do on this...
  - sounds 10y ago
    And by not having a group of hand-optimized special cases, the REP MOVSB and REP STOSB can be inlined saving instruction cache.
- userbinator 10y ago
  The BCD instructions, despite originally conceived for BCD, actually have some other niche uses such as AAM/AAD for a small multiply/divide: https://news.ycombinator.com/item?id=8477254 https://news.ycombinator.com/item?id=8477254 In that article I also further refute the common belief that they are significantly slower in this comment, by reasoning and then an actual benchmark: https://news.ycombinator.com/item?id=8477585 https://news.ycombinator.com/item?id=8477585 And this is where I think a gap between compilers and humans exist --- would a compiler recognise, for example, that if your code, for whatever reason, happened to have this pattern of operations in it... http://x86.renejeschke.de/html/file_module_x86_id_3.html http://x86.renejeschke.de/html/file_module_x86_id_3.html ...it should emit a single AAS instruction? Or perhaps a simpler example, would it know to emit an AAM for an 8-bit division or modulus with a constant divisor? Maybe it could --- see the other discussion here about LEA --- but the developers just didn't bother to. I wish they would though, because despite how slow these instructions may be (which might not be the case), they are still valuable for size optimisation (-Os), and after all, it is a gap.
rwmj 10y ago
And the counterpoint is that some instructions that are commonly believed to be slow (eg. the string instructions like rep movs, lods, stos), are in fact fast on modern processors.
- nneonneo 10y ago
  Now I'm curious - do you have performance numbers somewhere for this? The rep instructions can actually be shorter than a call to str*, so if rep is actually fast enough then it might make a nice optimization.
  - rwmj 10y ago
    It depends if the strings are aligned or not, the size of the copy, and also on the generation of processor. There are some good answers here: http://stackoverflow.com/a/9177369 http://stackoverflow.com/a/9177369 https://stackoverflow.com/questions/12359228/reliable-information-about-x86-string-instruction-performance https://stackoverflow.com/questions/12359228/reliable-inform... https://stackoverflow.com/questions/8425022/performance-of-x86-rep-instructions-on-modern-pipelined-superscalar-processors https://stackoverflow.com/questions/8425022/performance-of-x...
  - veddan 10y ago
    Reasonably modern versions of GCC will emit various rep instructions in some cases. Some code I just compiled with GCC 6.1.1 had several snippets like this emitted for zeroing with memset: xor eax,eax ... rep stos QWORD PTR es:[rdi],rax and some rep movs for memcpy/memmove.
    - chkras 10y ago
      really? I wonder if the timing of rep and string instructions have improved at all?
      - userbinator 10y ago
        They operate on cacheline-sized pieces ever since the P6.
cptskippy 10y ago
Since P6, Intel's CPUs have used a RISC like core with a very heavy decoder that translates x86 CISC instructions to run on the internal ISA. With that in mind, do older or lesser used instructions actually perform poorly or are they just the wrong choice but actually preferred for other scenarios?
- mkup 10y ago
  According to [1], on recent Intel CPUs, each instruction is translated by hardware decoder to up to four micro-ops: either trivial micro-ops like addition, subtraction, bitwise and/or/xor, or a special "microcode assist" micro-op which is essentially a function call into the CPU microcode table. According to the same source, CPU microcode table is believed to consist roughly of 20,000 micro-ops which handle edge cases like rare instructions, rare prefixes, FPU denormals, traps/exceptions, all that stuff. Also, CPU microcode table is believed to contain full-blown implementations of RSA and SHA-256 in order to support microcode updates. So, yes, there's a performance gap between instructions with hardware fast path and ones which require a microcode assist. [1] https://eprint.iacr.org/2016/086.pdf https://eprint.iacr.org/2016/086.pdf
  - CyberDildonics 10y ago
    The new slides for AMD Zen say explicitly that it has hardware sha256 support.
    - majewsky 10y ago
      Careful. Do they mean an ISA extension to support fast SHA-256 implementations in your code, or do they have a SHA-256 implementation in their microcode for CPU-internal use?
      - CyberDildonics 10y ago
        I don't know and that goes beyond my point. The original poster said that it is rumored that Intel has a full implementation of sha256 in microcode. I am saying that AMD has confirmed that they at least have it in microcode.
deleted 10y ago
[deleted]

by api 10y ago

nneonneo 10y ago

Good examples of (essentially-deprecated) instructions include the rep prefixed instructions for string operations (modern library code for string operations typically involve a mixture of SSE, full-word loads and unrolled loops for speed); the "loop" instruction (compilers usually generate explicit loops for flexibility); pretty much all the BCD arithmetic instructions (since programming languages don't typically use BCD anymore), and many other such examples. The x86 architecture is chock-full of rarely-used legacy instructions that are mostly carried around for compatibility these days.

cfallin 10y ago
> the rep prefixed instructions for string operations ... are actually preferred over a hand-written vectorized loop on Ivy Bridge and up (see [1] section 3.7.7, "Enhanced REP MOVSB and STOSB operation (ERMSB)"). It's indicated by a CPUID feature flag bit (edit: grep for "erms" in /proc/cpuinfo to see this). The reason is that microcode knows more about the dcache microachitecture, load/store units, special features (weak ordering with fence at end? [2]), etc., than you do, and can be specially optimized for the particular design. There's a slight cost to transitioning to microcode and back (to ordinary hardware-decoded instructions), of course, so for small operations it might not be a win. The section cited above shows ERMSB as ~break-even vs. 128 bit AVX on Ivy Bridge from 128 bytes up to 2KB, and about 2% faster above that. [1] Intel 64 and IA-32 Architectures Optimization Reference Manual (order #248966-026), April 2012. http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf http://www.intel.com/content/dam/doc/manual/64-ia-32-archite... [2] http://stackoverflow.com/questions/33480999/how-can-the-rep-stosb-instruction-execute-faster-than-the-equivalent-loop http://stackoverflow.com/questions/33480999/how-can-the-rep-...
- olegolegovich 10y ago
  Do you have benchmarks, supporting "~break-even vs. 128 bit AVX on Ivy Bridge from 128 bytes up to 2KB" as I have not found it to be the case at least on Haskell (my benchmarking code is @ https://bitbucket.org/olegoandreev/scratch/src/dd7ab9008c59c8254dd5bdb4becae20457214c3f/memcpy-test/?at=default https://bitbucket.org/olegoandreev/scratch/src/dd7ab9008c59c...).
  - cfallin 10y ago
    I was just quoting the cited PDF ("the section cited above shows..."), which the author(s) did on Ivy Bridge. I haven't benchmarked it myself. It would be interesting to see how the most common cores today do on this...
- sounds 10y ago
  And by not having a group of hand-optimized special cases, the REP MOVSB and REP STOSB can be inlined saving instruction cache.
userbinator 10y ago
The BCD instructions, despite originally conceived for BCD, actually have some other niche uses such as AAM/AAD for a small multiply/divide: https://news.ycombinator.com/item?id=8477254 https://news.ycombinator.com/item?id=8477254 In that article I also further refute the common belief that they are significantly slower in this comment, by reasoning and then an actual benchmark: https://news.ycombinator.com/item?id=8477585 https://news.ycombinator.com/item?id=8477585 And this is where I think a gap between compilers and humans exist --- would a compiler recognise, for example, that if your code, for whatever reason, happened to have this pattern of operations in it... http://x86.renejeschke.de/html/file_module_x86_id_3.html http://x86.renejeschke.de/html/file_module_x86_id_3.html ...it should emit a single AAS instruction? Or perhaps a simpler example, would it know to emit an AAM for an 8-bit division or modulus with a constant divisor? Maybe it could --- see the other discussion here about LEA --- but the developers just didn't bother to. I wish they would though, because despite how slow these instructions may be (which might not be the case), they are still valuable for size optimisation (-Os), and after all, it is a gap.

rwmj 10y ago

And the counterpoint is that some instructions that are commonly believed to be slow (eg. the string instructions like rep movs, lods, stos), are in fact fast on modern processors.

nneonneo 10y ago
Now I'm curious - do you have performance numbers somewhere for this? The rep instructions can actually be shorter than a call to str*, so if rep is actually fast enough then it might make a nice optimization.
- rwmj 10y ago
  It depends if the strings are aligned or not, the size of the copy, and also on the generation of processor. There are some good answers here: http://stackoverflow.com/a/9177369 http://stackoverflow.com/a/9177369 https://stackoverflow.com/questions/12359228/reliable-information-about-x86-string-instruction-performance https://stackoverflow.com/questions/12359228/reliable-inform... https://stackoverflow.com/questions/8425022/performance-of-x86-rep-instructions-on-modern-pipelined-superscalar-processors https://stackoverflow.com/questions/8425022/performance-of-x...
- veddan 10y ago
  Reasonably modern versions of GCC will emit various rep instructions in some cases. Some code I just compiled with GCC 6.1.1 had several snippets like this emitted for zeroing with memset: xor eax,eax ... rep stos QWORD PTR es:[rdi],rax and some rep movs for memcpy/memmove.
  - chkras 10y ago
    really? I wonder if the timing of rep and string instructions have improved at all?
    - userbinator 10y ago
      They operate on cacheline-sized pieces ever since the P6.

cptskippy 10y ago

Since P6, Intel's CPUs have used a RISC like core with a very heavy decoder that translates x86 CISC instructions to run on the internal ISA. With that in mind, do older or lesser used instructions actually perform poorly or are they just the wrong choice but actually preferred for other scenarios?

mkup 10y ago
According to [1], on recent Intel CPUs, each instruction is translated by hardware decoder to up to four micro-ops: either trivial micro-ops like addition, subtraction, bitwise and/or/xor, or a special "microcode assist" micro-op which is essentially a function call into the CPU microcode table. According to the same source, CPU microcode table is believed to consist roughly of 20,000 micro-ops which handle edge cases like rare instructions, rare prefixes, FPU denormals, traps/exceptions, all that stuff. Also, CPU microcode table is believed to contain full-blown implementations of RSA and SHA-256 in order to support microcode updates. So, yes, there's a performance gap between instructions with hardware fast path and ones which require a microcode assist. [1] https://eprint.iacr.org/2016/086.pdf https://eprint.iacr.org/2016/086.pdf
- CyberDildonics 10y ago
  The new slides for AMD Zen say explicitly that it has hardware sha256 support.
  - majewsky 10y ago
    Careful. Do they mean an ISA extension to support fast SHA-256 implementations in your code, or do they have a SHA-256 implementation in their microcode for CPU-internal use?
    - CyberDildonics 10y ago
      I don't know and that goes beyond my point. The original poster said that it is rumored that Intel has a full implementation of sha256 in microcode. I am saying that AMD has confirmed that they at least have it in microcode.

deleted 10y ago

[deleted]