Harder, better, faster, SIMD

Los sistemas computacionales son sin duda alguna indispensables para múltiples actividades cotidianas. Podemos realizar actividades de oficina, buscar puntos específicos en la ciudad, ver fotos, editar videos, reproducir música, y muchas otras cosas más. Sin embargo, muchas de las aplicaciones más recientes no existirían de no haber sido por el desarrollo de los lenguajes de programación, y de las computadoras mismas.

Todos los lenguajes de programación tienen su origen en un lenguaje final: el binario. El binario es el verdadero dialecto computacional. Pero este no es un lenguaje que sea fácil de programar, y mucho menos de leer. Dado esto, se implementó una tecnología que permitiera a un usuario con  conocimientos suficientes acerca del hardware, para poderlo programar: el ensamblador.

Una de las variantes del ensamblador, es la implementación tipo SIMD (Simple Instruction, Multiple Data). Este tipo de implementaciones en ensamblador permiten agilizar el procesamiento de instrucciones que se repiten (como en un ciclo for en C), de tal forma que se aprovechan los componentes del procesador (registros y memoria caché, principalmente). Sin embargo, el uso de este tipo de implementaciones tiene ciertas restricciones:

·       1.  No es fácil escribir un programa en ensamblador si no se tiene una idea de qué se va a hacer.

·        2.  Al nivel de programación que tenemos hoy en día (por la complejidad de los lenguajes para su fácil uso), si no sirve en un lenguaje de nivel superior a ensamblador, no tiene caso hacerlo en ensamblador.

·         3. Dependiendo de la arquitectura del procesador, se deben considerar el número de bits y bytes a procesar en los registros.

·         4. El total de bytes a procesar debe ser múltiplo del total de registros a utilizar, siendo también congruente con el número de bits de éstos.

Este tipo de implementaciones resulta interesante, ya que una aplicación puramente en C, puede alcanzar speed ups de más de 20 unidades, cuando la implementación del código paralelizable es una extensión SIMD bien realizada.

Nadie dijo que fuera fácil, pero alguien tiene que hacerlo

El cómputo paralelo, como hemos estado discutiendo a lo largo del semestre, es una de las tendencias con mayor importancia en esta década. Existen múltiples plataformas de hardware que soportan el cómputo paralelo. Estas plataformas están en uso desde el año 2004. Sin embargo, el software generado en años anteriores (incluso el actual) no está pensado para trabajar de forma paralela.

El problema radica principalmente en que el paralelismo, a pesar de que es posible enseñarlo en las escuelas con piezas de hardware económicas (laptops, tarjetas multinúcleo, GPU’s, entre otros), no se le ha dado la importancia que requiere para su desarrollo.

Una de los grandes campos de paralelismo a nivel mundial (y comercial) es el mercado de los videojuegos. Cada día, vemos cómo empresas como Microsoft, Sony, entre otros, compiten arduamente por ofrecer a los fans una plataforma que les brinde mejor desempeño y videojuegos cada vez más específicos para satisfacer las expectativas de los mismos jugadores. Este mercado no sería tan fuerte, de no ser por la gran capacidad de cómputo paralelo que se realiza a nivel de hardware y a nivel de software en las consolas.

Los problemas crecen conforme las ambiciones son mayores. Dado a que gran cantidad de segmentos de código han sido elaborados de forma secuencial, pensando en que el desarrollo de procesadores más rápidos radicaba en la frecuencia de reloj,  la forma más “rápida” de paralelizar el código es ver qué segmentos son candidatos a paralelizado. Posteriormente, se deben hacer pruebas para verificar que no haya bugs. Esta etapa, sin duda alguna, es la más difícil y tediosa de todo el proceso.

A veces, nos preguntamos a nosotros mismos por qué no reescribir el código, tomando en cuenta la capacidad de paralelismo que se tiene. Sin embargo, abrimos un archivo que tiene millones de líneas de código (como el de un kernel, o un sistema operativo completo), y vemos que es muy mala idea. Especialmente, en los códigos que corren en servidores bancarios, o gubernamentales.

