hoy vamos a hablar sobre paralelismo y sus
efectos sobre los MBA

en los tempranos 80 Danny Hillis 
desarrolló una arquitectura para una

computadora en paralelo a la que llamó la
"máquina de la conexión"

a diferencia de las máquinas von Neumann
tradicionales de las que estuvimos

hablando antes, no había un solo CPU, sino
había miles de unidades de procesamiento

central, miles de procesadores de bajo 
costo y baja capacidad conectados todos

juntos, entonces qué es un procesamiento
central? la idea era que cada uno de los

procesadores individuales podían 
representar un solo cálculo o un evento

él desarrolló el marco de trabajo conocido
como Simple Instrucción para Múltiples

Datos, una de las formas de entenderlo es,
imaginen que tienen un conjunto de datos

similares, distribuído por todas estas
máquinas diferentes, estos procesadores

diferentes, no puedo decir máquinas porque
están todos en una máquina

todos tienen datos levemente diferentes, 
pero uno puede enviar una instrucción sola

que será preguntada a todos los 
procesadores, manipulando estos datos que

son diferentes en la misma forma. Hillis
fundó "Thinking machines" para poder

comercializar este producto

El problema es que esta noción de máquinas
paralelas, procesarores paralelos son muy

pero muy difíciles de programar, nosotros
hacemos como que actuamos en máquinas

paralelas, nuestro cerebro se prende en
llamas en formas paralelas y nos gustaría

pensar en una forma lineal, en una forma
secuencial

uno tiene que percatarse de que hay 
lenguajes especiales que permiten

programar estas máquinas, para finales de
los 80 aparecieron lenguajes como StarLisp

and C-Star, desarrollados para programar
las máquinas de conexión, lo que se

llamaba la máquina de conexión; de hecho
el CM-2 tiene 65536 procesadores

individuales, los datos se distribuían por
todos los procesadores y como efecto de

ello, hay muchas cosas que involucraban
muchos conjuntos de datos, y eso era algo

que era sencillo de hacer con estas 
máquinas, por ejemplo la recuperación de

documentos; imaginen 56 mil documentos,
tienen estos procesadores, un solo

documento que están buscando, le dicen a
estos procesadores que cuenten el número

de veces que la palabra "conexión" aparece
en estos documentos

uno puede extraer el documento que posee 
el mayor número de ocurrencias de la

palabra "conexión" de manera muy rápida
con este sistema, mucho más veloz que con

un solo procesador

lo mismo con el reconocimiento de objetos,
trabajando con gráficos en vez de texto

es muy útil para cosas como los autómatas
celulares, debido a que los autómatas

celulares pueden leer los estados de 
entrada de sus vecinos, actualizar esos

datos y enviar salidas

de hecho StarLogo, del que uno puede 
pensar como una forma temprana de MBA

fue escrito en StarLisp y utilizaba estas 
mismas nociones, de hecho influyó en la

forma de desarrollo en la que trabajaron 
otros MBA que andan por ahí

qué tiene que ver la programación paralela
con los MBA? tenemos esta idea, tenemos

muchos, muchos diferentes entidades que
tienen todas sus propias computaciones

individuales y muchas veces los MBA tienen
como objetivo pensar en ellos como

entidades paralelas que actúan y aún en el
final lo escribimos todo desde un punto de

vista secuencial, en muchos sentidos, el
paralelismo nos da una noción que emerge

de pensamientos donde uno puede crear un
MBA con esta idea de que las cosas pueden

suceder en forma simultánea

dentro de esta discusión interesante, las
diferencias entre sincronización y no

sincronización, paralelismo o secuencia y
así; haremos una pequeña inmersión en uno

de los modelos que muestra un poco las
diferencias que están ahí, y que es el

modelo de las termitas en NetLogo, vamos a
hablar un poco de ello

El paralelismo tiene múltiples efectos en
nuestros pensamientos, en como construir

los MBA, aún cuando haya muchas 
plataformas diferentes de MBA que son

seriales

Aquí tengo el modelo de las termitas, que 
está en la biblioteca de modelos de

NetLogo, bajo "Biología", "Termitas"

este modelo muestra algunas 
características, uno de los ejemplos que

