Blogia
Blog de Ibercivis

Novedades sobre la compilación

¿Habéis oído alguna vez la expresión: "La explicación más simple suele ser la correcta"? Pues eso nos ha pasado. Teníamos el problema de que en Windows las aplicaciones iban 4 o 5 veces más lentas que en Linux, sin razón aparente. Nos volvimos locos conjeturando acerca de las opciones de optimización, indicando a mano la arquitectura de la máquina y escarbando en las opciones más oscuras del gcc. Al final, tras hacer pruebas con benchmarks (el whetstone y el dhrystone, ¿le suenan a alguien?) en una máquina con arranque dual Linux y Windows, hemos llegado a la conclusión de que la razón por la que las aplicaciones iban 4 o 5 veces más lentas en Windows era porque las máquinas donde estabamos probando las versiones de windows eran, efectivamente, entre 4 y 5 veces más lentas que las máquinas de Linux. ¡Quién lo iba a decir! Risa

Una de las máquinas tenía poca memoria (256 MB de RAM) y enseguida empezaba usar el swap lo que la ralentizaba mucho. La cuestión es que el problema se repetía en otra máquina con 2 GB de RAM y un Core Duo a 2,2 Ghz (una máquina supuestamente potente) y eso nos despistó.

A ver si el lunes o el martes podemos tener listas versiones para Windows de materiales128 y fusión_2.0, y ya volvemos a la normalidad.

Ahora paso a comentar las nuevas versiones.

Habréis observado hoy que hemos lanzado unas cuantas miles de workunits de prueba de docking. En Linux funcionan correctamente y no hay ningún problema. Sin embargo, los resultados que devuelven los Windows son rechazados por el validador, aunque la aplicación se ejecuta de forma correcta. En las pruebas en local iba bien, así que habrá que investigarlo.

En fusión también hay novedades. Tras encontrar un molesto bug que hacia fallar a la aplicación en los Linux de 32 bits, los investigadores de fusión han actualizado los parámetros de la simulación. Ahora, uno de los archivos de input (que sólo hay que descargarse la primera vez), ocupa el nada desdeñable tamaño de 73 MB. Si esto es mucho o poco, os toca a vosotros decidirlo. También ha habido que añadir una restricción a la memoria disponible en la template de la workunit. La exigencia en recuros de la aplicación es mayor también y he restringido el envío a máquinas que dispongan de, al menos, 500 MB de RAM para el proyecto libres.

6 comentarios

Guiri-1 -

De hecho me dice que no está disponisble para mi tipo de pc.
Y tengo 2GB de ram...creo que algo va mal.

Deuvede -

La nueva versión de fusión usa muchísima memoria (del orden de 400 MB), que es la Jorge pone los logs. A lo mejor, Guiri-1, no te cae de fusión porque está restringido sólo para ordenadores potentes (con 500+ MB de RAM disponibles par a el proyecto).

Guiri-1 -

Pues a mi no me pilla, ni mucho menos tanta memoria. Pq a unos les pillas mas que otros?
Si pillaran 2GB de memoria habría muchisimos usuarios que no podrían correr la aplicación. Y otros,como yo, que dejariamos de hacerlo, ya que solo computo en el pc del trabajo y claro...tiene que funcionar¡
G-1

Jorge Mena -

Me corrijo, en el top estoy mostrando también los threads, así que en el primer caso, "solo" usan 1,1GB de memoria. No obstante, hay veces que ocupan todos sobre los 380MB, así que rondarían los 1,5GB en ese caso, dejando en un sistema de 2GB con sólo 0,5GB libres para el resto de procesos.

Jorge Mena -

Es cierto eso de que exige en recursos... tanto que me deja la máquina en swap. De mis 2 Gb de memoria, me consumen 2,2Gb sólo las aplicaciones de Ibercivis. La máquina es un Q6600.
Básicamente no se puede trabajar en ella con el Boinc encendido

Mem: 2062712k total, 2047072k used, 15640k free, 36k buffers
Swap: 979920k total, 562908k used, 417012k free, 184624k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ PPID P nFLT nDRT COMMAND
13938 boinc 39 19 443m 384m 1460 R 24.7 19.1 3:13.67 7058 2 6 0 lgv_2.00_x86_64
13939 boinc 39 19 443m 384m 1460 S 0.0 19.1 0:00.00 7058 2 0 0 lgv_2.00_x86_64
13951 boinc 39 19 443m 380m 1456 R 23.2 18.9 0:21.10 7058 1 1 0 lgv_2.00_x86_64
13952 boinc 39 19 443m 380m 1456 S 0.0 18.9 0:00.00 7058 2 0 0 lgv_2.00_x86_64
13576 boinc 39 19 443m 188m 912 R 24.9 9.4 8:57.93 7058 3 212 0 lgv_2.00_x86_64
13671 boinc 39 19 443m 188m 912 S 0.0 9.4 0:00.04 7058 1 0 0 lgv_2.00_x86_64
13575 boinc 39 19 443m 170m 912 R 23.9 8.5 8:37.40 7058 0 2035 0 lgv_2.00_x86_64
13670 boinc 39 19 443m 170m 912 S 0.0 8.5 0:00.03 7058 0 0 0 lgv_2.00_x86_64


Mi portátil no entra en swap, pero poco le falta:
Mem: 2066772k total, 1933612k used, 133160k free, 5304k buffers
Swap: 524276k total, 0k used, 524276k free, 580144k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ PPID P nFLT nDRT COMMAND
20026 boinc 39 19 431m 383m 1116 R 44.6 19.0 26:52.08 2624 0 0 0 lgv_2.00_i686-p
20035 boinc 39 19 431m 383m 1116 S 0.1 19.0 0:00.37 2624 1 0 0 lgv_2.00_i686-p
18736 boinc 39 19 431m 383m 1116 R 45.7 19.0 57:06.78 2624 1 0 0 lgv_2.00_i686-p
18746 boinc 39 19 431m 383m 1116 S 0.1 19.0 0:00.73 2624 0 0 0 lgv_2.00_i686-p

Terminal -

Jeje, si que me suenan esos temas. Por cierto, y por si veis esto, el upload (carga de resultados) lleva caída 8 horas. Nadie - creo - puede entregar sus ficheros de resultados... Gracias