In short - endless battle between RISC or CISC.
Endless? It ended a long time ago. RISC won.
There hasn't been any new CISC architecture worth mentioning in decades.
How many x86 instructions are there? (2016)
81–90 of 92 posts
Re: How many x86 instructions are there? (2016)
#82Re: How many x86 instructions are there? (2016)
#83Earlier quoted context omitted.
_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 .
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-th... We used these techniques in simdjson (which I presume still uses them…
Yep. My use-case is from your work. Brilliant stuff!
Re: How many x86 instructions are there? (2016)
#84Earlier quoted context omitted.
Probably a couple hundred at most, and for common programs several dozen.
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
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?
Re: How many x86 instructions are there? (2016)
#85Earlier quoted context omitted.
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
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?
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
Re: How many x86 instructions are there? (2016)
#86Earlier quoted context omitted.
It's not that variable length is expensive, it's that variable length the way Intel does it is expensive. For instance — not that this is a good idea — you could burn the top 2b to mark instructions as 2/4/6/8 bytes (or whatever) in length. Then you can have your variable-width-cake-and-eat-your-fast-decode-too.
> you could burn the top 2b to mark instructions as 2/4/6/8 bytes (or whatever) in length. FWIW, this is exactly what RISC-V does.
How is this so? I thought RISC-V was fixed length, except for 16 bit compressed instructions. And afaik those aren't identified by a singular particular bit.
Re: How many x86 instructions are there? (2016)
#87Earlier quoted context omitted.
> you could burn the top 2b to mark instructions as 2/4/6/8 bytes (or whatever) in length. FWIW, this is exactly what RISC-V does.
How is this so? I thought RISC-V was fixed length, except for 16 bit compressed instructions. And afaik those aren't identified by a singular particular bit.
See section 1.5 ("Base Instruction-Length Encoding") of the RISC-V spec. It's actually a bit more complex than just using 2 bits (I had forgotten those details), but the basic idea is the same in that there is a fixed cascade of bits identifying the instruction length.
There aren't any standard extensions with instructions >32b yet, but the extensibility is there in the base spec.
Re: How many x86 instructions are there? (2016)
#88Earlier quoted context omitted.
_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 .
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-th... We used these techniques in simdjson (which I presume still uses them…
Have you had a chance to experiment with the SVE and/or AVX512 mask systems, yet?
Re: How many x86 instructions are there? (2016)
#89How about undocumented instructions? Sandsifter[1] is an interesting project and the video from BlackHat[2] is a good watch. There's also a previous discussion of it on HN[3]. [1] https://github.com/Battelle/sandsifter [2] https://www.youtube.com/watch?v=KrksBdWcZgQ [3] https://news.ycombinator.com/item?id=18179212
Also see https://blog.can.ac/2021/03/22/speculating-x86-64-isa-with-o...
Ah cool, seems I missed that when it appeared on HN a few weeks back. Thanks for the pointer.
Re: How many x86 instructions are there? (2016)
#90Earlier quoted context omitted.
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-th... We used these techniques in simdjson (which I presume still uses them…
Have you had a chance to experiment with the SVE and/or AVX512 mask systems, yet?
No and yes, respectively.
I'm somewhat curmudgeonly w.r.t. SVE, insisting that while the sole system in existence is a HPC machine from Fujitsu, that for practical purposes it doesn't really exist and isn't worth learning. I will likely revise this opinion when ARM vendors decide to ship something (likely soon, by most roadmaps). There's only so much space in my brain.
AVX-512's masks are OK. They're quite cheap. There are some infelicities. I was irate to discover that you can't do logic ops on 8b/16b lanes with masking; as usual the 32b/64b mafia strike again. This may be a symptom of AVX-512's origin with Knights*.
It would be nice if the explicit mask operations were cheaper. Unfortunately, they crowd out SIMD operations. I suppose this is inevitable given that they need to have physical proximity to their units - so explicit mask ops are on the same ports as the SIMD ops.
I also wish that there were 512b compares that produced zmm registers like the old compares used to; sometimes that's the behavior you want. However, you can reconstruct that in another cheap operation iirc.