18 votos

¿Cuál sería el tamaño ideal del buffer?

Posible duplicado:
¿Cómo se determina el tamaño ideal de la memoria intermedia al usar FileInputStream?

Cuando se leen los datos en bruto de un archivo (o cualquier flujo de entrada) usando los C++'s istream de la familia read() o C's fread() un buffer tiene que ser suministrado, y una cantidad de datos a leer. La mayoría de los programas que he visto parecen elegir arbitrariamente una potencia de 2 entre 512 y 4096.

  1. ¿Hay alguna razón por la que tiene que/debe ser un poder de 2, o la inclinación natural de este programador a los poderes de 2?
  2. ¿Cuál sería el número "ideal"? Por "ideal" quiero decir que sería el más rápido. Asumo que tendría que ser un múltiplo del tamaño del buffer del dispositivo subyacente. ¿O tal vez del buffer del objeto de la corriente subyacente? ¿Cómo determinaría el tamaño de esos buffers, de todos modos? Y una vez que lo haga, ¿usar un múltiplo de él daría algún aumento de velocidad sobre sólo usar el tamaño exacto?

EDITAR
La mayoría de las respuestas parecen ser que no se puede determinar en el momento de la compilación. Estoy bien con encontrarla en tiempo de ejecución.

13voto

ravi Puntos 986

FUENTE:
¿Cómo se determina el tamaño ideal de la memoria intermedia al usar FileInputStream?

El tamaño óptimo del búfer está relacionado con un número de cosas: el sistema de archivos tamaño del bloque, tamaño de la caché de la CPU y latencia de la caché.

La mayoría de los sistemas de archivos están configurados para usar tamaños de bloque de 4096 o 8192. En teoría, si se configura el tamaño del búfer de manera que se lee unos cuantos bytes más que el bloque de disco, las operaciones con el sistema de archivos puede ser extremadamente ineficaz (es decir, si configuró su buffer para leer 4100 bytes a la vez, cada lectura requeriría 2 lecturas de bloque por el sistema de archivos). Si los bloques ya están en el caché, entonces terminas pagando el precio de la RAM -> L3/L2 de latencia de la caché. Si tienes mala suerte y los bloques no están en el caché todavía, el que pague el precio de la y también la latencia del disco y del RAM.

Es por eso que la mayoría de los buffers tienen un tamaño de 2, y generalmente más grande que (o igual a) el tamaño del bloque del disco. Esto significa que uno de los sus lecturas de flujo podrían resultar en lecturas de múltiples bloques de discos - pero esas lecturas siempre usarán un bloque completo, sin desperdiciar lecturas.

Asegurarse de ello también suele dar lugar a otros parámetros favorables al rendimiento que afectan tanto a la lectura como al procesamiento posterior: alineación del ancho del bus de datos, alineación de la DMA, alineación de la línea de la memoria caché, número completo de páginas de la memoria virtual.

3voto

unwind Puntos 181987
  1. Al menos en mi caso, la suposición es que el sistema subyacente está usando un buffer cuyo tamaño es una potencia de dos, también, por lo que es mejor tratar de igualar. Creo que hoy en día los buffers deberían ser un poco más grandes de lo que la "mayoría" de los programadores tienden a hacer. Yo diría que 32 KB en lugar de 4, por ejemplo.
  2. Es muy difícil saberlo de antemano, por desgracia. Depende de si su aplicación está vinculada a la E/S o a la CPU, por ejemplo.

1voto

Guffa Puntos 308133

1 . ¿Hay alguna razón por la que tiene que/debe ser un poder de 2, o la inclinación natural de este programador a los poderes de 2?

En realidad no. Probablemente debería ser algo que vaya incluso en el tamaño del ancho del bus de datos para simplificar la copia de la memoria, así que cualquier cosa que se divida en 16 estaría bien con la tecnología actual. Usar una potencia de 2 hace probable que funcione bien con cualquier tecnología futura.

2 . ¿Cuál sería el número "ideal"? Por "ideal" quiero decir que sería el más rápido.

El más rápido sería tanto como fuera posible. Sin embargo, una vez que pases de unos pocos kilobytes tendrás una diferencia de rendimiento muy pequeña comparada con la cantidad de memoria que usas.

Asumo que tendría que ser un múltiplo de la el tamaño del buffer del dispositivo subyacente? O tal vez de la corriente subyacente ¿búfer del objeto? ¿Cómo podría determinar el tamaño de esos buffers es, de todos modos?

No se puede saber realmente el tamaño de los amortiguadores subyacentes, o depender de que sigan siendo los mismos.

Y una vez que lo haga, ¿usar un múltiplo de él daría cualquier velocidad aumentar por sólo usar el tamaño exacto?

Algo, pero muy poco.

0voto

jcoder Puntos 14982
  1. Creo que en su mayoría es sólo elegir un número "redondo". Si las computadoras trabajaran en decimales, probablemente elegiríamos 1000 o 10000 en lugar de 1024 u 8192. No hay una muy buena razón.

Una posible razón es que los sectores del disco suelen tener un tamaño de 512 bytes, por lo que leer un múltiplo de eso es más eficiente, asumiendo que todas las capas de hardware y el almacenamiento en caché hacen que el código de bajo nivel pueda realmente utilizar este hecho de manera eficiente. Lo cual probablemente no pueda a menos que estés escribiendo un controlador de dispositivo o haciendo una lectura sin búfer.

0voto

Component 10 Puntos 4512

No hay razón por la que sepa que tiene que ser un poder de dos. Estás limitado por el tamaño del buffer que tiene que estar dentro del máximo size_t pero es poco probable que esto sea un problema.

Claramente cuanto más grande sea el buffer, mejor, pero esto obviamente no es escalable, por lo que se deben tener en cuenta algunas consideraciones sobre los recursos del sistema, ya sea en tiempo de compilación o preferiblemente en tiempo de ejecución.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X