Para estos casos, lo mejor que se ha logrado es el desarrollo de módulos que, con simples instrucciones, se paralelizan ciertas partes del código. Un ejemplo de estos módulos es OpenMP, que con directivas a compilador (pragmas), se pueden paralelizar segmentos de código, ciclos for, entre otras cosas.

El paralelismo es un gran reto, tanto a nivel de desempeño del hardware, como el desarrollo del software especializado. Y, dada la importancia que esto tiene, es imperioso que se acepte el reto, y comencemos a ser más eficientes a la hora de programar, tomando en cuenta el paralelismo como herramienta fundamental.

MapReduce y su simulación de procesos

Este artículo acerca de la tecnología MapReduce, escrito por Dean y Ghemawat, me resultó un tanto interesante, ya que habla acerca de qué es esta tecnología y cuál es el enfoque con el que se desarrolló.

Como hemos visto en artículos diferentes, este es otro esquema de paralelismo computacional. Pero lo que lo hace diferente a los demás, es su estructura de funcionamiento y el sistema en el que corre. El sistema de ejecución de este esquema podría ser implementado en cualquier ordenador, pero funciona mucho mejor en un cluster. Un cluster es un arreglo de varias (muchas) computadoras conectadas entre sí, que pueden ser utilizadas para un sinfín de propósitos. Uno de estos propósitos es la búsqueda de información en la red, tal y como es el servicio de Google.

El funcionamiento de MapReduce puede asemejarse un poco a lo que es una cadena de producción, o una búsqueda en masa de la información. Si suponemos que los datos clave que se deben buscar es una petición de producción, y los documentos donde se busca es la materia prima, existen varios threads (también llamados workers) que se encargan de realizar la búsqueda de los materiales necesarios que se deben utilizar para la producción del lote en cuestión. Posteriormente, cuando los workers terminan, otro conjunto de trabajadores realiza la producción del lote, generando un resultado. Esto viéndolo desde una perspectiva muy sencilla. MapReduce cuenta con su propio calendarizador (scheduler), el cual es el equivalente al líder de equipo o administrador de proyectos, quien es el que se encarga de asignar tareas específicas a cada trabajador, y en caso de que uno acabe antes que los demás, le asigna más trabajo para que no esté en estado de ocio la mayor cantidad de tiempo (siempre y cuando haya algo que hacer).

Me pareció muy interesante ver la esquematización de esta tecnología, ya que se asemeja mucho a situaciones como la anterior, y que tiene un manejo de errores muy eficiente, el cual consiste en que si por algo falla un trabajador, otro toma su lugar y ejecuta lo que el primero deió hacer para poder tener el resultado consistente. Esto, tanto en el algoritmo como en la vida real, resulta ser muy bueno, ya que en un equipo no podemos depender 100% de nuestros colegas, y menos cuando se presenta una falla (baja de energía, un segmentation fault, enfermedad [bug], etc.).

Erlang: un cambio de perspectiva

El artículo escrito por el profesor Ariel Ortiz resume lo que, desde el inicio del curso de programación multinúcleo, nos ha ido diciendo: el paralelismo a nivel de software es un hecho que no podemos ignorar. Y, como ingenieros en software (y algunos en hardware), debemos ser capaces de poder utilizar y explotar las bondades que las nuevas tecnologías nos ofrecen.

Siempre he sido fiel partidario de que hay cosas que el software no puede realizar sin el hardware adecuado. Un ejemplo relevante es la unidad de punto flotante. Sin este módulo, todas las operaciones aritméticas que tengan números flotantes, simplemente se quedarían siempre truncadas a su entero. En este caso, el paralelismo en software se puede dar ya que existen procesadores con más de un núcleo en el mismo chip. Y ahora, con las redes de computación y otras tecnologías, se puede hacer paralelismo utilizando más de una máquina para ello.