tratan de hacer que las tortugas actúen
como si estuvieran operando en paralelo y

por eso creo que es importante hablar un
poco de ello. Si lo notan,

este botón tiene un pequeño símbolo acá
arriba

que es una tortuga pequeña como indicador
y esto es porque el observador no está

ejecutando el "go" en este caso, en vez es
la tortuga la que va a ejecutar, es la

tortuga, es un botón de tortuga como 
distinto de un botón de observador

si miramos el código

tiene en verdad a cada una de las tortugas
como ejecutoras del código, es casi como

si estuviera haciendo un implícito "ask"
para cada una de las tortugas

de hecho los botones, cuando lo hacemos de
esta forma es similar a hacerlo en forma

concurrente, cada una de estas, el modo en
que trabaja este mundo es que cada una de

las tortugas pueden tener un orden 
aleatorio para ejecutar una pieza de este

código hasta que cambian o actualizan el
mundo que las rodea y es cuando pararán

y pasarán el control a otra tortuga, que 
será la siguiente y ésta pasará el control

hasta que todas las tortugas ejecuten los
tres comando estos y volverá a empezar

cuando clickeamos en "setup" y luego "go"

no es en verdad obvio que algo diferente
está sucediendo excepto por que se pone un

poco más lento, notamos que cada 
tortuga no ejecuta completamente todos los

comandos hasta que la próxima ejecución

este modelo está realmente operando en una
forma simulada concreta, si lo aceleramos

un poco y lo corremos, qué es lo que hace?
lo que hace, si aplicamos el "setup"

pueden ver que cada tortuga empieza en
blanco, si levantan una pieza de madera

amarilla la llevan hasta que puedan 
encontrar otra pieza, otro lugar donde

dejarla y cuando la dejan la dejan y lo 
que sucede es que estas piezas empiezan a

acumularse unas al lado de otras; esto se
debe a que las termitas dejan las piezas

en el primer lugar que encuentran, luego
de que la levantaran y la transportaran

hasta donde la dejarán

si miramos el código, tenemos el "search-
for-chip", si hay un parche amarillo acá

levantalo, pintá el parche de negro, 
avanzá 20 pasos, luego zigzagueá y empezá

a buscar nuevamente

perdón, si no es el parche amarillo 
entonces zigzagueá y buscá el pedazo, así

continua buscando

y luego vemos "find-new-pile" donde si el
parche no es amarillo, en otras palabras

no estoy en una pila, entonces zigzagueo y
trato de encontrar una nueva pila

y así mantenemos, si tenemos un pedazo

nos mantenemos moviendo hasta que hallemos
un nuevo pedazo

luego dejamos el pedazo donde encontremos
un espacio vacío

uno podría decir, este código es un poco
confuso, ya que "search-for-chip" llama a

"search-for-chip", las tortugas están 
entrando en un bucle infinito, pero

recordemos, estas tortugas están operando
concurrentemente, no se están esperando

esta tortuga puede quedar atrapada en el
código por un rato, mientras que otras van

para adelante y por tanto comparten el 
código muchas veces, se actualizan a

través de todos los comandos muchas veces
todos juntos. Entonces las tortugas pueden

estar en diferentes estados en distintos
tiempos, antes de completar el círculo

completo de lo que está ocurriendo allí;
no están esperando que el otro haga algo

en un orden secuencial

esta es una pieza de código muy 
interesante, vale la pena más que modelos

más tempranos de NetLogo y realmente va
atrás con algunos de los trabajos de 1997

yo les recomiendo que los vean si están
interesados en como hacer programación en

paralelo

de hecho si miran

acá dice que la tortuga sigue moviéndose
por un tiempo, porque están terminando los

comandos y así se mantienen corriendo, no
avanzan hasta que terminan todo

entonces si clickeamos en "setup" y en 
"go", podemos ver que sucede esto, podemos

hacerlo más lento, avanza y se frena y aún
se mantiene corriendo

por un rato, porque tiene que dejar que
todas terminen, por lo menos una vez

es una pieza de código muy interesante, es
muy diferente, es un paradigma diferente

que los otros modelos de NetLogo

gracias