5 ms·

More than 1,500! Holy cow! While having instructions for everything that are slow in early models but can be significantly improved in silicon over time is one

More than 1,500! Holy cow! While having instructions for everything that are slow in early models but can be significantly improved in silicon over time is one way to look at CISC, I genuinely wonder how much silicon is spent on instructions that are so rarely used they'd be better in software. Or to ask another way: how many instructions are in billions of x86 cores that rarely if ever get used? Hmmm...

dreamcompiler 6y ago
I'd also be curious to discover how many distinct x86 instructions gcc can even emit? I expect the answer is "a lot less than all of them."
- kingsuper20 6y ago
  I mostly just think of the test set they must make use of at Intel. It makes my head hurt. Maybe you end up with a wad of legacy code so large that no one knows how it really works. That ends up being the real definition of the part.
- Someone 6y ago
  If you cheat: all of them. GCC supports in-line assembly. Of course, that’s not an interesting observation. It gets (somewhat) interesting when you realize that one may inadvertently include in-line assembly. Do you call including system headers that happen to contain inline assembly cheating? Including headers for a standard C library? Compiling with old-fashioned compiler flags (for example to generate FPU instructions for the x87)?
- saagarjha 6y ago
  Probably a couple hundred at most, and for common programs several dozen.
  - kijiki 6y ago
    Tried it out on Debian Bullseye x86_64: $ objdump -w -j .text --no-show-raw-insn -d /usr/bin/emacs-gtk | egrep '^ *[0-9]+:' | awk '{print $2}' | sort | uniq | wc -l 130 $ objdump -w -j .text --no-show-raw-insn -d /bin/ls | egrep '^ *[0-9]+:' | awk '{print $2}' | sort | uniq | wc -l 97 $ objdump -w -j .text --no-show-raw-insn -d firefox-bin | egrep '^ *[0-9]+:' | awk '{print $2}' | sort | uniq | wc -l 136
    - deleted 6y ago
      [deleted]
    - flukus 6y ago
      Wow thanks, this is exactly the type of comment I come to HN for. I wonder if the numbers would change significantly for gentoo or anything compiled manually that had more knowledge of the CPU specifics?
      - mjsir911 6y ago
        From my fairly riced gentoo system: $ objdump -w -j .text --no-show-raw-insn -d /usr/lib64/firefox/firefox-bin | egrep '^ \*[0-9]+:' | awk '{print $2}' | sort | uniq | wc -l 134 So actually, less!
thechao 6y ago
It's really more like 6000, if you do the accounting right. And, as someone who just ate a 2x (customer-facing) slow down porting a piece of x86 assembly to ARM, because that "one nifty instruction" was missing, I'm going to say: we should keep all of 'em.
- mhh__ 6y ago
  Which one?
  - thechao 6y ago
    _mm256_movemask_epi8, i.e., the "fast lexer" instruction. That instruction takes ~3c (depending on uarch), and the ARM equivalent (7-8 instructions) takes ~5-6c (depending on uarch). It's just annoying.
    - ConcernedCoder 6y ago
      This instruction does quite a bit of leg work, and it becomes obvious why a RISK architecture would need 7-8 instructions to do the same, see: https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm256_movemask_epi8&expand=3865 https://software.intel.com/sites/landingpage/IntrinsicsGuide...
      - irdc 6y ago
        This looks like a task for gorc: https://five-embeddev.com/riscv-bitmanip/draft/bext.html#generalized-or-combine-gorc-gorci https://five-embeddev.com/riscv-bitmanip/draft/bext.html#gen... (granted, that’s only 32/64 bits, but still…)
    - glangdale 6y ago
      PMOVMSKB is a great instruction, and 3c understates how cheap it is - if you have a throughput problem (rather than a latency problem) it's even more efficient relative to the ARM equivalent. I have a blog post about coping strategies for working around the absence of PMOVMSKB on NEON: https://branchfree.org/2019/04/01/fitting-my-head-through-the-arm-holes-or-two-sequences-to-substitute-for-the-missing-pmovmskb-instruction-on-arm-neon/ https://branchfree.org/2019/04/01/fitting-my-head-through-th... We used these techniques in simdjson (which I presume still uses them; the code has changed considerably since I built this): https://github.com/simdjson/simdjson https://github.com/simdjson/simdjson The best techniques for mitigating the absence of PMOVMSKB require that you use LD4, which results in interleaved inputs. This can sometimes make things easier, sometimes harder for your underlying lexing algorithm - sadly, it's not a 1:1 transformation of the original x86 code.
CodeArtisan 6y ago
AMD Zen dropped a few instructions sets from the previous architecture. FMA4 https://en.wikipedia.org/wiki/FMA_instruction_set#FMA4_instruction_set https://en.wikipedia.org/wiki/FMA_instruction_set#FMA4_instr... XOP https://en.wikipedia.org/wiki/XOP_instruction_set https://en.wikipedia.org/wiki/XOP_instruction_set TBM https://en.wikipedia.org/wiki/Bit_manipulation_instruction_set#TBM https://en.wikipedia.org/wiki/Bit_manipulation_instruction_s...

