Recuerdo haber leído en alguna parte que es mejor usar enteros como variables de contador de bucle en lugar de char o corto. ¿Si es así por qué? ¿Proporciona algún beneficio de optimización?¿Es mejor utilizar enteros como variables de contador de bucle?
En general, el compilador hará que int sea un buen tamaño para colocarlo en uno de los registros de propósito general de su CPU. Eso generalmente conduce a un acceso rápido.
Por supuesto, no hay garantía de nada. El compilador es libre de hacer muchas cosas, entre ellas, supongo, promocionar parte de tu código que usa char a algún tipo más grande. Entonces la diferencia podría no importar.
En realidad, la respuesta que es cierto para su compilador, usted debe buscar en la asamblea emite.
En la arquitectura de 32 bits, las operaciones con 4 bytes (int) las variables suelen ser más rápidas. Esto se debe principalmente al tamaño de los registros y la alineación de la memoria. En la arquitectura de 64 bits, int (deberá) hacerse automáticamente un entero de 64 bits.
En general, se puede esperar que el tipo int sea el tipo de entero implementado más rápido en su plataforma y, por lo tanto, debe ser la opción predeterminada.
De K & R, 2da edición, p. 36:
int: un número entero, típicamente refleja el tamaño natural de números enteros en la máquina host.
Ah, nada como una generalización incorrecta allí. Puede implementar funciones trascendentales usando enteros, no será tan rápido como un flotador con un procesador de coma flotante. Además, una matriz de entradas donde los valores de la matriz se adaptarían a una char requeriría cuatro veces el ancho de banda de la memoria para procesar. – Skizz
Cambió eso al "tipo de entero implementado más rápido". –
Sería aún mejor utilizar el tipo size_t para contadores de bucle. Se escalará a 64 bits.
un bucle que hace 2^64-1 me asustaría: D –
no tiene que empezar desde 0 y terminar en el mayor valor posible x – fortran
Corremos comúnmente por encima de 2^31-1 en los próximos años. Es mucho mejor que nuestro código esté preparado para esto. –
En algunos casos, los problemas de desbordamiento con char s (o incluso short s) producirán bucles no terminales.
Alexey * es correcto, por lo general es más rápido usar un tipo que es la misma anchura que la arquitectura (es decir, int32 para un sistema de 32 bits)
Además, si se utiliza un char es decir
for(char i=0;i<max;++i)
hay una pequeña posibilidad de que usted (o un colega) va a volver al código de tiempo y el cambio de un mes como máximo a algo alto, causando un desbordamiento y un molesto error;)
Sam
* y todos los demás que respondieron mientras escribía esto!
¿Ha notado alguna vez cómo el estándar C es bastante dudoso sobre el tamaño de los enteros? Este hecho hace que los ingenieros de controladores de dispositivos y los que trabajan en protocolos de comunicaciones se pongan nerviosos porque creen que el lenguaje debe definir claramente el tamaño de los objetos.
C dice que int es el tamaño natural para la arquitectura de implementación. Eso significa que se manejará al menos tan eficientemente como cualquier otro tamaño. Tome la arquitectura x86: Un short (entero de 16 bits) utilizado en un programa de 32 bits contiene instrucciones que realizan una modificación adicional de "anulación de tamaño". Por lo tanto, el código tiene más bytes, aunque generalmente no hay penalización de rendimiento.A menos que los bytes adicionales causen un desbordamiento de la línea de caché ...
El código x86 generado para un contador char generalmente incluye enmascaramiento después del incremento para garantizar que permanezca en 8 bits. Puede parecer que el uso de una variable más pequeña sería más pequeño y más ajustado, pero ese no es el caso para x86, y varias otras CPU comunes.
Realmente depende de la plataforma que está escribiendo para codificar. El mejor tipo para usar es hacer coincidirlo con su plataforma. Es decir, si está escribiendo código para un simple micro de 8 bits, tal vez usar uint8_t es mejor que usar uint16_t.
Preocúpese de obtener sus bucles justo antes de preocuparse por esto. Es mucho más probable que tenga un error de uno por uno en los límites de bucle que una diferencia medible en la velocidad o el tamaño del código al cambiar el tipo del contador de bucle entre int, char o short. Así que preocúpate por la corrección primero.
Dicho eso, de forma predeterminada usa int o unsigned int a menos que tenga motivos para hacerlo de otra manera, pero lo digo porque es menos probable que tenga que preocuparse por el desbordamiento o porque no sea porque sea más rápido (aunque podría)
Realmente depende de lo que esté haciendo su ciclo. Tome este bucle, por ejemplo:
typedef struct _SomeData
{
/* some data here */
} SomeData;
void SomeFunction (SomeData *array_of_data, int number_of_elements)
{
int i;
for (i = 0 ; i < number_of_elements ; ++i)
{
DoSomethingWithData (&array_of_data [i]);
}
}
Algunos compiladores harán un buen trabajo al optimizar lo anterior. Pero algunos compiladores, especialmente compiladores para microprocesadores integrados de nicho, generarán códigos terriblemente ineficientes. Se puede volver a escribir como:
void SomeFunction (SomeData *array_of_data, int number_of_elements)
{
SomeData *current = array_of_data, *end = &array_of_data [number_of_elements];
while (current < end)
{
DoSomethingWithData (current++);
}
}
que no utiliza números enteros en absoluto y es más probable que genere un buen resultado independientemente del compilador (compiladores modernos son propensos a optimizar la versión número entero de algo parecido a la anterior de todas formas).
Por lo tanto, los enteros no siempre son necesarios para los bucles, y la mejor optimización siempre es no hacer algo que no sea necesario. Sin embargo, si el ciclo necesita explícitamente el entero, entonces el tipo int generalmente proporcionaría el mejor resultado.
Por supuesto, siempre debe usar un generador de perfiles para asegurarse del rendimiento del código y de si el cambio de tipo hace alguna diferencia.
Normalmente, int es la elección correcta para el bucle. Hay dos razones por las que podría no ser:
Así que, sí, puede que tenga que pensar en qué tamaño son los grandes, según su arquitectura. Pero por lo general no lo haces.
Tiene razón, pero hay muchos microcontroladores de 8 bits (mucho más que PC y servidores juntos), que no caben en un int en un solo registro. Tal vez un 'uint8_fast_t' es el mejor para el rendimiento – 12431234123412341234123