3 ms·

Article might raise an interesting question, but the methodology used to determine if his system's binaries use the entire available set of instructions is dubi

by chungy 4y ago

Article might raise an interesting question, but the methodology used to determine if his system's binaries use the entire available set of instructions is dubious at best. He doesn't describe what operating system or distribution he is running, or how the binaries were built at all. If it's on Gentoo with all the optimization settings tweaked out, it may be useful data. If it's on something like Debian where binaries are built to a lowest common denominator, that's... much less useful.

johannes1234321 4y ago
> If it's on something like Debian where binaries are built to a lowest common denominator, that's... much less useful. Depending on the point one wants to make. Only very few people will run maxed out Gentoo builds, but there is a huge number of people running debian and red hat derived distributions. Thus findings there represent what is in broad use.
nwallin 4y ago
On my Gentoo system with `-march=znver2` and `-ftree-vectorize` set, I ran: find /usr/bin /usr/lib64 -type f -executable -or -name '*.so*' -exec objdump -d '{}' + | cut -f3 | grep -oE "^[a-z]+" | sort | uniq -c Which should find all executables and shared libraries. It found 1174 instructions. So ballpark 3 times as many instructions as on his system, and twice as many as the number of instructions he claims to exist. So you're right; suffice to say his methodology has some holes in it. Interestingly xor got dropped from 6th place on his list to 11th on mine. My list upgraded jmp to 4th place: above 5th place je, which surprised me. His objdump calling convention appears to be different than mind; he's seeing the `callq`, `jmpq`, and `retq` instructions, I get `call`, `jmp`, and `ret`. I don't know what that means.
- stefantalpalaru 4y ago
- adrian_b 4y ago
  The mnemonics ending in -q just specify explicitly that they are 64-bit (quad-word, where "word" was 16-bit on Intel 8088) instructions, while the size of the mnemonics without -q is specified implicitly by a previous assembler directive. Also on a Gentoo system, even when searching just on /usr/bin I have seen a result similar to yours, with plenty of AVX instructions. This is expected, because our executables have been compiled for a modern CPU, while those of the author have been compiled for a generic 64-bit CPU, i.e. 20-years old. The high frequency of "jmp", which I have noticed too, can come e.g. from a higher proportion of "if ... else ..." versus simple "if", or from a higher proportion of "switch" versus "if", or from some compiler that does tail-call optimization. The methodology is OK for determining the static frequency of instructions, which determines the size of a program. The dynamic frequency of instructions, which influences the execution time, can be very different, because many computational instructions are mostly used either in loops or in frequently invoked functions, so their static frequency can be orders of magnitude less than their dynamic frequency. To the one-liner it is convenient to add at the end " | sort -n ", to get the list of mnemonics already sorted by frequency.

by chungy 4y ago

johannes1234321 4y ago

> If it's on something like Debian where binaries are built to a lowest common denominator, that's... much less useful. Depending on the point one wants to make. Only very few people will run maxed out Gentoo builds, but there is a huge number of people running debian and red hat derived distributions. Thus findings there represent what is in broad use.

nwallin 4y ago

On my Gentoo system with `-march=znver2` and `-ftree-vectorize` set, I ran: find /usr/bin /usr/lib64 -type f -executable -or -name '*.so*' -exec objdump -d '{}' + | cut -f3 | grep -oE "^[a-z]+" | sort | uniq -c Which should find all executables and shared libraries. It found 1174 instructions. So ballpark 3 times as many instructions as on his system, and twice as many as the number of instructions he claims to exist. So you're right; suffice to say his methodology has some holes in it. Interestingly xor got dropped from 6th place on his list to 11th on mine. My list upgraded jmp to 4th place: above 5th place je, which surprised me. His objdump calling convention appears to be different than mind; he's seeing the `callq`, `jmpq`, and `retq` instructions, I get `call`, `jmp`, and `ret`. I don't know what that means.

stefantalpalaru 4y ago
adrian_b 4y ago
The mnemonics ending in -q just specify explicitly that they are 64-bit (quad-word, where "word" was 16-bit on Intel 8088) instructions, while the size of the mnemonics without -q is specified implicitly by a previous assembler directive. Also on a Gentoo system, even when searching just on /usr/bin I have seen a result similar to yours, with plenty of AVX instructions. This is expected, because our executables have been compiled for a modern CPU, while those of the author have been compiled for a generic 64-bit CPU, i.e. 20-years old. The high frequency of "jmp", which I have noticed too, can come e.g. from a higher proportion of "if ... else ..." versus simple "if", or from a higher proportion of "switch" versus "if", or from some compiler that does tail-call optimization. The methodology is OK for determining the static frequency of instructions, which determines the size of a program. The dynamic frequency of instructions, which influences the execution time, can be very different, because many computational instructions are mostly used either in loops or in frequently invoked functions, so their static frequency can be orders of magnitude less than their dynamic frequency. To the one-liner it is convenient to add at the end " | sort -n ", to get the list of mnemonics already sorted by frequency.