sobre la creación de una versión 'nativa' para linux
18 views
Skip to first unread message
Martín Gaitán
Mar 11, 2011, 9:12:22 AM3/11/11
to gpec-d...@googlegroups.com
Reenvio esta conversación con Francisco Sánchez sobre el interes en trabajar en la compilación de una versión nativa de los ejecutables de GPEC para plataforma linux.
Actualmente, en la "nueva versión" que estoy desarrollando en el marco de mi tésis, funciona en todas las plataformas no-linux mediante el "emulador" Wine. http://www.winehq.org/ pero obviamente es un método ineficiente y un requerimiento bastante grande que sería muy bueno evitar.
saludos a todos y todas.
Forwarded conversation
Subject: GPEC
------------------------
From: Francisco Adrián Sánchez <franciscoad...@gmail.com>
Date: 2011/3/10
To: gai...@gmail.com
Martín:
Soy Francisco Sánchez, de PLAPIQUI. Nos conocimos en RITEQ del año pasado (aunq yo en realiadd ya te conocía de una charla que diste acá sobre SL).
Te quería comentar, que pude yo compilar GPEC directamente desde Linux, con el compilador de fortran de Intel (no pude con el de GNU, aún). Estuve probando la versión de GPEC para Linux que hiciste, y traté de ver si podía tocar algo para poder usar este ejecutable (el de GPEC, aún me falta el resto de los programas) pero la verdad no pude: no entiendo nada de python.
Si bien aún me falta resolver algunas cuestiones, la compilación del resto de los programas de GPEC, nativa en linux es posible cambiando algunas (cuantas) líneas de código más (por una cuestión de subrutinas).
Mi progrunta es si estás interesado en producir un GPEC totalmente nativo, sin la necesidad de usar Wine, ya que básicamnete, a mí por lo menos, me tardan más los ejecutables.
Un saludo
----------
From: Martín Gaitán <gai...@gmail.com>
Date: 2011/3/10
To: Francisco Adrián Sánchez <franciscoad...@gmail.com>
Cc: Martín Cismondi Duarte <mcis...@efn.uncor.edu>
----------
From: Francisco Adrián Sánchez <franciscoad...@gmail.com>
Date: 2011/3/11
To: Martín Gaitán <gai...@gmail.com>
Cc: gpi...@plapiqui.edu.ar, Martín Cismondi <mcis...@plapiqui.edu.ar>
Martín, vamos por partes, dijo Jack.
En GPEC (y me refiero al código que genera el ejecutable GPEC) hay sólo 2 subrutinas, de toda la IMSL, que se usan. Una es DLSARG que resuelve sistemas lineales. Seguramente, debe ser muy buena resolviendo sistemas lineales pero, algoritmos de resulución de sistemas lineales está lleno. Ignoro qué características tendrá la DLSARG frente a oras subrutinas disponibles, pero otras hay.
Lo único que hice fue reemplazar el llamado a DLSARG por otras dos subrutinas que tomé prestadas del curso que nos dieron Martín y sus profesores daneses en el 2009.. Igual, ya comprobé, que subrutinas de algebra lineal, ya tenemos acá mismo.
A esas subrutinas, simplemente las copié un otro archivo .for que inclui en la compilación.
La otra subrutina en cuestión, idamax, a pesar de estar en la IMSL está disponible gratis en internet (su código fuente, quiero decir) en www.netlib.org.
Jajaja, igual no adelantemos tanto aún, faltaría bastante. SI bien compila (y según he visto, algunos programadores siguen el "if it compiles, ship it!") y ejecutable que genero corre, pero he encontrado algunos bugs. El asunto creo, no sé si es por compilarlo con el compilador de Intel o porque está optimizado para velocidad (-O3) o no sé qué. De cualquir manera, mirá estos ejemplos de tiempo (x.gpec es el ejecutable de linux y gpec.exe el de windows, aunq no es una comparación justa, porque mi linux es de 64 bits):
Interesante es luego comparar con la salida del ejecutable compilado CON las IMSL:
Lo bueno, es que producen los mismos resultados, al menos con la presición que GPEC los está imprimiendoEntiendo que el proceso de escribir los datos a disco sea ineficiente. Lo que proponés es cierto, y creo que aumentaría la velocidad en alguna forma al no tener que escribir en el disco pero, a mí en particular me gustan las entradas y salidas en modo texto. Estoy acostumbrado a trabajar con ellas.
En todo caso, sería bueno sí, que los llamados a las variables se hagan dentro del programa, y que uno luego pueda exportar a texto la salida, pero creo que me gustaría conservar la posiblidad de ingresar datos en modo texto... a modo de proyectos.Ammm sí, recuerdo que estuve por anotarme pero al final no lo hice, jeje. Ahora me fijo.
Un saludo
El 10 de marzo de 2011 19:18, Martín Gaitán <gai...@gmail.com> escribió:
Subject: GPEC
------------------------
From: Francisco Adrián Sánchez <franciscoad...@gmail.com>
Date: 2011/3/10
To: gai...@gmail.com
Martín:
Soy Francisco Sánchez, de PLAPIQUI. Nos conocimos en RITEQ del año pasado (aunq yo en realiadd ya te conocía de una charla que diste acá sobre SL).
Te quería comentar, que pude yo compilar GPEC directamente desde Linux, con el compilador de fortran de Intel (no pude con el de GNU, aún). Estuve probando la versión de GPEC para Linux que hiciste, y traté de ver si podía tocar algo para poder usar este ejecutable (el de GPEC, aún me falta el resto de los programas) pero la verdad no pude: no entiendo nada de python.
Si bien aún me falta resolver algunas cuestiones, la compilación del resto de los programas de GPEC, nativa en linux es posible cambiando algunas (cuantas) líneas de código más (por una cuestión de subrutinas).
Mi progrunta es si estás interesado en producir un GPEC totalmente nativo, sin la necesidad de usar Wine, ya que básicamnete, a mí por lo menos, me tardan más los ejecutables.
Un saludo
----------
From: Martín Gaitán <gai...@gmail.com>
Date: 2011/3/10
To: Francisco Adrián Sánchez <franciscoad...@gmail.com>
Cc: Martín Cismondi Duarte <mcis...@efn.uncor.edu>
Hola francisco.
Creo que sería buenísimo hacer eso. reemplazas la biblioteca IMSL ? Yo me había embalado a meterme en esa tarea porque existe una versión para linux de esa biblioteca, pero no es libre y no compila sino es con el de Intel, así que decidí aprovechar la energía para otra cosa. pero si vos podés aportar trabajo ahí, creo que sería muy bueno.
Me vas a obligar a cambiar esta parte!
Ahora, tambien sería bueno, creo yo, rediseñar la comunicación de estas librerias, permitiendo por ejemplo definir como parámetros los archivos de entrada y salida que deben procesar y no que estén "hardcodeados" en el código (que por defecto sean el stdin y el stdout). Ese simple cambio permitiría hacer pipes sin tener que escribir los datos a disco, lo que sería bastante más rápido.
Más aun, pero esto ya sería más laburo, definir las rutinas de fortran respetando la convención de F2Py de modo de poder usarlas "más nativamente" desde python. http://cens.ioc.ee/projects/f2py2e/ (volvería inservible gran parte del laburo que yo hice, pero sería mucho mejor para el desarrollo futuro).
Estás anotado en el grupo de GPEC ? seria piola si te podés anotar y continuamos la charla por ahí de modo que Martín o quien quiera pueda enterarse y opinar y de paso reactivamos el interés
la dire del grupo es https://groups.google.com/group/gpec-discuss
saludos
----------
From: Francisco Adrián Sánchez <franciscoad...@gmail.com>
Date: 2011/3/11
To: Martín Gaitán <gai...@gmail.com>
Cc: gpi...@plapiqui.edu.ar, Martín Cismondi <mcis...@plapiqui.edu.ar>
Martín, vamos por partes, dijo Jack.
[...]reemplazas la biblioteca IMSL ?[...]
En GPEC (y me refiero al código que genera el ejecutable GPEC) hay sólo 2 subrutinas, de toda la IMSL, que se usan. Una es DLSARG que resuelve sistemas lineales. Seguramente, debe ser muy buena resolviendo sistemas lineales pero, algoritmos de resulución de sistemas lineales está lleno. Ignoro qué características tendrá la DLSARG frente a oras subrutinas disponibles, pero otras hay.
Lo único que hice fue reemplazar el llamado a DLSARG por otras dos subrutinas que tomé prestadas del curso que nos dieron Martín y sus profesores daneses en el 2009.. Igual, ya comprobé, que subrutinas de algebra lineal, ya tenemos acá mismo.
A esas subrutinas, simplemente las copié un otro archivo .for que inclui en la compilación.
La otra subrutina en cuestión, idamax, a pesar de estar en la IMSL está disponible gratis en internet (su código fuente, quiero decir) en www.netlib.org.
Me vas a obligar a cambiar esta parte! [...]
Jajaja, igual no adelantemos tanto aún, faltaría bastante. SI bien compila (y según he visto, algunos programadores siguen el "if it compiles, ship it!") y ejecutable que genero corre, pero he encontrado algunos bugs. El asunto creo, no sé si es por compilarlo con el compilador de Intel o porque está optimizado para velocidad (-O3) o no sé qué. De cualquir manera, mirá estos ejemplos de tiempo (x.gpec es el ejecutable de linux y gpec.exe el de windows, aunq no es una comparación justa, porque mi linux es de 64 bits):
francisco@Francisco-PC:/media/FRAN/GPEC/Fuentes GPEC - sin IMSL$ time ./x.gpec
T-limit for High-P search exceeded
T-limit for High-P search exceeded
T-limit for High-P search exceeded
real 0m0.153s
user 0m0.040s
sys 0m0.010s
francisco@Francisco-PC:/media/FRAN/GPEC/Fuentes GPEC - sin IMSL$ time wine gpec.exe
T-limit for High-P search exceeded
T-limit for High-P search exceeded
forrtl: severe (157): Program Exception - access violation
Image PC Routine Line Source
gpec.exe 004239C8 Unknown Unknown Unknown
gpec.exe 00415F4D Unknown Unknown Unknown
gpec.exe 004156FC Unknown Unknown Unknown
gpec.exe 00415644 Unknown Unknown Unknown
gpec.exe 0049CF09 Unknown Unknown Unknown
gpec.exe 00482449 Unknown Unknown Unknown
KERNEL32.dll 7B85975C Unknown Unknown Unknown
KERNEL32.dll 7B85C0CB Unknown Unknown Unknown
ntdll.dll 7BC72698 Unknown Unknown Unknown
ntdll.dll 7BC72870 Unknown Unknown Unknown
ntdll.dll 7BC4CC4A Unknown Unknown Unknown
Incrementally linked image--PC correlation disabled.
real 0m1.752s
user 0m0.640s
sys 0m0.060s
Interesante es luego comparar con la salida del ejecutable compilado CON las IMSL:
francisco@Francisco-PC:/media/FRAN/GPEC/Fuentes GPEC$ time wine gpec.exeCon lo que vemos que la DLSARG no es mucho más rápida, y que por usar un sistema operativo de 64 bits, tengo una velocidad de un orden de magnitud menor
*** WARNING ERROR 1 from DLSARG. The matrix is too ill-conditioned. An
*** estimate of the reciprocal of its L1 condition number is RCOND
*** = 1.770651383309205D-16. The solution might not be accurate.
# etc, etc, más warnings, etc, etc..
*** WARNING ERROR 1 from DLSARG. The matrix is too ill-conditioned. An
*** estimate of the reciprocal of its L1 condition number is RCOND
*** = 1.174200333832325D-16. The solution might not be accurate.
T-limit for High-P search exceeded
T-limit for High-P search exceeded
forrtl: severe (157): Program Exception - access violation
Image PC Routine Line Source
gpec.exe 00411408 Unknown Unknown Unknown
gpec.exe 00404175 Unknown Unknown Unknown
gpec.exe 00403924 Unknown Unknown Unknown
gpec.exe 0040386C Unknown Unknown Unknown
gpec.exe 004A9A69 Unknown Unknown Unknown
gpec.exe 0048EF59 Unknown Unknown Unknown
KERNEL32.dll 7B85975C Unknown Unknown Unknown
KERNEL32.dll 7B85C0CB Unknown Unknown Unknown
ntdll.dll 7BC72698 Unknown Unknown Unknown
ntdll.dll 7BC72870 Unknown Unknown Unknown
ntdll.dll 7BC4CC4A Unknown Unknown Unknown
Incrementally linked image--PC correlation disabled.
real 0m1.714s
user 0m0.650s
sys 0m0.050s
Lo bueno, es que producen los mismos resultados, al menos con la presición que GPEC los está imprimiendoEntiendo que el proceso de escribir los datos a disco sea ineficiente. Lo que proponés es cierto, y creo que aumentaría la velocidad en alguna forma al no tener que escribir en el disco pero, a mí en particular me gustan las entradas y salidas en modo texto. Estoy acostumbrado a trabajar con ellas.
En todo caso, sería bueno sí, que los llamados a las variables se hagan dentro del programa, y que uno luego pueda exportar a texto la salida, pero creo que me gustaría conservar la posiblidad de ingresar datos en modo texto... a modo de proyectos.Ammm sí, recuerdo que estuve por anotarme pero al final no lo hice, jeje. Ahora me fijo.
Un saludo
El 10 de marzo de 2011 19:18, Martín Gaitán <gai...@gmail.com> escribió:
--
oscars-awards.com
Reply all
Reply to author
Forward
0 new messages