¿Cuál es más rápido: Int64 o Int8?

Según tengo entendido, basado en int32 vs int8 en la arquitectura de 32 bits, es que el ancho de bits nativo del procesador siempre es el más rápido. Los registros son todos de 64 bits en el i7, por lo que si intenta una operación de 8 bits, debe extraer un número de 64 bits de la RAM o caché, enmascarar los bits relevantes, realizar la operación y luego escribir el byte . 64 bits es más simple (fetch, bitwise op, replace), por lo que debería ser más rápido. Los números de 64 bits siempre deben estar correctamente alineados también.

Sin embargo, definitivamente probaría esto escribiendo un código simple “Do [blah] 100,000,000 times” para ambos casos, simplemente porque los compiladores tienen la costumbre de optimizar lo que estamos tratando de hacer mejor de lo que optimizamos debido a lo que creemos que somos ¡Intentando hacer!

¿Me puede decir por qué prefiere creer una opinión dada aquí sobre la medición de la velocidad del código real en una máquina real?

Lo cual es una forma gruñona de decir: no hay nada intrínsecamente más rápido o más lento sobre uint64_t u uint8_t . El código que usa esos tipos de datos tendrá interacciones con cachés de datos, cachés de instrucciones, predictores de ramificación, programadores de instrucciones y (por efectos de segundo orden) la frecuencia del reloj de la CPU. No puede simplemente mirar el código y predecir con una certeza razonable que será más rápido (y ni siquiera nos ha dado el código para que lo veamos).

Simplemente ejecute ambos y mida. Terminarás con una respuesta que sea definitiva y correcta.

NB: supongo que te refieres a una matriz de 8 uint8_t -s. Eso te daría un objeto de 64 bits.

Debería echar un vistazo a y uint_64fast_t en particular.

uint_64fast_t está destinado a ser el tipo entero sin signo más rápido de al menos 64 bits.

Es poco probable que pueda implementar un número entero sin signo de mayor rendimiento ‘encadenando’ tipos más pequeños juntos. Debe manejar el desbordamiento y el desbordamiento en el código. C ni siquiera da ningún acceso formal a un indicador de acarreo (que probablemente exista en la CPU) y ciertamente estaría profundizando en el ensamblador (no portátil).

Sin duda, debe investigar cómo se implementa uint_64fast_t en su (s) plataforma (s) de destino. pero en cualquier plataforma plausible de 64 bits no tiene la posibilidad de superar en código lo que hará la CPU en una sola instrucción. En plataformas más pequeñas, es probable que la CPU proporcione algún soporte intrínseco para esto y tal vez, solo tal vez, pueda encontrar una manera de reducir un poco la versión del compilador, pero es poco probable.

En general, la operación más rápida ocurre si el tamaño de los datos es igual a la palabra máquina. Entonces, si usa el código de 32 bits, Int32 será el más rápido. Si su código es de 64 bits, entonces Int64. Pero esta es una gran simplificación de la situación real. Por ejemplo, tiene comandos mmx / sse / avx incluso en modo de 32 bits para la arquitectura Intel que opera enteros de 128 bits.

Bien. Puedo proporcionar algunas inferencias … cuando trabajo con instrucciones simd sse … tiendo a evitar datos de bytes. son muy lentos y desperdician el ciclo del reloj. reducir la eficiencia

32 y 64 int. son buenos

pero la computadora moderna solo procesará eficientemente los datos si están alineados en caché. como simd sse necesita 16 bytes vectores 4d alineados … que pueden ser 4 flotantes 2 dobles 4 int16 o 1 int64 ….

pero las operaciones escalares no alineadas son una mierda en comparación con las operaciones alineadas … aún mis opiniones … se necesita otro consejo experto …

Si no está seguro de cómo desea manipular sus datos, simplemente use una unión con los tipos uint8_t [8] y uint64_t / uint64fast_t. En teoría, una máquina de 8 bits puede ser más rápida ya que la suma es innatamente O (n) para la lógica de transporte. En el mundo real, su CPU, compilador e ISA realmente no harán mucho para apoyar esa teoría y probablemente no verá un aumento en el rendimiento. En todo caso, la lógica de bloqueo para manejar una matriz de uint8_t probablemente ralentizará su código.

La única forma de averiguarlo es implementarlo en ambos sentidos y perfilarlo.

Aunque supongo que el único int64 probablemente será más rápido que int8 [4] a menos que la operación realmente siga los límites de bytes.

¿Más rápido para qué?

Puede dejar que el compilador decida usando uint_fast8_t