0
354
Views¿Por qué los tipos de enteros rápidos son más rápidos que los otros tipos de enteros?
En ISO/IEC 9899:2018 (C18), se establece en 7.20.1.3:
7.20.1.3 Tipos enteros de ancho mínimo más rápidos
1 Cada uno de los siguientes tipos designa un tipo de entero que suele ser el 268) más rápido para operar entre todos los tipos de enteros que tienen al menos el ancho especificado.
2 El nombre typedef
int_fastN_tdesigna el tipo de entero con signo más rápido con un ancho de al menos N. El nombre typedefuint_fastN_tdesigna el tipo de entero sin signo más rápido con un ancho de al menos N.3 Se requieren los siguientes tipos:
int_fast8_t,int_fast16_t,int_fast32_t,int_fast64_t,uint_fast8_t,uint_fast16_t,uint_fast32_t,uint_fast64_tTodos los demás tipos de este formulario son opcionales.
268) No se garantiza que el tipo designado sea el más rápido a todos los efectos; si la implementación no tiene motivos claros para elegir un tipo sobre otro, simplemente elegirá algún tipo entero que satisfaga los requisitos de firma y ancho.
Pero no se indica por qué estos tipos de enteros "rápidos" son más rápidos.
- ¿Por qué estos tipos de enteros rápidos son más rápidos que los otros tipos de enteros?
Etiqueté la pregunta con C++, porque los tipos de enteros rápidos también están disponibles en C++17 en el archivo de encabezado de cstdint . Desafortunadamente, en ISO/IEC 14882:2017 (C++17) no existe tal sección sobre su explicación; Había implementado esa sección de otra manera en el cuerpo de la pregunta.
Información: En C, se declaran en el archivo de encabezado de stdint.h .
3 answers
Answer question0
Imagine una CPU que realiza solo operaciones aritméticas de 64 bits. Ahora imagine cómo implementaría una adición de 8 bits sin firmar en dicha CPU. Necesariamente implicaría más de una operación para obtener el resultado correcto. En dicha CPU, las operaciones de 64 bits son más rápidas que las operaciones en otros anchos de enteros. En esta situación, todo Xint_fastY_t presumiblemente podría ser un alias del tipo de 64 bits.
Si una CPU admite operaciones rápidas para tipos enteros estrechos y, por lo tanto, un tipo más ancho no es más rápido que uno más estrecho, entonces Xint_fastY_t no será (no debería) ser un alias del tipo más ancho que el necesario para representar todos los bits Y.
Por curiosidad, verifiqué los tamaños en una implementación particular (GNU, Linux) en algunas arquitecturas. Estos no son los mismos en todas las implementaciones en la misma arquitectura:
┌────╥───────────────────────────────────────────────────────────┐ │ Y ║ sizeof(Xint_fastY_t) * CHAR_BIT │ │ ╟────────┬─────┬───────┬─────┬────────┬──────┬────────┬─────┤ │ ║ x86-64 │ x86 │ ARM64 │ ARM │ MIPS64 │ MIPS │ MSP430 │ AVR │ ╞════╬════════╪═════╪═══════╪═════╪════════╪══════╪════════╪═════╡ │ 8 ║ 8 │ 8 │ 8 │ 32 │ 8 │ 8 │ 16 │ 8 │ │ 16 ║ 64 │ 32 │ 64 │ 32 │ 64 │ 32 │ 16 │ 16 │ │ 32 ║ 64 │ 32 │ 64 │ 32 │ 64 │ 32 │ 32 │ 32 │ │ 64 ║ 64 │ 64 │ 64 │ 64 │ 64 │ 64 │ 64 │ 64 │ └────╨────────┴─────┴───────┴─────┴────────┴──────┴────────┴─────┘Tenga en cuenta que aunque las operaciones en los tipos más grandes pueden ser más rápidas, estos tipos también ocupan más espacio en la memoria caché y, por lo tanto, usarlos no necesariamente produce un mejor rendimiento. Además, uno no siempre puede confiar en que la implementación haya tomado la decisión correcta en primer lugar. Como siempre, se requiere medir para obtener resultados óptimos.
Captura de pantalla de la tabla, para usuarios de Android:
(Android no tiene caracteres de dibujo de cuadro en la fuente mono - ref )
0
No lo son, al menos no de forma fiable.
Los tipos rápidos son simplemente typedefs para tipos regulares, sin embargo, depende de la implementación cómo definirlos. Deben ser al menos del tamaño solicitado, pero pueden ser más grandes.
Es cierto que en algunas arquitecturas, algunos tipos de enteros tienen un mejor rendimiento que otros. Por ejemplo, las primeras implementaciones de ARM tenían instrucciones de acceso a la memoria para palabras de 32 bits y bytes sin firmar, pero no tenían instrucciones para medias palabras o bytes con signo. Las instrucciones de media palabra y byte con signo se agregaron más tarde, pero aún tienen opciones de direccionamiento menos flexibles, porque tuvieron que calzarse en el espacio de codificación libre. Además, todas las instrucciones de procesamiento de datos reales en ARM funcionan con palabras, por lo que en algunos casos puede ser necesario enmascarar valores más pequeños después del cálculo para obtener resultados correctos.
Sin embargo, también existe la preocupación competitiva de la presión de caché, incluso si se necesitan más instrucciones para cargar/almacenar/procesar un valor más pequeño. El valor más pequeño aún puede funcionar mejor si reduce la cantidad de errores de caché.
Las definiciones de los tipos en muchas plataformas comunes no parecen haber sido pensadas. En particular, las plataformas modernas de 64 bits tienden a tener un buen soporte para enteros de 32 bits, sin embargo, los tipos "rápidos" a menudo son innecesariamente de 64 bits en estas plataformas.
Además, los tipos en C pasan a formar parte de la ABI de la plataforma. Entonces, incluso si un proveedor de la plataforma descubre que tomó decisiones tontas, es difícil cambiar esas decisiones tontas más adelante.
Ignore los tipos "rápidos". Si está realmente preocupado por el rendimiento de los enteros, compare su código con todos los tamaños disponibles.
0
Los tipos rápidos no son más rápidos que todos los demás tipos de enteros; de hecho, son idénticos a algún tipo de entero "normal" (son solo un alias para ese tipo), cualquiera que sea el tipo más rápido para mantener un valor de al menos esa cantidad de bits.
Solo depende de la plataforma para qué tipo de entero es un alias cada tipo rápido.