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@skype.com rgriman@jabberes.org -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org