¿El bloqueo MPI_Reduce (o una barrera natural)?

Tengo el siguiente fragmento de código en C++ que básicamente calcula el pi usando la técnica clásica de monte carlo.¿El bloqueo MPI_Reduce (o una barrera natural)?

srand48((unsigned)time(0) + my_rank); 

    for(int i = 0 ; i < part_points; i++) 
    { 
      double x = drand48(); 

      double y = drand48(); 

      if((pow(x,2)+pow(y,2)) < 1){ ++count; } 
    } 

    MPI_Reduce(&count, &total_hits, 1, MPI_DOUBLE, MPI_SUM, 0, MPI_COMM_WORLD); 

    MPI_Barrier(MPI_COMM_WORLD); 

    if(my_rank == root) 
    { 
      pi = 4*(total_hits/(double)total_points); 

      cout << "Calculated pi: " << pi << " in " << end_time-start_time << endl; 
    }

Me pregunto si la llamada MPI_Barrier es necesaria. ¿MPI_Reduce se asegura de que el cuerpo de la instrucción if no se ejecutará antes de que la operación de reducción esté completamente terminada? Espero que estuviera claro. Gracias

Fuente

2012-02-14 Cemre

Sí, todas las llamadas de comunicación colectiva (Reduce, Scatter, Gather, etc.) están bloqueando. No hay necesidad de la barrera.

Fuente

2012-02-14 22:12:02 suszterpatt

El estándar MPI permite la salida anticipada de los procesos participantes. La única llamada colectiva que garantiza la sincronización es 'MPI_Barrier'. –

Bloqueo sí, una barrera, no. Es muy importante llamar al MPI_Barrier() para MPI_Reduce() cuando se ejecuta en un circuito cerrado. Si no se llama al MPI_Barrier(), los búferes de recepción del proceso de reducción eventualmente se ejecutarán completos y la aplicación abortará. Mientras que otros procesos participantes solo necesitan enviar y continuar, el proceso de reducción debe recibir y reducir. El código anterior no necesita la barrera si my_rank == root == 0 (lo que probablemente sea cierto). De todos modos ... MPI_Reduce() no realiza ninguna barrera ni ninguna forma de sincronización. AFAIK incluso MPI_Allreduce() no garantiza la sincronización (al menos no según el estándar MPI).

Fuente

2013-03-11 16:57:38 beer

Como esta respuesta parece contradecir la respuesta seleccionada y no hay evidencia de que haya sido rechazada, ¿alguien puede comentar si esto es realmente incorrecto? – MarkWayne

Esta respuesta es solo mitad correcta. Los búferes de recepción ** pueden ** ejecutarse por completo. La mayoría de las bibliotecas de MPI implementan mecanismos de control de flujo que evitan que esto ocurra. –

Pregúntese si esa barrera es necesaria. Supongamos que no eres la raíz; usted llama a Reduce, que envía sus datos. ¿Hay alguna razón para sentarse y esperar hasta que la raíz tenga el resultado? Respuesta: no, entonces no necesitas la barrera.

Supongamos que es la raíz. Usted emite la llamada de reducción. Semánticamente ahora te obligan a sentarte y esperar hasta que el resultado esté completamente ensamblado. Entonces, ¿por qué la barrera? De nuevo, no se necesita una llamada de barrera.

En general, casi nunca necesita una barrera porque no le importa la sincronización temporal. La semántica garantiza que su estado local es correcto después de la llamada de reducción.

Fuente

2018-01-02 18:48:04

¿El bloqueo MPI_Reduce (o una barrera natural)?

Respuesta

Cuestiones relacionadas