Otra de las aseveraciones que defiendo es que el software potencializa al hardware. La verdad, no me imagino programando una computadora con puros ceros y unos (que no niego que sería interesante y al mismo tiempo agobiante). Los lenguajes de programación en sí son un fuerte ejemplo de que el software potencializa al hardware. Sin lenguajes de programación, muchísimas cosas que utilizamos hoy en día podrían existir, pero requerirían de mucho tiempo de trabajo y corrección para que funcionen de manera “aceptable”.

Dados estos dos argumentos, considero que Erlang es una herramienta interesante, empezando por el tipo de lenguaje que es. Los principios por los que surge el lenguaje son interesantes, y su impacto en las aplicaciones más actuales son sorprendentes, considerando que tienen miles de usuarios activos todo el tiempo y que la eficiencia es muy satisfactoria. De no ser así, no tendría caso utilizar Erlang.

En otros cursos, he tenido la oportunidad de utilizar esquemas de threads, Message-passing, entre otros. Pero Erlang promete algo diferente. Para empezar, el hecho de comprender su sintaxis me da curiosidad de cómo funciona la herramienta, y de ver qué cosas podría hacer con ella. Actualmente, estaré aprendiendo Erlang y Cuda al mismo tiempo, por lo que tendré la oportunidad de ver el enfoque de ambos lenguajes, y ver qué podría hacer de manera individual o en conjunto.

Erlang y los nodos concurrentes

La concurrencia es uno de los esquemas más recientes que se han introducido a la computación. Como es sabido, y como lo reitera Joe Armstrong en su podcast, la concurrencia se generó alrededor del año 2003, una vez que las empresas que fabrican procesadores llegaron al límite físico, en la tendencia por el incremento de la frecuencia de reloj de los mismos procesadores. La razón principal: sobrecalentamiento, ya que la misma frecuencia de reloj incrementa proporcionalmente la potencia consumida por el procesador. Dado esto, la nueva tendencia es el desarrollo de chips que contengan varios procesadores, capaces de trabajar simultáneamente, ya sea compartiendo información en memoria, o cada núcleo con su segmento de memoria privado.

Joe Armstrong enfatiza que muchas de las tecnologías que se usan hoy en día para generar concurrencia, en realidad no son concurrentes, sino que sin formas de hacer que el calendarizador del sistema operativo mande los diferentes procesos, o threads a los diferentes núcleos que tiene una misma computadora. Sin embargo, estas tecnologías no permiten que un sólo ordenador envíe procesos a los núcleos de otro ordenador. En otras palabras, si tenemos acceso a otro ordenador mediante una conexión a Internet u otro medio, no podríamos utilizarlo para realizar multiprocesamiento aunque el vínculo sea compatible para ello. Se pueden implementar tareas como el “message passing”, entre otros; para realizar multiprocesamiento. Sin embargo, estas implementaciones son costosas en tiempo y recursos de los equipos.

Erlang es un algo similar a un sistema operativo que permite a los programadores realizar segmentos de código que realmente sean capaces de correr por sí mismos en una computadora con un procesador multinúcleo, e inclusive utilizar nodos para intercomunicar computadoras entre sí, y que cada proceso funcione de manera independiente completamente, en relación a los demás núcleos y/o chips de procesador. Una de las cualidades de Erlang, es que soporta el “message-passing”; sin embargo, esto se utiliza solamente cuando es requerido, y no es una implementación fija en cada programa en Erlang.

