c - imagen - meta keywords google
¿Cuál es la diferencia entre intXX_t e int_fastXX_t? (4)
Recientemente descubrí la existencia del tipo estándar más rápido , principalmente int_fast32_t e int_fast64_t .
Siempre me dijeron que, para un uso normal en la arquitectura convencional, uno debería usar el int & long clásico, que siempre debería ajustarse a la capacidad de lectura predeterminada del procesador y así evitar las conversiones numéricas inútiles.
En el estándar C99, dice en §7.18.1.3p2:
"El nombre typedef int_fastN_t designa el tipo de entero con signo más rápido con un ancho de al menos N. El nombre typedef uint_fastN_t designa el tipo entero sin signo más rápido con un ancho de al menos N."
Y también hay una cita al respecto en §7.18.1.3p1:
"No se garantiza que el tipo designado sea el más rápido para todos los propósitos: si la implementación no tiene motivos claros para elegir un tipo sobre otro, simplemente seleccionará un tipo de número entero que satisfaga los requisitos de signatura y ancho".
No está claro para mí lo que realmente significa el más rápido . No entiendo cuándo debería usar este tipo y cuándo no.
He investigado un poco sobre esto y descubrí que algunos projects source projects han cambiado algunas de sus funciones, pero no todos. Realmente no explicaron por qué han cambiado una parte, y solo una parte, de su código.
¿Sabes cuáles son los casos / usos específicos cuando int_fastXX_t son realmente más rápidos que los clásicos?
En el estándar C99, 7.18.1.3 tipos enteros de ancho mínimo más rápidos.
(7.18.1.3p1) "Cada uno de los siguientes tipos designa un tipo entero que generalmente es el más rápido225) para operar con todos los tipos de enteros que tienen al menos el ancho especificado."
225) "No se garantiza que el tipo designado sea el más rápido para todos los fines: si la implementación no tiene motivos claros para elegir un tipo sobre otro, simplemente seleccionará un tipo de número entero que satisfaga los requisitos de signatura y ancho".
y
(7.18.1.3p2) "El nombre de typedef int_fastN_t designa el tipo de entero con signo más rápido con un ancho de al menos N. El nombre de typedef uint_fastN_t designa el tipo entero sin signo más rápido con un ancho de al menos N."
Los tipos int_fastN_t y uint_fastN_t son contrapartes de los tipos enteros de ancho exacto intN_t y uintN_t . La implementación garantiza que toman al menos N bits, pero la implementación puede tomar más bits si puede realizar la optimización utilizando tipos más grandes; solo garantiza que toman al menos N bits.
Por ejemplo, en una máquina de 32 bits, uint_fast16_t podría definirse como un unsigned int lugar de un unsigned short porque trabajar con tipos de tamaño de palabra de la máquina sería más eficiente.
Otra razón de su existencia es que los tipos enteros de ancho exacto son opcionales en C, pero se requieren los tipos enteros de ancho mínimo más rápidos y los tipos enteros de ancho mínimo ( int_leastN_t y uint_leastN_t ).
Gnu libc defines {int, uint} _fast {16,32} _t como de 64 bits al compilar para CPU de 64 bits y de otra manera de 32 bits. Las operaciones en enteros de 64 bits son más rápidas en las CPU Intel y AMD de 64 bits x86 que las mismas operaciones en enteros de 32 bits.
IMO son bastante inútiles.
Al compilador no le importa lo que usted llame un tipo, solo qué tamaño es y qué reglas se aplican a él. así que si int, in32_t e int_fast32_t son todos 32 bits en su plataforma, casi con seguridad todos realizarán lo mismo.
La teoría es que los implementadores del lenguaje deberían elegir según lo que sea más rápido en su hardware, pero los escritores estándar nunca definieron una definición clara de la más rápida. Agregue eso al hecho de que los mantenedores de la plataforma son reacios a cambiar la definición de tales tipos (porque sería una ruptura ABI) y las definiciones terminan escogidas arbitrariamente al inicio de la vida de una plataforma (o heredada de otras plataformas que la biblioteca C portado desde) y nunca volvió a tocar.
Si se encuentra en el nivel de micro-optimización que cree que el tamaño variable puede marcar una diferencia significativa, compare las diferentes opciones con su código en su procesador. De lo contrario, no te preocupes por eso. Los tipos "rápidos" no agregan nada útil IMO.
Probablemente no haya una diferencia, excepto en hardware exótico donde int32_t e int16_t ni siquiera existen.
En ese caso, puede usar int_least16_t para obtener el tipo más pequeño que puede contener 16 bits. Podría ser importante si quieres ahorrar espacio.
Por otro lado, usar int_fast16_t puede obtener otro tipo, más grande que int_least16_t pero posiblemente más rápido para el uso de entero "típico". La implementación tendrá que considerar qué es más rápido y qué es típico. Tal vez esto es obvio para algunos hardware de propósito especial?
En la mayoría de las máquinas comunes, estos tipos de 16 bits serán un tipo def para short , y usted no tiene que molestarse.