Mailinglist Archive: opensuse-es (1064 mails)

[Rafa Griman <rafagriman@xxxxxxxxx>]

Hola :)


Vaya, no pensaba que se iba a liar tanto ;)


On Tuesday 21 July 2009 17:14:51 Carlos E. R. wrote:
> El 2009-07-21 a las 16:02 +0200, miguel gmail escribió:
> > > Pues no tanto, porque cuando metes un sistema operativo multitarea ya
> > > tienes un ordenador impredecible.
> >
> > Pues no. No es así. Los ordenadores están programados. Y siguen ese
> > programa. Y no hay nada más allá del programa. Las cosas no aparecen
> > de la nada, hay en algún lado una línea de código que explica por qué
> > el programa ha fallado, o ha ido por otro lado.
>
> Si estudiaras informática verías como te dicen lo mismo que yo he dicho,
> que un ordenador multitarea o con interrupciones se considera
> impredecible. No es estudiable en su totalidad, por la sencilla razón de
> que hay sucesos externos al flujo del programa bajo estudio que lo hacen
> no lineal.
>
> Es rizar el rizo, pero es cierto. Es una consideración distinta de la que
> se hace en física.


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.

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.

Otros ejemplos que os puedo poner es cuando clientes nuestros con grandes 
almacenamientos (PB y/o millones de ficheros por directorio) intentan escalar 
o hacen pruebas con TB y pasan a PB. Hasta un punto todo es lineal y de pronto 
todo se cae por los suelos.

Otros ejemplos (no tan grandes) son que el mismo benchmark ejecutado muchas 
veces en el mismo equipo puede dar resultados diferentes. Por ejemplo, tenemos 
gente que se dedica a correr benchmarks estudiando únicamente cómo afecta la 
caché al resultado en función del core en el que se corre la 
aplicación/benchmark. Llega un momento que la discusión/debate es 
completamente incomprensible ya que se ponen a hablar de electrónica, opciones 
de compilación, ensamblador, temperaturas ambientales, ...

Algunos pensarán que este tipo de benchmarks es ridículo porque es demasiado 
bajo nivel ... les remito a lo de la predicción del tiempo y a los 70 
decimales. No es tan ridículo y puede suponer en el diseño de un coche el 
diseño efectivo de un airbag (pensemos en el tiempo de respuesta de un airbag, 
su velocidad, su resistencia, presión, ...) o el poder detectar correctamente 
un huracán y salvar unas cuantas vidas o ahorrar un 1% en el consumo de 
combustible de un avión (que redunda en el billete de avión que luego 
compramos ;).


> 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 ...


> 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;)

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



> Es un concepto distinto del caos como concepto físico o matemático.
>
> > > ¿Caótico? Pues depende de como lo definas. Díselo a los que hacen la
> > > función random(), les encantaría que fuese realmente caótica.
> >
> > Aquí el problema es que intentan obtener una cifra aleatoria en
> > función de algo que no lo es. Intentan, partiendo de algo en principio
> > aleatorio pero muy ciclico intentan añadir complejidad mediante... un
> > programa.
>
> Un amigo mio me enseñó un prototipo de circuito electrónico digital de su
> invención con salida realmente aleatoria, caótica. Hace ya años, y no he
> oído de él, ni sé si lo ha intentado comercializar. Me sospecho que no :-(
>
> > > Ah, y no hemos hablado de las motas de polvo que conducen a veces si y a
> > > veces no tanto situadas entre los contactos produciendo cuelgues...
> >
> > Eso es otro problema. No cuenta :D
>
> Para lo que yo digo de los ordenadores, si :-P


   Rafa

-- 
"We cannot treat computers as Humans. Computers need love."

rgriman@xxxxxxxxx
rgriman@xxxxxxxxxxxx
--
Para dar de baja la suscripción, mande un mensaje a:
   opensuse-es+unsubscribe@xxxxxxxxxxxx
Para obtener el resto de direcciones-comando, mande
un mensaje a:
   opensuse-es+help@xxxxxxxxxxxx