Manera eficiente de guardar datos en el disco mientras se ejecuta una tarea de cálculo intensivo

Question

Estoy trabajando en una pieza de software científico que es muy intensivo en CPU (su proc está vinculado), pero necesita escribir datos en el disco con bastante frecuencia (i/o obligado).

Estoy agregando paralelización a esto (OpenMP) y me pregunto cuál es la mejor manera de abordar las necesidades de escritura en disco. No hay ninguna razón para que la simulación deba esperar en el HDD (que es lo que está haciendo ahora).

Estoy buscando una "mejor práctica" para esto, y la velocidad es lo que más me importa (estas pueden ser simulaciones muy largas).

Gracias ~ Alex

primeros pensamientos:

que tienen un proceso separado hacer la escritura real en el disco para la simulación tiene dos procesos: uno es vinculado a la CPU (simulación) y una es IO-bound (archivo de escritura). Esto suena complicado

¿Posiblemente una tubería/buffer? Soy algo nuevo en esto, así que tal vez esa podría ser una posible solución.

Answer 1

Si la implementación de OpenMP a su programa, entonces es mejor usar #pragma omp sola o #pragma omp maestro de la sección paralela a guardar en el archivo. Estos pragmas permiten que solo un hilo ejecute algo. Por lo tanto, el código puede verse de la siguiente manera:

#pragma omp parallel 
{ 
    // Calculating the first part 
    Calculate(); 

    // Using barrier to wait all threads 
    #pragma omp barrier 

    #pragma omp master 
    SaveFirstPartOfResults(); 

    // Calculate the second part 
    Calculate2(); 

    #pragma omp barrier 

    #pragma omp master 
    SaveSecondPart(); 

    Calculate3(); 

    // ... and so on 
} 

Aquí equipo de hilos va a hacer el cálculo, pero sólo un solo hilo ahorrará resultados en el disco.

Parece una línea de software. Le sugiero que considere el patrón tbb :: pipeline de la biblioteca Intel Threading Building Blocks. Puedo referirlo al tutorial sobre software pipes al http://cache-www.intel.com/cd/00/00/30/11/301132_301132.pdf#page=25. Por favor lea el párrafo 4.2. Resolvieron el problema: un hilo para leer desde el disco, el segundo para procesar cadenas de lectura, el tercero para guardar en la unidad.

Answer 2

Yo diría que la mejor manera sería generar un hilo diferente para guardar los datos, no un proceso completamente nuevo; con un nuevo proceso, se corre el problema de tener que comunicar los datos que se guardarán a través del límite del proceso, lo que introduce un nuevo conjunto de dificultades.

Answer 3

Un subproceso ejecuta continuamente un paso del proceso intensivo computacionalmente y luego agrega el resultado parcial a una cola de resultados parciales. Otro hilo elimina continuamente resultados parciales de la cola y los escribe en el disco. Asegúrese de sincronizar el acceso a la cola. Una cola es una estructura de datos similar a una lista donde puede agregar elementos al final y eliminar elementos del frente.

Answer 4

Dado que tiene CPU y IO obligado: Déjame adivinar: Todavía hay mucha memoria disponible, ¿verdad?

Si es así, debe almacenar temporalmente hasta cierto punto los datos que se deben escribir en el disco de la memoria. Escribir grandes cantidades de datos suele ser mucho más rápido que escribir piezas pequeñas.

Para la escritura en sí: Considere el uso de memoria asignada IO. Ha pasado un tiempo desde que hice la evaluación comparativa, pero la última vez que lo hice fue significativamente más rápido.

También siempre se puede cambiar un poco la CPU contra IO. Creo que actualmente está escribiendo los datos como algún tipo de datos en bruto, sin comprimir, ¿verdad? Puede obtener cierto rendimiento de E/S si utiliza un esquema de compresión simple para reducir la cantidad de datos que se escribirán. La biblioteca ZLIB es bastante fácil de trabajar y se comprime muy rápido en el nivel de compresión más bajo. Depende de la naturaleza de sus datos, pero si hay mucha redundancia, incluso un algoritmo de compresión muy crudo puede eliminar el problema de IO.

Answer 5

La primera solución que le viene a la mente es más o menos lo que ha dicho, tener grabaciones en el disco en su propio proceso con una tubería de una sola vía del simulador al escritor. El escritor escribe lo más rápido posible (extrayendo nuevos datos de la tubería). El problema con esto es que si la tarjeta SIM se adelanta demasiado al escritor, la tarjeta SIM bloqueará las escrituras de la tubería de todos modos, y se vinculará con la E/S de una vez.

El problema es que, de hecho, su ciclo de simulación no está completo hasta que escupió los resultados.

Lo segundo que se me ocurre es usar E/S sin bloqueo.Siempre que la tarjeta SIM necesite escribir, debe hacerlo a través de E/S sin bloqueo. En la siguiente necesidad de escribir, puede recoger los resultados de la operación de E/S anterior (posiblemente incurriendo en una pequeña espera) antes de iniciar la nueva. Esto mantiene la simulación ejecutándose tanto como sea posible en paralelo con la E/S sin permitir que la simulación vaya mucho más allá de la escritura.

La primera solución sería mejor si el ciclo de procesamiento de la simulación varía (a veces más pequeño que el tiempo de una escritura, a veces más) porque en promedio las escrituras pueden mantenerse al día con el sim.

Si el ciclo de procesamiento es siempre (o casi siempre) más corto que el tiempo de escritura , entonces no se moleste con la tubería y simplemente use E/S sin bloqueo, porque si usa la tubería Eventualmente se llenará y la tarjeta SIM se colgará en la E/S de todos modos.

Answer 6

Haga que su aplicación tenga dos hilos , uno para la CPU y el otro para el disco duro.

Tiene el empuje hilo CPU completado los datos en una cola, que el hilo disco duro tira luego de que los datos entra en acción.

De esta manera la CPU simplemente se deshace de los datos y permite que otra persona manejar y el disco el disco simplemente espera pacientemente cualquier información en su cola.

En cuanto a la implementación, podría hacer la cola como un tipo de objeto de memoria compartida, pero creo que una tubería sería exactamente lo que estaría buscando. La CPU simplemente escribe en la tubería cuando sea necesario. En el lado del disco duro, simplemente leería el conducto y siempre que tenga datos válidos, proceda desde allí.