Joe Armstrong enfatiza que hay 3 cuestiones en las que debemos siempre tener cuidado para lograr una verdadera aplicación concurrente, y evitar muchas cosas que terminan haciendo de nuestro programa una implementación más parecida a una secuencial que a una paralela: a) el tiempo de cambio de contexto, b) el tiempo de paso de mensaje, y c) el tiempo de creación de los procesos. Personalmente, a estos puntos les puedo dar validez, como ingeniero electrónico, ya que a nivel de hardware es más eficiente un procesador que tarde menos en cambiar de contexto, en especial para las aplicaciones de alto riesgo y que trabajan mediante interrupciones. Si un procesador se espera mucho tiempo en atender una interrupción de alta prioridad, la secuencia de atención no sería ejecutada a tiempo, y podría tener resultados catastróficos. Por ejemplo, si tenemos un microcontrolador, interconectado con muchos otros, y este microcontrolador tarda en procesar que nuestro coche ha chocado y no trabaja oportunamente, el mensaje que debe recibir el microcontrolador que maneja las bolsas de aire, no las abriría a tiempo y los pasajeros correrían peligro de muerte.

Será interesante ver las implementaciones que se pueden hacer con Erlang, y las ventajas que tiene este “lenguaje” en comparación de las tecnologías thread y Fork/Join.

Lambda no sólo significa "longitud de onda"...

Como se menciona en el podcast que Freddy Guime realizó, las expresiones lambda no son cosas que resulten recientes, ya que se han utilizado desde que se empezaron a diseñar los lenguajes de programación de los años cincueta. Sin embargo, este concepto para mi resulta nuevo, ya que muy pocas veces me he encontrado con una expresión lambda en todos los archivos de código que he realizado desde que comencé a programar, e inclusive en los libros de lenguajes que me han encargado que lea.

Resulta “mágico” que una pequeña sentencia sea tan útil como escribir una línea, o inclusive un bloque de código completo, en unos cuantos caracteres, además de utilizar el token “->”. Esto, al principio, resultó un tanto confuso para mí. Lo primero que pensé fue “¿apuntadores en Java? Interesante…”. Pero, claramente, no hay tal cosa en Java. Al menos no de manera explícita en el lenguaje.

Hasta como hemos visto en clase, y dándole crédito a lo que comenta Freddy Guime en su podcast, las expresiones lambda se pueden ver como una expresión “mutable”. Es como una función que puede cambiar de comportamiento, de acuerdo a lo que le solicitemos en la misma expresión lambda.  Y es mucho más sencillo y más rápido que estar creando nuevas clases, o inclusive andar sobreescribiendo la funcionalidad del método run() de la clase Runnable, lo cual tiene un impacto admirable en la simplicidad que le dá al escribir un código en un lenguaje tan verboso como lo es Java.

Una de las “limitantes” que tiene el uso de expresiones lambda en Java, es que el programador debe declarar interfaces funcionales. Estas interfaces, por definición, son aquellas que únicamente contengan un método en ellas. Sin embargo, el hecho de tener que escribir una interface de una línea en lugar de una clase completa (la cual puede tener muchísimas líneas de código para poder funcionar correctamente), es un pequeñísimo “sacrificio” que se debe realizar para poder ahorrarnos tiempo de programación, y en cierta forma tiempo de cómputo en la implementación que estemos programando.

Espero tener la oportunidad de ver una implementación real con expresiones lambda, para poder comprender de mejor manera su funcionamiento, tanto a nivel código como a nivel de desempeño, y tenerlas siempre en cuenta para futuras implementaciones que yo realice, ya sea en Java o en cualquier otro lenguaje de programación que las utilice.

La perseverancia es clave para el éxito, incluso para terminar Super Mario Bros.

En el video documental, se plantea perfectmente el caso de 3 proyectos. Estos proyectos son un tanto singulares, ya que no son “proyectos” como los que normalmente llamamos así: son videojuegos. Sí, los videojuegos también son proyectos de, al menos, mediano plazo, ya que requieren una buena cantidad de tiempo y esfuerzo para poder realizarlos. Además de un poco de dinero, claro. Estos tienen la particularidad de que fueron desarrollados por “agentes libres”; es decir, personas que no trabajan para una empresa, sino para sí mismos.

