Me gustaría estar de acuerdo con Brian aquí, y con Wouter y pjc50.
También me gustaría agregar que para propósitos generales, especialmente CISC, procesadores, las instrucciones no tienen el mismo rendimiento: una operación complicada podría tomar más ciclos que una fácil.
Considere X86: AND
(que es una operación "y") es probablemente muy rápido. Lo mismo vale para NOT
. Veamos un poco de desmontaje:
Codigo de entrada:
#include <immintrin.h>
#include <stdint.h>
__m512i nand512(__m512i a, __m512i b){return ~(a&b);}
__m256i nand256(__m256i a, __m256i b){return ~(a&b);}
__m128i nand128(__m128i a, __m128i b){return ~(a&b);}
uint64_t nand64(uint64_t a, uint64_t b){return ~(a&b);}
uint32_t nand32(uint32_t a, uint32_t b){return ~(a&b);}
uint16_t nand16(uint16_t a, uint16_t b){return ~(a&b);}
uint8_t nand8(uint8_t a, uint8_t b){return ~(a&b);}
Comando para producir ensamblaje:
gcc -O3 -c -S -mavx512f test.c
Conjunto de salida (acortado):
.file "test.c"
nand512:
.LFB4591:
.cfi_startproc
vpandq %zmm1, %zmm0, %zmm0
vpternlogd $0xFF, %zmm1, %zmm1, %zmm1
vpxorq %zmm1, %zmm0, %zmm0
ret
.cfi_endproc
nand256:
.LFB4592:
.cfi_startproc
vpand %ymm1, %ymm0, %ymm0
vpcmpeqd %ymm1, %ymm1, %ymm1
vpxor %ymm1, %ymm0, %ymm0
ret
.cfi_endproc
nand128:
.LFB4593:
.cfi_startproc
vpand %xmm1, %xmm0, %xmm0
vpcmpeqd %xmm1, %xmm1, %xmm1
vpxor %xmm1, %xmm0, %xmm0
ret
.cfi_endproc
nand64:
.LFB4594:
.cfi_startproc
movq %rdi, %rax
andq %rsi, %rax
notq %rax
ret
.cfi_endproc
nand32:
.LFB4595:
.cfi_startproc
movl %edi, %eax
andl %esi, %eax
notl %eax
ret
.cfi_endproc
nand16:
.LFB4596:
.cfi_startproc
andl %esi, %edi
movl %edi, %eax
notl %eax
ret
.cfi_endproc
nand8:
.LFB4597:
.cfi_startproc
andl %esi, %edi
movl %edi, %eax
notl %eax
ret
.cfi_endproc
Como puede ver, para los tipos de datos de tamaño inferior a 64, las cosas simplemente se manejan como largas (de ahí el yl y no l ), ya que ese es el ancho de bits "nativo" de mi compilador, como parece.
El hecho de que haya mov
s en el medio solo se debe al hecho de que eax
es el registro que contiene el valor de retorno de una función. Normalmente, solo calcularía en el edi
registro de propósito general para calcular con el resultado.
Para 64 bits, es lo mismo, solo con q
palabras "quad" (por lo tanto, finales ) y rax
/ en rsi
lugar de eax
/ edi
.
Parece que para operandos de 128 bits y mayores, a Intel no le importó implementar una operación "no"; en su lugar, el compilador produce un 1
registro completo (autocomparación del registro consigo mismo, el resultado almacenado en el registro con la vdcmpeqd
instrucción), y xor
eso.
En resumen: al implementar una operación complicada con múltiples instrucciones elementales, no necesariamente se ralentiza la operación; simplemente no hay ventaja en tener una instrucción que haga el trabajo de múltiples instrucciones si no es más rápida.