Indie Game

Esta semana vimos el documental Indie Game: The movie, que si bien no se relaciona directamente con la materia de programación multinúcleo, presenta casos reales de desarrolladores que lograron cumplir sus sueños a través de su propio esfuerzo y dedicación.
El documental explora el desarrollo de diferentes videojuegos encargados por sus equipos, que muchas veces estaban conformados por 2 o 3 personas, como Super Meat Boy, Fez y Braid. A pesar de ser grupos pequeños, se puede ver la gran necesidad de tener un control, organización y planeación de sus responsabilidades para llegar a un fin en común.
En lo general, yo no soy un gamer en todo sentido de la palabra, ya que si juego algunos títulos pero me aburro rápido y me pongo a hacer tras cosas, sin embargo, el desarrollo de videojuegos siempre me ha parecido interesante desde el punto de vista técnico, ya que estos requieren de la combinación correcta de programación, para hacer las cosas realidad, diseño para hacerlo estético y usable de forma natural, redacción para hacer una historia interesante y liderazgo para organizar y planear las diferentes etapas del desarrollo.
Personalmente, creo que este documental trata una temática muy interesante e importante en la carrera, ya que muestra la forma de dedicación correcta del desarrollador que logra grandes proyectos. Ya que muestra que la pasión y ganas de hacer las cosas es mas importante que ganar dinero de tus actividades, y que si tienes un sueño es posible realizarlo aunque tengan recursos limitados.
La verdad es que la película muestra una realidad cruda donde podemos ver el estrés real que se sufre al realizar lanzamientos masivos, donde los errores inesperados son siempre presentes y que no es lo mas inteligente realizar cambios de ultima hora en proyectos grandes ya que se desestabiliza el producto.

Welcome to this wild world...

En esta ocasión leímos Welcome to the Jungle de Herb Sutter, continuación del articulo The Free Lunch Is Over del mismo autor que discutimos hace un par de semanas, en este se discute acerca de la adopción de dispositivos con capacidades en Hardware que permiten la implementación y uso correcto de técnicas de concurrencia.
En el 2005 la industria comenzó a incluir dispositivos que utilizaban hardware paralelo (en su mayoría multicore) en sus catálogos de productos, y en tan solo 6 años, en el 2011, lograron completar una importante, y significativa transición en los equipos de sobremesa y portátiles.
Esta revolución nos dejó en una situación en la que hay una gran variedad de dispositivos, tecnologías, y enfoques que aprovechan la concurrencia de alguna u otra forma, nos menciona, obviamente, los procesadores multi-core (ya cubiertos en el articulo citado), el uso de núcleos o unidades de procesamiento especializados (como los GPUs), uso de modelos elásticos (HaaS).
Creo que el autor nos presenta una visión bastante objetiva y acertada acerca de la situación del software en el mundo, ya que a pesar de que la transición ha sido casi transparente para el usuario, el mundo de desarrollo ha sufrido bastantes revoluciones y cambios de corriente de pensamiento en los últimos 30 años. Pasando desde programación meramente procedural, a la de objetos, y esta al descubrimiento de la mejora teoría exponencial del procesamiento, después a concurrencia, y ahora a varios caminos, donde la forma de programar se ha visto muy afectada.
Una cosa que me parece muy importante es la razón de por que todos estos cambios han pasado de manera tan apresurada y abrupta. Creo que las primeras dos revoluciones (programación procedural y orientada a objetos) son simples evoluciones y perfeccionamientos de la técnica de la programación, situaciones que se dan muy a menudo en toda ciencia, pero, las ultimas revoluciones sufridas vienen como consecuencia de la sobreexplotación de La Ley de Moore, que el autor describe como una mina de oro, que comienza rica y donde la extracción es extremadamente barata, y parece que así seguirá (pero toda ley exponencial debe terminar en la practica), la “ambición” de los mineros los llevo a la perfección de circuitos y uso de los transistores para producir mejoras en threads sencillos, y eventualmente a crear múltiples cores usado otra “vena de la mina”, pero la mina sigue agotándose y al decantarse por utilizar la tercera y mas cara de ellas han decidido apostar por múltiples arquitecturas.

Distribuye y vencerás

En esta ocasión leímos el articulo Parallel Computing on any desktop de Ami Marowka, que fue publicado por la revista Communications of the ACM en Septiembre del 2007; en este articulo nos expone una perspectiva de la evolución de la computación paralela hasta esos momentos.

Marowka retoma algunos de los puntos que ya hemos tratado a lo largo del curso, y este blog. Pero haciendo mas énfasis en la implementación practica y económica de este modelo de programación, expone que antiguamente (en la década pasada apenas) era muy costoso obtener equipo que soportara estas practicas, y que solo organizaciones millonarias y universidades de prestigio apoyadas con inversores podían darse el lujo de adquirirlas, hasta que entraron al mercado los Beowulf clústeres, arreglos de computadoras domesticas administradas por software que las hacia trabajar como un conjunto en una tarea especifica, que permitían comprar poco a poco el paralelismo necesario y proveían una escalabilidad casi lineal.

Debo decir que cuando leí este articulo, estaba bastante confundido, pues exponía el uso de arreglos de computadoras como solución al manejo de paralelismo en tareas complejas o mejor dicho CPU bound (que requieren uso intensivo de CPU), cuando este articulo hablaba de programación paralela, y no de computo distribuido, que es el concepto bajo el cual yo conocía estas soluciones (uso de commodity PCs en una tarea en particular colaborativamente); y por esto, me dediqué a investigar en que momento mi entendimiento de la diferencia entre estas dos técnicas falló, según un moderador del StackExchange de Computer Science, la diferencia radica en que el computo distribuido es un subconjunto de las técnicas de paralelización, ya que estas simplemente se enfocan en ejecutar tareas en diferentes procesadores, ya sea que estos compartan el mismo CPU, motherboard, o inclusive caché.

El articulo habla también de la necesidad de que los desarrolladores en común adopten las nuevas tecnologías disponibles para ayudar a paralelizar sus programas, uno de los ejemplos de librerías concurrentes que expone es OpenMP, ya que con pocas líneas de código encima del código ya escrito es posible paralelizar bloques de código iterativos como for, y while.

Gilles. (2012, Abril 29). Computer science stackexchange: Re [Online forum comment]. Extraido de http://cs.stackexchange.com/a/1582