Estos tres proyetos en paticular ilustran varios aspectos con los que siempre lidiamos en nuestra vida diaria. Sin embargo, si realizamos un trabajo o algo que nos apasiona con tanto ahínco, realmente plasmamos todo nuestro pensar y nuestras emociones en el proyecto. No cabe duda de que estos 3 videojuegos son geniales, no sólo por sus temas o por la manera original de jugarlos, sino porque se ve que están buenos, los 3 tienen características únicas (tanto de jugabilidad como de temas) con respecto a otros juegos que ya están en el mercado), y sobre todo porque los 3 tienen plasmados en ellos los ideales y sueños de los desarrolladores.

En el video se muestra que, lejos de tener un beneficio económico por el juego, los desarrolladores están más preocupados porque la gente de verdad se divierta jugando los juegos, que recuerden los buenos tiempos de los juego que eran extremadamente difíciles, y sobre todo que la gente entendiera el mensaje que estaba plasmado en los juegos: sus emociones y sus sueños.

Desafortunadamente, muchas cosas pueden pasarle a cualquier proyecto que realicemos en nuestras vidas. Así, cada juego tuvo un resultado distinto. Uno de ellos fue exitoso, tanto en críticas como en ventas y en captación del mensaje plasmado. Uno de ellos sufrió complicaciones, pero logró obtener un colchón de tiempo para depurar defectos y mejorar la funcionalidad. Así mismo, uno de ellos sí tuvo venta, pero fracasó porque muy, muy pocos usuarios entendieron el trasfondo del juego, y lo tacharon de ridículo, aburrido y “choteante”.

Aun así, en los 3 juegos se demuestra un gran muy alto de perseverancia, ya que, apesar de los problemas legales, económicos, sociales, entre otros; todos los desarrolladores han puesto toda su energía en lograr algo que ellos quieren, con un nivel de perseverancia tal que unos estuvieron al borde de la locura por conseguir lo que querían: un proyecot funcionando.

Este ejemplo, en lo personal, me ha motivado a mejorar mi perspectiva con respecto a lo que hago en mi día a día, y que no importa qué tan trivial o difícil sea el reto, siempre hay que hacerlo con todo el esfuerzo que se requiera, con perseverancia y actitud positiva. Pero más aun, el hecho de vincularnos emocionalmente con algo que realizamos, nos mueve a hacerlo cada día mejor, y sobre todo, con las únicas ganas de dejar algo como legado en este mundo.

La jungla: hogar de transistores, condensadores y procesadores salvajes que quieren devorarnos.

Como menciona Herb Sutter en su artículo de “Bienvenidos a la jungla”, el desarrollo del hardware ha sido de gran relevancia para la ciencia computacional en todos los campos. No solo es importante para alguien que utilice una computadora (ya sea un usuario común o un desarrollador reconocido) la velocidad con la que se desempeña el sistema, sino también que se puedan realizar diversas tareas al mismo tiempo. Esto se ha logrado por las dos vías principales: el aumento de la velocidad de procesamiento de un núcleo, y la capacidad de este para trabajar “en equipo” con otros núcleos.

El expresión “la unión hace la fuerza” adquiere relevacia en este rubro, tras la aparición de los procesadores multinúcleo; y su significado se vuelve definitivo con el desarrollo de los clusters, o servidores de nube. No sólo hay computadoras con más de un núcleo trabajando en tareas específicas, sino que hay muchas computadoras y dispositivos embebidos, comunicados entre sí a través de diferentes protocolos de comunicación (por hardware: Ethernet, WiFi, Bluetooth, Serial, I²C, SPI, entre muchos otros; y por software: Sockets, DNS, HTTP, FTP, OpenMP, MPI, entre otros).

