programas - problemas resueltos de programación en fortran 95 pdf

Fortran: matrices dinámicas frente a matriz automática Evitar la asignación de memoria

Question

Al perfilar uno de nuestros códigos fortran, hay dos subrutinas que ocupan la mayor parte del tiempo computacional (22.1% y 17.2%). En cada rutina, ~ 5% del tiempo se gasta en asignar y liberar memoria. Estas rutinas se ven como

MODULE foo

CONTAINS

SUBROUTINE bar( ... )
...
IMPLICIT NONE
...
REAL, ALLOCATABLE, DIMENSION(:,:) :: work
...
ALLOCATE (work(size1,size2))
...
DEALLOCATE (work)
END SUBROUTINE bar
...
END MODULE foo

Estas subrutinas son llamadas del orden de 4000-5000 veces en mi punto de referencia, por lo que me gustaría deshacerme de ALLOCATE y DEALLOCATE. Cambiar estos a arreglos automáticos cambia a la salida del generador de perfiles.

MODULE foo

CONTAINS

SUBROUTINE bar( ... )
...
IMPLICIT NONE
...
REAL, DIMENSION(size1,size2) :: work
...
END SUBROUTINE bar
...
END MODULE foo

Cambia el perfil resultante a

Running Time        Symbol Name
20955.0ms  17.0%    __totzsp_mod_MOD_totzsps
    7.0ms   0.0%        malloc
    5.0ms   0.0%        free
    2.0ms   0.0%        user_trap

16192.0ms  13.2%    __tomnsp_mod_MOD_tomnsps
   20.0ms   0.0%        free
    3.0ms   0.0%        malloc
    1.0ms   0.0%        szone_size_try_large

Parece que Gfortran los está asignando a la pila y no a ese montón, pero me preocupa cuándo ocurre cuando estas matrices se vuelven demasiado grandes.

El segundo enfoque que estoy tomando es asignar y desasignar estas matrices una vez.

work_array.f

MODULE work_array
IMPLICIT NONE

REAL(rprec), ALLOCATABLE, DIMENSION(:,:) :: work

END MODULE work_array

Asigno estos una vez en una parte diferente del código. Ahora mi subrutina parece

MODULE foo

CONTAINS

SUBROUTINE bar( ... )
...
USE work_array
IMPLICIT NONE
...
END SUBROUTINE bar
...
END MODULE foo

Sin embargo, cuando ejecuto el código ahora el perfil empeora.

Running Time        Symbol Name
30584.0ms  21.6%    __totzsp_mod_MOD_totzsps
 3494.0ms   2.4%        free
 3143.0ms   2.2%        malloc
   27.0ms   0.0%        DYLD-STUB$$malloc_zone_malloc
   19.0ms   0.0%        szone_free_definite_size
    6.0ms   0.0%        malloc_zone_malloc

24325.0ms  17.1%    __tomnsp_mod_MOD_tomnsps
 2937.0ms   2.0%        free
 2456.0ms   1.7%        malloc
   23.0ms   0.0%        DYLD-STUB$$malloc_zone_malloc
    3.0ms   0.0%        szone_free_definite_size

¿De dónde vienen estos mallocs extra y libres? ¿Cómo puedo configurar esto para que yo asigne estas matrices una vez?

Answer 1

Como la matriz de work solo se usa dentro de la subrutina de bar , puede agregarle el atributo de save y asignarla cuando se invoque la subrutina por primera vez. Si work1 o work2 es diferente en comparación con llamadas anteriores, puede reasignar la matriz en ese caso.

Esto deja el problema de la desasignación una vez que ya no se necesita la subrutina. Si necesita llamar durante toda la vida útil del programa, no hay problema, ya que el sistema operativo debe desasignar la memoria cuando se cierra el programa. Por otro lado, si solo lo necesita durante la inicialización, la memoria permanecerá asignada incluso cuando no sea necesaria. Tal vez pueda agregar un argumento a la subrutina que le indique desasignar la matriz de work , si el uso de memoria es un problema.

Answer 2

Si puede salir adelante con una única asignación en la inicialización del programa, entonces no hay ninguna razón para que la matriz se defina como asignable. Ponlo en común.

Si solo necesita un tamaño fijo, pero no conoce ese tamaño hasta el tiempo de ejecución, necesitará ir con su opción final, una asignación única en la inicialización. Sin embargo, no tiene sentido que esto haya incrementado el impacto en el rendimiento de la asignación. Necesitaría ver la definición y el código de asignación para decir más.

Como lo que se asigna es la memoria virtual, el "uso de la memoria" no es realmente un problema, a menos que la matriz sea tan grande que afecte el espacio de direcciones disponible.