¿Debo pasar argumentos de línea de comando a MPI_Init o no?

Al escribir el código MPI 3.0, ¿debería pasar argcy argva la MPI_Initllamada o no, y por qué?

EDITAR: Dado que la respuesta de Bill Barth planteó algunas preguntas, quiero hacer algunos comentarios:

Pasar argc/ argvno es necesario desde MPI 1.1.
La pregunta es específicamente sobre por qué debería / no debería pasar argc/ argv( por qué no debería, entonces no es realmente una respuesta).
Aún así, a veces no puede pasar argc/ argva MPI_Init(escribir una biblioteca que usa inicialización estática para iniciar MPI si main está fuera de su control y MPI es un detalle de implementación).

EDIT2: La pregunta por qué noMPI_Init(argc, argv) usarías ha llegado con demasiada frecuencia ahora. Algunos motivos:

No es posible hacerlo por razones de compatibilidad con implementaciones MPI <1.1 antiguas / no conformes / compatibles, ya que si está utilizando las funciones MPI2 o MPI3, no funcionarán de todos modos.
MPI_Init() inicializa el tiempo de ejecución de MPI de la misma manera que MPI_Init(argc, argv)
MPI_Init(argc, argv)elimina los argumentos que se pasan a la MPI tiempo de ejecución de argc, y argv e inicializa MPI. AFAIK es la única forma de limpiar argcy, argvpor lo tanto, si necesita que estos no tengan argumentos MPI, debe usarlo.
MPI_Init()se puede usar en más situaciones que MPI_Init(argc, argv). Por ejemplo, su biblioteca que usa MPI como detalle de implementación puede probar si MPI se inicializa, y si no, llame MPI_Init()y sucederá lo correcto. Su usuario no sabe que está utilizando MPI, no necesita pasar argc, argva la biblioteca, no necesita cambiar su principal (en caso de que se está llevando sin argumentos) para utilizar su biblioteca ....

c++ c mpi gnzlbg
fuente

No entiendo por qué la respuesta de BillBarth no responde a su pregunta. Parece que la parte "por qué no lo harías" resume la esencia de su respuesta, que describe lo que sucedió con implementaciones anteriores de MPI y por qué no pasar argumentos podría causar problemas. ¿Quizás estás buscando algo más definitivo?

Geoff Oxberry

@GeoffOxberry El problema con el por qué no responderías es que es tan bueno como el por qué responderías. Dado que todas las implementaciones de MPI que admiten MPI> 1.1 tienen que ofrecer la alternativa MPI_Init()que tiene que obtener correctamente los argumentos a los que pasas mpirun/ de mpiexec alguna manera (no se especifica cómo), y dado que MPI_Init()se pueden usar en más situaciones que MPI_Init(argc, argv)(y sin soluciones), no lo hago ' Realmente no veo el punto de usar MPI_Init(argc, argv)si está apuntando a MPI 3.0.

gnzlbg

De todos modos, la compatibilidad con las implementaciones de MPI que admiten MPI <1.1 no es posible si tiene que usar las funciones MPI 2.0 o MPI 3.0.

gnzlbg

Todavía te estás perdiendo mi punto básico. La distribución MPI no puede decir en el momento de la ejecución si su MPI_Init pasa NULL o no, por lo que probablemente ponga cosas en la línea de comando. Si no pasa argc y argv, MPI_Init no puede editarlos para eliminar sus adiciones, por lo tanto, su código tendrá que ser robusto para los argumentos espurios de la línea de comandos de MPI. Por lo tanto, ¿por qué arriesgarse a tener que lidiar con un conjunto de argumentos arbitrarios y quizás conflictivos cuando puede pasarlos a MPI_Init y recuperar un conjunto limpio? Si no puedes, no puedes, pero deberías .

Bill Barth

Ver el segundo EDITAR a la pregunta. Básicamente, si desea limpiar argcy argvpartir de argumentos MPI e inicializar MPI, use MPI_Init(argc, argv), de lo contrario MPI_Init()está bien (y a veces es necesario).

gnzlbg

Respuestas:

Definitivamente los pasaría, pero pasaría los punteros como este MPI_init (& argc, & argv), permitiendo una llamada perfectamente válida MPI_init (NULL, NULL) en su función.

ruibarbo
fuente

No sé si hay algo nuevo en el estándar 3.0 que lo hace opcional en C / C ++ para no pasarlos, pero definitivamente los pasaría. No sé el estado actual, pero en el pasado muchas implementaciones pasaron argumentos adicionales de la línea de comandos a su programa cuando se ejecutaron y luego los editaron MPI_Init(). Si desea utilizar argumentos de línea de comandos para pasar opciones a su programa, si no deja que la implementación realice su edición, deberá interpretar tanto sus argumentos como un número y estilo de argumentos potencialmente desconocido de la implementación particular Tu estas usando. Es muy probable que estos argumentos varíen de una implementación a otra.

Es bastante normal que llamar MPI_Init()con argcy argv, ¿por qué no?

Bill Barth
fuente

La especificación dice que después de MPI 1.1 si pasa nulo a MPI_Init, debería leer los argumentos del entorno. Entonces, ¿por qué pasarlos a su aplicación en primer lugar si puede leerlos desde el entorno? Si los tiempos de ejecución pasan los argumentos a la aplicación de todos modos, entonces sí tiene sentido llamar a MPI_Init con ellos de modo que al menos su tiempo de ejecución los limpie antes de que el resto de su aplicación los use.

gnzlbg

De acuerdo, ¿ha probado todas las pilas disponibles para averiguar si se han puesto al día con lo que pueden hacer? Si es posible que alguna pila pueda arruinar el análisis de argumentos de su código agregando argumentos adicionales, ¿por qué no dejar que haga su parte para eliminar esos argumentos adicionales durante la inicialización? ¿Cuál es el daño al pasar argc y argv a MPI_Init ()? De nuevo, ¿por qué no hacerlo?

Bill Barth

(1) Realmente no entiendo tu punto sobre la información del entorno. Si llamo mpirun/ mpiexeccon algunos parámetros, mpirunpuedo configurar algunas variables de entorno antes de iniciar mi programa y luego leerlas desde adentro MPI_Init. (2) No he probado todas las implementaciones posibles, pero como dice la pregunta, solo estoy interesado en las implementaciones compatibles con MPI 3.0. No hay muchos de los que son arcanos .

gnzlbg

Me perdí tu edición antes de escribir todo eso. Mi sugerencia es pasar argc y argv a la biblioteca si quiere inicializar MPI en su nombre. Eso, o requiere que los usuarios MPI_Init () y pasen a la biblioteca el comunicador requerido. Posiblemente no sea portable, no llame a MPI_Init () con argc y argv. Petsc, por ejemplo, admite ambos estilos.

Bill Barth

Soportar ambos estilos parece necesario para cualquiera que escriba un contenedor MPI.

gnzlbg