Resaltando lo que mencionó Herb Sutter, y en lo que en particular estoy de acuerdo, la ciencia de la computación actual no puede quedarse estacionada en la programación secuencial; hay llegado su momento de evolucionar (irremediablemente), caer en la cuenta y adaptarse a su futuro: el paralelismo. El paralelismo actual, sin lugar a dudas, es un poco primitivo, ya que no se ha aprovechado el 100% de las capacidades que los ordenadores tienen hoy en día. Y mucho menos con la aparición de la tecnología contemporánea más importante de la era de la comunicación: la Internet. Con Internet, podemos realizar un sin fin de aplicaciones paralelas. Además, cuando guardamos archivos en la nube, los archivos no están estrictamente almacenados siquiera en el mismo disco duro. Pueden estar en más de uno. Con esto, se puede enfatizar el hecho de que el paralelismo no solo golpea al procesamiento en sí, sino también al almacenamiento de información.

Con el paralelismo aplicado 2 de los módulos principales de una computadora; el procesamiento y el almacenamiento de información; el hardware ya tiene la capacidad de realizar muchas cosas diferentes, y nos da nuevas posibilidades. Situación que no hubieramos alcanzado con el procesamiento tradicional de von Neumann. Es momento de aprender a programar de manera concurrente, y aprovechar lo que el hardware nos está brindando hoy en día. Aunque no lo parezca, si no nos forzamos como ingenieros en software a aprovechar esta oportunidad, no nos daríamos oportunidad como ingenieros en hardware a ver un nuevo reto y mejorar las arquitecturas con el paso del tiempo, ya que “un mejor desempeño que el actual” no va a ser requerido.

El paralelismo y su discreción en nuestra vida

A pesar de que el artículo es un tanto viejo, tiene una buena redacción acerca de la tendencia que tuvo el paralelismo computacional. Y no se equivocaba el autor al respecto. El paralelismo hoy en día es importante para el desarrollo de infinidad de aplicaciones de software.

Los usuarios no se percatan de ellos, pero el paralelismo está vigente en muchos de los servicios web que utilizamos, como youtube, facebook, outlook, entre muchos otros. Otro ejemplo de paralelismo importante es la industria del videojuego. ¿Cómo es posible que puedas jugar Halo con tantos bots, escuchar la música de ambientación, e incluso jugar contra jugadores humanos? La respuesta es sencilla: paralelismo.

Como menciona el autor, parte fundamental del paralelismo actual se debe a la fabricación de procesadores de multinúcleo, ya que sin ellos, la gente no tendría acceso a muchas de las aplicaciones mencionadas, y tendría que estarse capacitando para poder utilizar los clusters, cuyo acceso sólo lo tienen (y lo seguirán teniendo) las grandes empresas y los gobiernos más fuertes, económicamente hablando.

Es bien cierto que mucha gente se basa en algunas cosas para decir “yo compro esta máquina”. Y una de ellas es el procesador que tienen. No saben qué significa que tengan 4 núcleos a ciencia cierta, pero eso les indica que la computadora es capaz de realizar más tareas en un periodo de tiempo. Sin embargo, de nada sirve tener una computadora super buena, con 16 núcleos, si las aplicaciones no soportan esta arquitectura, y si no son diseñadas adecuadamente para ella.
Por esto, como programadores, sin importar tendencia, objetivo, preferencia en cuanto a lenguaje, ambiente de programación, entre otros; debemos siempre tener en cuenta que ya es posible realizar paralelismo, y que esto nos dará la ventaja sobre los programadores que están aferrados a seguir programando de manera secuencial para un solo núcleo. El paralelismo le dará un grado más de escalabilidad a nuestro trabajo, y con algo de suerte, nuestros clientes no nos estarán pidiendo que volvamos a desarrollar el mismo programa (que nos costó 3 años de arduo trabajo) para una computadora con mayor capacidad, simplemente porque el hardware ya no es compatible con el software.

Y, a decir verdad, no es necesario que estemos casados con una tecnología de paralelismo. Podemos seguir solteros o ser polígames, y probar con muchas y diferentes tecnologías, como MPI para C, OpenMP, Pthreads, Java threads, Kuda, entre muchas otras opciones, que siempre tendrán ventajas respecto al enfoque que les demos, y que nunca está por demás ir a la vanguardia, sin la necesidad de tirar a la basura lo que hemos programado hace unos años.

