Linux: matriz int grande: mmap versus archivo de búsqueda?

Question

Supongamos que tengo un conjunto de datos que es una matriz de 1E12 enteros de 32 bits (4 TB) almacenados en un archivo en un sistema de archivos ext4 4 TB de disco duro ..

consideran que los datos es más probable al azar (o al menos parece aleatorio).

// pseudo-code 
for (long long i = 0; i < (1LL << 40); i++) 
    SetFileIntAt(i) = GetRandInt(); 

Además, considero que me gustaría leer elementos int individuales en un orden impredecible y que el algoritmo se ejecuta indefinidamente (está en curso).

// pseudo-code 
while (true) 
    UseInt(GetFileInt(GetRand(1<<40))); 

Estamos en Linux x86_64, gcc. Se puede suponer sistema tiene 4 GB de RAM (es decir 1000x menos de conjunto de datos)

Los siguientes son dos maneras de acceder arquitecto:

(A) mmap el archivo a un bloque de 4 TB de memoria, y acceder a ella como una int matriz

(B) abierto (2) el archivo y utilizar buscar (2) y leer (2) para leer los enteros.

Fuera de A y B que tendrá el mejor rendimiento ?, y por qué?

¿Hay algún otro diseño que proporcione un mejor rendimiento que A o B?

Answer 1

Diría que el rendimiento debería ser similar si el acceso es realmente aleatorio. El sistema operativo utilizará una estrategia de almacenamiento en caché similar, ya sea que la página de datos esté mapeada a partir de un archivo o que los datos del archivo estén simplemente en caché sin una asociación con la memoria RAM.

caché Suponiendo es ineficaz:

• Puede utilizar fadvise declarar su patrón de acceso por adelantado y readahead desactivar.
• Debido a la aleatorización del diseño del espacio de direcciones, es posible que no exista un bloque contiguo de 4 TB en el espacio de direcciones virtuales.
• Si su conjunto de datos se expande, el problema del espacio de direcciones puede ser más apremiante.

Así que me gustaría ir con lecturas explícita.

Answer 2

Por un lado, que tienen un amplio uso de de intercambio de memoria lo que resulta en menores pagefaults y transparentes para el aplicativo. En el otro, tiene numerosas llamadas al sistema , con la sobrecarga conocida. La página de Wikipedia sobre memory-mapped file parece ser bastante clara para mí, examina de manera exhaustiva los pros y los contras.

creo que la arquitectura de 64 bits + llamada archivo de gran tamaño para un enfoque de archivo asignado en memoria, al menos para no complejizar el aplicativo; Me han dicho que la complejidad a menudo conduce a un rendimiento pobre. Sin embargo, mmap() es habitual para el acceso secuencial, que no es el propósito aquí.

Debido a que este es de acceso aleatorio puro, hay pocas posibilidades de que dos accesos estarán en la misma página RAM-cargado. Una página completa de 4 kb se intercambiará de la HDD a la RAM, solo para datos de 4 bytes ... Esta es una carga inútil de los buses y probablemente dará como resultado un bajo rendimiento.

Espero que esta ayuda.

Answer 3

Probablemente para un conjunto de datos lineales de 4TB no necesita un sistema de archivos. Supongo que un acceso al dispositivo sin procesar puede traer algunos beneficios de rendimiento.

¿Probablemente también hay una manera de optimizar las consultas o la estructura de datos, para que el almacenamiento en caché se pueda utilizar de manera más eficiente?

Answer 4

El rendimiento de búsqueda depende en gran medida de la implementación de su sistema de archivos. Ext4 debería ser una buena opción ya que usa extent trees. Además, si su archivo tiene una asignación contigua lineal, el árbol de extensión constará de una sola entrada, lo que hace que la búsqueda sea trivialmente eficiente.