-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-07-22 a las 20:53 +0200, Rafa Griman escribió:
Hola :)
Vaya, no pensaba que se iba a liar tanto ;)
:-)
Creo que lo que quiere decir Carlos es lo siguiente (pong un ejemplo). Cuando se hace un estudio de CFD (dinámica de fluidos) para diseñar un camión o un autobús, se utilizan modelos muy grandes por lo que hacen falta equipos muy grandes. Bien pues nosotros hemos hecho benchmarks con el MISMO modelo en la misma máquina, lo único que ha cambiado es el número de CPUs. OJO!! _NO_ se hizo con cluster sino con una única máquina. Empezamos con 32 procesadores. Pasamos a 64, a 128, 256, 512, 1024, +1024 BOOOOOM. El benchmark cae por debajo de cuando la misma máquina tenía 256 procesadores. Vaya, teóricamente, tendría que haber mejorado el rendimiento, hasta los 1024 procesadores escalaba linealmente. Esto no se esperaba. ¿Qué le pasa? ¿Será la aplicación que no es capaz de trabajar con más de 1024 procesadores? ¿Será la coherencia de cachés? ¿La cantidad de memoria?
Os dejo que le déis unas vueltas al por qué de la repentina pérdida de rendimiento tan bestial >;) Cuando empecéis a formular preguntas y/o conjeturas, veréis que hay muchas más variables de las que pensáis y que un sistema informático no es tan predecible o sencillo como creeis.
¡je!
Creo que es a eso a lo que se refiere Carlos: que no es completamente predecible el funcionamiento de una misma aplicación o de un mismo sistema informático.
Pues no pensaba en eso, yo pensaba en una sóla cpu... pero sí, en efecto, puede ser un ejemplo práctico. ... ...
Lo que pasa es que se hacen ciertas suposiciones, y bajo esas suposiciones el sistema es predecible... hasta que de repente hace algo no previsto.
Espero que mis ejemplos hayan sido válidos 0:)
Sin embargo, todo se reduce a conocer perfectamente el código fuente de lo que se está ejecutando y qué acciones se toman.
No, no te vale, porque otros programas interrumpen al tuyo en momentos que no puedes saber a priori.
En estos el caso del camión que pongo como ejemplo no era problema de código fuente >;) Ooops, os estoy dando muchas pistas ...
Esperaré a que lo cuentes :-)
Podrías estudiar tu programa y qué le sucede si es interrumpido en cada una de sus millones de instrucciones por cada uno de los miles de procesos existentes en el mismo ordenador, cada uno de esos procesos en cada uno de sus millones de estados posibles, y con cada una de las millones de entradas posibles por parte del usuario (el ratón en cada pixel distinto es una acción distinta), etc. Además están las temperaturas de cada uno de los componentes, los posibles rayos cósmicos...
El problema es intratable. Ni con un superdebugger. Se trata porque se hacen suposiciones que lo reducen drásticamente, pero de vez en cuando nos topamos con eso... como los miles de bugs irreproducibles atestiguan.
Hablando de debuggers. Si alguien programa, que nos cuente lo agradable (y predecible) que es depurar (debug) o hacer un profiling de un sw multihilo en sistemas multiprocesador (que cuente sus experiencias en entornos SMP, NUMA y cluster). Sabéis que yo no programo, pero hablando con gente que sí programa (esta gente programa en entornos de más de 512 procesadores NUMA y cluster) y creedme que tienen muy poco sentido del humor cuando les sacas el tema 0;)
No he programado con esos bichos de múltiples cabezas, pero tengo la suficiente idea como para que me dé verdadero pánico.
La programación paralela es mucho más compleja de lo que nos imaginamos y eso de tener el código fuente no es suficiente :( En estos casos influye el código fuente de: - firmwares de CPU y otros chips - debugger - compiladores - profilers - kernel - librerías
Pero es que en casos mucho más simples, como un par de procesadores, puedes toparte con algo tan mundano como que uno de los núcleos atiende la interrupción de reloj, o atiende a otro proceso de los muchos que corren en un Linux continuamente, retrasando uno de los dos procesos principales y haciendo que tenga tarde unos datos que el otro proceso espera a tiempo, y no los tiene. Al no tenerlos, para no estar parado procesa otra cosa mientras espera, es decir, sigue otra rama del código... luego ya tenemos una ruta de ejecución distinta de la que se pensó que iba a seguir inicialmente. Puede que el resultado final sea el mismo o no... depende. Hacemos la suposición de que todo será igual, pero si no lo es... alucinas para descubrir porqué. U otro caso con un simple procesador. No ejecuta sólo nuestro programa, sino varios, pseudo-concurrentemente. Uno de los procesos, pongamos el driver de ratón, que no está bajo estudio (o sea, no es el nuestro) está mal y escribe en alguna posición de memoria que no le corresponde, o altera el estado de algún dispositivo, o simplemente, a veces se le olvida restaurar uno sólo de los registros del procesador... y eso altera el comportamiento de nuestro programa de una manera no prevista. Ya tienes un comportamiento aleatorio. O tienes un proceso de simulación en tiempo real, como puede ser un simulador de vuelo (un juego). Otros procesos que se ejecutan al mismo tiempo le "roban" tiempo de cpu al simulador, que tiene que ceder ciclos de calculo: esto es, en vez de calcular el estado del avión 20 veces por segundo lo hace 15, o peor, 5. Esa mayor granularidad del cálculo hace que el cálculo no sea tan exacto, e incluso el usuario puede notar que el avión no va fino, da saltitos... estamos alterando el comportamiento (y los valores numéricos) que tiene nuestro programa. Probablemente puede compensarlo, pero es algo que no se puede calcular con exactitud a priori cual va a ser la salida exacta de cada bucle del simulador. Puede ocurrir que como consecuencia el usuario estrelle el avión... y no me lo invento, me ha pasado. Todo esto con un sólo núcleo... - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkpnbhQACgkQtTMYHG2NR9WETQCgknrFrv+iVFqQZbuKc+SSGD+3 XJsAmgIxR0vzpuBkTRNl2OpYtt0mtPB6 =ftmb -----END PGP SIGNATURE-----