The free lunch is over... but dinner has been ordered.

Multicore processors sound like the hit of the moment. However, these technologies are quite old. The first multicore processors had been designed on 2004 approximately. Over 10 years! That’s significant for a “modern” technology. By this, most people believe that computers can run much more programs in lower time. And their intuition could be right unless the fact that they don’t. Why this happens? The answer is simple: programs are not designed to be run on more than 1 processor at once.

This problem has created users’ disappointment because we, as users, want speed, effectiveness, reliability, and so many other characteristics from a computer. And this expectations increase on quantity and quality every year, due to marketing, and some other techniques sellers use to convince us to buy a brand-new computer every year (at least). 

As we can read on Suttler’s article, multicore processors have substituted the “Moore’s law”. Hardware engineers are not spending more time on researching how to increase clock speed because, no matter how simple or complex the processor architecture is, the processor dissipates more energy on heat proportionally to the clock speed. In other words, the faster the clock is, the more heat the processor dissipates. And, of course, heat can damage performance, even destroy the processor. This is one of the main reasons that clock speed is not a task to improve.

Nowadays, we use computers that have multicore processors. And this fact works hand-to-hand with hyperthreading and cache-size-increasing trends. As Suttler says: if we increase the size of cache blocks, we can avoid more “miss” events and change them for “hit” events. Then, the second technique in order to use all functionality given by multicore processors is: parallelism.

However, parallelism is not a common way to program, and this is due to its complexity. But, this is not an excuse to keep programing on single-core based way, because, when it comes to performance, the only way to speed up programs nowadays is by learning to parallelize our programs, and allow the multicore processors to use they physical advantages, where and when possible.

Programmers can keep programming under single-core layouts. But, if they want to have a better performance of their own codes, they must learn how to split processes, and exploit most of the resources of the new systems.

If we can manage 2 cores, there is a change that we can handle more cores, and give our users the possibility to do much more things at a time.

Notes:

A “hit” event occurs when the piece of data that the processor is waiting for is already loaded on cache.

A “miss” event occurs when the piece of data that the processor is waiting for is not located on cache, and the system must search for it on the principal memory or the hard drive, and then fetch it from that location.

Suttler, H (Aug, 2009). The Free Lunch is Over. Retrieved on August 23, 2015, from http://www.gotw.ca/publications/concurrency-ddj.htm

Entrada 1: comienza la instancia

• Mi nombre es Pedro Cámara Martínez. Soy alumno de la carrera de Ingeniería en Sistemas Digitales y Robótica, de noveno semestre. Soy candidato a graduar. En este semestre cursaré únicamente 4 materias, ya que cursé diferentes materias en los 4 veranos de mi carrera.

• Mis expectativas de la materia Programación multinúcleo son:
• Aprender a manejar eficientemente los recursos del procesador.
• Complementar mis temas de este rubro con mi materia de multiprocesadores (hardware).
• Divertirme aprendiendo nuevos lenguajes de programación.
• Tener una experiencia más con la programación concurrente.
• Aprender a separar la programación secuencial y convertirla eficientemente en programación paralela. 

• Mis pasatiempos e intereses personales son:
• Escultismo
• Campismo
• Natación
• Música
• Tango

• Libros, música, películas, programas de televisión, etc. que he recientemente disfrutado:
• Libros:
• Las crónicas de Narnia: el caballo y el niño.
• Las crónicas de Narnia: el príncipe Caspian.
• Las crónicas de Narnia: el viajero del Alba.
• Fable: The Barlverine Order.
• Assassin's Creed: Brotherhood (hay libro del juego XD). 
• Música:
• Los pericos.
• Los cadillacs.
• Nightwish.
• Sonata Artica.
• Il Divo.
• Carlos Di Sarli.
• Juan Carlos Caceres.
• Programas de televisión:
• Breaking bad.
• Attack on Titan.
• Películas:
• Los minions.
• No se metan con el Zohan.
• Star Wars
• El Señor de los Anillos.