dreamcompiler 6y ago

I'd also be curious to discover how many distinct x86 instructions gcc can even emit? I expect the answer is "a lot less than all of them."

kingsuper20 6y ago
I mostly just think of the test set they must make use of at Intel. It makes my head hurt. Maybe you end up with a wad of legacy code so large that no one knows how it really works. That ends up being the real definition of the part.
Someone 6y ago
If you cheat: all of them. GCC supports in-line assembly. Of course, that’s not an interesting observation. It gets (somewhat) interesting when you realize that one may inadvertently include in-line assembly. Do you call including system headers that happen to contain inline assembly cheating? Including headers for a standard C library? Compiling with old-fashioned compiler flags (for example to generate FPU instructions for the x87)?
saagarjha 6y ago
Probably a couple hundred at most, and for common programs several dozen.
- kijiki 6y ago
  Tried it out on Debian Bullseye x86_64: $ objdump -w -j .text --no-show-raw-insn -d /usr/bin/emacs-gtk | egrep '^ *[0-9]+:' | awk '{print $2}' | sort | uniq | wc -l 130 $ objdump -w -j .text --no-show-raw-insn -d /bin/ls | egrep '^ *[0-9]+:' | awk '{print $2}' | sort | uniq | wc -l 97 $ objdump -w -j .text --no-show-raw-insn -d firefox-bin | egrep '^ *[0-9]+:' | awk '{print $2}' | sort | uniq | wc -l 136
  - deleted 6y ago
    [deleted]
  - flukus 6y ago
    Wow thanks, this is exactly the type of comment I come to HN for. I wonder if the numbers would change significantly for gentoo or anything compiled manually that had more knowledge of the CPU specifics?
    - mjsir911 6y ago
      From my fairly riced gentoo system: $ objdump -w -j .text --no-show-raw-insn -d /usr/lib64/firefox/firefox-bin | egrep '^ \*[0-9]+:' | awk '{print $2}' | sort | uniq | wc -l 134 So actually, less!

thechao 6y ago

It's really more like 6000, if you do the accounting right. And, as someone who just ate a 2x (customer-facing) slow down porting a piece of x86 assembly to ARM, because that "one nifty instruction" was missing, I'm going to say: we should keep all of 'em.

mhh__ 6y ago
Which one?
- thechao 6y ago
  _mm256_movemask_epi8, i.e., the "fast lexer" instruction. That instruction takes ~3c (depending on uarch), and the ARM equivalent (7-8 instructions) takes ~5-6c (depending on uarch). It's just annoying.
  - ConcernedCoder 6y ago
    This instruction does quite a bit of leg work, and it becomes obvious why a RISK architecture would need 7-8 instructions to do the same, see: https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm256_movemask_epi8&expand=3865 https://software.intel.com/sites/landingpage/IntrinsicsGuide...
    - irdc 6y ago
      This looks like a task for gorc: https://five-embeddev.com/riscv-bitmanip/draft/bext.html#generalized-or-combine-gorc-gorci https://five-embeddev.com/riscv-bitmanip/draft/bext.html#gen... (granted, that’s only 32/64 bits, but still…)
  - glangdale 6y ago
    PMOVMSKB is a great instruction, and 3c understates how cheap it is - if you have a throughput problem (rather than a latency problem) it's even more efficient relative to the ARM equivalent. I have a blog post about coping strategies for working around the absence of PMOVMSKB on NEON: https://branchfree.org/2019/04/01/fitting-my-head-through-the-arm-holes-or-two-sequences-to-substitute-for-the-missing-pmovmskb-instruction-on-arm-neon/ https://branchfree.org/2019/04/01/fitting-my-head-through-th... We used these techniques in simdjson (which I presume still uses them; the code has changed considerably since I built this): https://github.com/simdjson/simdjson https://github.com/simdjson/simdjson The best techniques for mitigating the absence of PMOVMSKB require that you use LD4, which results in interleaved inputs. This can sometimes make things easier, sometimes harder for your underlying lexing algorithm - sadly, it's not a 1:1 transformation of the original x86 code.

CodeArtisan 6y ago

AMD Zen dropped a few instructions sets from the previous architecture. FMA4 https://en.wikipedia.org/wiki/FMA_instruction_set#FMA4_instruction_set https://en.wikipedia.org/wiki/FMA_instruction_set#FMA4_instr... XOP https://en.wikipedia.org/wiki/XOP_instruction_set https://en.wikipedia.org/wiki/XOP_instruction_set TBM https://en.wikipedia.org/wiki/Bit_manipulation_instruction_set#TBM https://en.wikipedia.org/wiki/Bit_manipulation_instruction_s...