Archive for 2014
SIMD. Such fascinating evolution.
¡Hola! :D
En esta ocasión, hablaré sobre el artículo titulado Teaching the SIMD Execution Model:
Assembling a Few Parallel Programming Skills escrito por Ariel Ortiz y
publicado en las memorias del 34° SIGCSE Technical
Symposium on Computer Science Education en febrero del 2003.
En el artículo se habla sobre el modelo Single-Instruction/Multiple-Data (SIMD), el soporte de éste mismo
en procesadores Pentium 4 y sobre algunos idioms
que pueden ser usados. Primero que nada, hay que recordar que SIMD permite procesar
varios elementos de manera simultánea, lo que implica que tendrá un mejor
comportamiento que el procesamiento secuencial. En la actualidad, todos los
procesadores soportan algún tipo de tecnología SIMD, entre las cuales destacan
MMX o SSE (las cuales fueron muy populares cuando fueron lanzadas).
El soporte de SIMD puede verse de muchas maneras. En el caso
del Pentium 4, existen 8 registros y dependiendo de cómo utilicemos las instrucciones
es la manera en la que vamos a manejar dichos registros. Éstos pueden manejarse
de varias maneras, desde palabras de 8 bits hasta palabras de 128 bits o tipos
de dato float en C.
Una parte importante del SIMD son los denominados idioms, los cuales son patrones son
patrones para soluciones de bajo nivel. Con ellos, se puede entender de una
mejor manera como usar SIMD. Estos idioms
se pueden considerar como algunas aplicaciones sencillas de SIMD para
familiarizarse con el uso de esta tecnología, y cada uno de ellos tiene
instrucciones específicas que son necesarias para los mismos y que a su vez
ayudan a comprender su funcionamiento individual. Si tomamos de ejemplo el complemento
a 2. Para este idiom podemos usar las
instrucciones pcmpeqb (comprobar si dos elementos son iguales) y pxor (instrucción
XOR), debido a que SIMD no tiene una instrucción NOT. Hay que recordar que para
el uso de cualquier operador es importante escribirlo de la forma OPERADOR destino fuente.
Finalmente, hay que recordar que como cualquier otra
tecnología, es importante que SIMD pueda ser enseñada a estudiantes de ciencias
computacionales. Es por ello que utilizar técnicas como idioms puede resultar relevante para realizar otro tipo de
proyectos que requieran mayor complejidad, ya que de esta manera, los
estudiantes ya tienen un background de
ésta tecnología.
Espero esta entrada haya sido de su agrado :)
MapReduce... ¿Quién necesita un mapa?
¡Hola! :D
Una de las ventajas del MapReduce distribuido, es que si uno
de los trabajadores falla, el cálculo se puede volver a hacer bajo ciertas
condiciones. El cálculo se debe repetir debido a que solo el equipo que falló
tiene acceso a la información que era resultado de la(s) funciones que
realizaba, por lo que la información es inalcanzable. Ahora bien, si lo que se
estaba realizando era una función map, todo sucede como se describió
anteriormente; sin embargo, si se tiene un reduce, se debe revisar si el
trabajo ya fue revisado. Si se revisó, entonces se deberá repetir; de lo
contrario no hace falta repetir el trabajo. Finalmente cabe mencionar que si la
falla se ha presentado en el maestro, simplemente se puede avisar de un error y
el usuario puede hacer una nueva petición.
Finalmente, podemos hacer énfasis en que los usuarios de MapReduce pueden encontrarse con pocas problemáticas de sección crítica, ya que si el reduce definido por el usuario no está definido correctamente, existirá una condición de carrera o deadlocks.
Espero que esta entrada haya sido de su agrado :)
En esta ocasión hablaré acerca del artículo titulado "MapReduce: Simplified Data Processing on Large Clusters" escrito por Jeffrey Dean y Sanjay Ghemawat, y publicado en el Communications of the ACM en enero del 2008.
Como ya bien sabemos, la cantidad de información contenida
en bases de datos se ha incrementado exponencialmente, por lo que las bases de
datos relacionales han ido perdiendo efectividad al momento de realizar
búsquedas de información. Por eso mismo los modelos relacionales han pasado a
segundo plano, dejando lugar a conceptos nuevos como NoSQL y Big Data. Una de
las técnicas para buscar información en Big Data es, justamente, MapReduce.
Esta técnica consiste en dos operaciones: map y reduce. Map
consiste en tomar una entrada y devolver un conjunto con pares “intermedios” de
llaves-valores. A su vez, este conjunto
será pasado como parámetro a la función reduce (que además recibe una llave
adicional) para juntar la información realizada por el map. Tanto la función
map como la función reduce son definidas por el usuario. Estas dos funciones
pueden verse como aquellas que están definidas en lenguajes funcionales como
Lisp o Clojure.
La importancia del MapReduce llega cuando hablamos de
realizarlo de manera distribuida (es distribuido debido a que tenemos una red
de procesadores y no hay una memoria compartida para todos los equipos). De
esta manera, se tienen a los “trabajadores” de map realizando esta función,
almacenar los resultados temporales en un búfer y posteriormente los
“trabajadores” de reduce realizando esta función en un almacenamiento común
(por obvias razones, debe haber un maestro que se encargue de coordinar estas
operaciones y obtener el resultado final).
Finalmente, podemos hacer énfasis en que los usuarios de MapReduce pueden encontrarse con pocas problemáticas de sección crítica, ya que si el reduce definido por el usuario no está definido correctamente, existirá una condición de carrera o deadlocks.
Espero que esta entrada haya sido de su agrado :)
Provocando Segmentation Faults con Erlang... Así se aprende :)
¡Hola! :D
En estaentrada hablaré sobre el arículo titulado Teaching Concurrency-Oriented Programming with Erlang escrito por Ariel Ortiz y publicado en las memorias del 42° SIGCSE Technical Symposium on Computer Science Education en marzo del 2011.
En el artículo se habla acerca de problemáticas que se han discutido en entradas anteriores, como lo es la necesidad de comenzar a escribir programas paralelos en lugar de seguir con los programas secuenciales, ya que se necesita aprovechar al máximo todo el procesamiento disponible. Adicionalmente, se tratan conceptos previamente vistos, como definir qué es concurrente, paralelo y distribuido. Además, se recuerdan algunas de las reglas (antes vistas) que se deben seguir para realizar programas paralelos.
La parte importante del artículo viene cuando se habla de la
enseñanza de programación concurrente utilizando Erlang. Este lenguaje
funcional tiene muchas características que lo vuelven un lenguaje interesante
de aprender, que van desde tener su propio REPL, hasta la utilizar pattern matching para realizar el binding de las variables (cosa
completamente nueva para mí). En cuanto a performance,
hay que considerar a Erlang debido a que es útil para muchas tareas que,
personalmente, no me hubiera imaginado y que incluso pueden tener ciertas
aplicaciones para el área de especialidad que estoy tomando (redes).
Más adelante se comentan algunos principios de diseño de Erlang
para asegurar que los programas sean óptimos. Estos principios van desde usar un
número de procesos proporcional al número de procesadores disponibles (y
distribuir el trabajo de manera adecuada) hasta asegurarnos de minimizar el
tiempo que se espera por una respuesta. Hay que recordar que las operaciones de
entrada/salida suelen consumir muchos recursos.
Cabe señalar que Erlang no es un lenguaje perfecto, ya que
hay tareas para las que no tiene un desempeño tan bueno y que también sufre de
su versión de problemas de programación en paralelo (deadlocks, starvation,
etc.).
Ahora bien, en la parte de enseñanza de programación
paralela y concurrente, Erlang me parece un lenguaje interesante de aprender,
debido a su simplicidad (característica de lenguajes funcionales) y a cómo funciona
internamente. En lo personal, me parece que la enseñanza de programación
paralela y concurrente se puede volver aún mejor si se toman lenguajes como
Clojure y se comparan con Erlang en cuanto a su desempeño en general.
Espero que esta entrada haya sido de su agrado :)
Espero que esta entrada haya sido de su agrado :)
Indie Games FTW!
¡Hola! En esta ocasión escribiré sobre el documental titulado “Indie Game: The Movie” producido por BlinkWorks
Media y dirigido por Lisanne Pajot y James Swirsky en el año 2012. Tocaré algunos temas de la película y comentaré un poco sobre el camino que está tomando la industria de los videojuegos en la actualidad.
En la película se le da seguimiento al desarrollo de tres
videojuegos independientes: Super Meat Boy, FEZ y Braid. En el caso de Super
Meat Boy, se enfrentaban a terminar el juego en un tiempo relativamente corto
no solo porque querían ganar dinero, sino porque DEBÍAN ganar dinero, ya que
sus fondos se estaban agotando. El caso de FEZ no es muy distinto. Se debía
terminar el juego para estar en una convención de videojuegos (PAX) y tener ganancias
para terminar con el desarrollo del videojuego y de igual manera obtener
ganancias. Adicionalmente, FEZ enfrentaba problemas legales por la separación
de los desarrolladores del juego, lo cual implicaba que si FEZ se presentaba en
PAX, podría implicar una demanda. Por otro lado, Braid es un juego que rompió
paradigmas en el modo de juego de plataforma tradicional, ya que podríamos
considerarlo como un juego a prueba de errores, haciendo que además de ser un
juego de plataformas, también pudiese ser considerado un puzzle.
La industria del desarrollo (de videojuegos y en general) es
un poco hostil en el aspecto de que las personas involucradas tienen que
sacrificar muchas cosas: dinero, tiempo para ellos mismos, horas de sueño e
incluso el tipo de alimentación que llevan. Si bien la recompensa final en
muchos casos vale la pena, hay que tener en cuenta lo que representan todos
estos sacrificios. En este caso no hablamos simplemente de tener poca vida
social, sino de repercusiones a la salud por la falta de sueño o alimentación
hasta depresión por la falta de contacto con otras personas.
Esto es todo por ahora. Espero que haya sido de su agrado y les recomiendo jugar juegos independientes. Aunque a veces no lo parezca, pueden llegar a ser muy buenos a pesar de que algunos son cortos.
Welcome to the Jungle, We Got Fun 'n' Games
¡Hola! :)
En esta ocasión hablaré un poco sobre el arículo titulado "Welcome to the Jungle" escrito por Herb Sutter en diciembre del 2011.
En esta ocasión hablaré un poco sobre el arículo titulado "Welcome to the Jungle" escrito por Herb Sutter en diciembre del 2011.
El artículo habla acerca como en el
“final” de la Ley de Moore, comenzamos a hablar de entregar a los
usuarios equipos personales de cómputo paralelo. En tiempos
actuales, tenemos que hablar de 3 formas esenciales de procesamiento
en múltiples núcleos.
Primero vale la pena hablar acerca del
procesamiento con varios núcleos en sus primeras fases. El hecho de
que la velocidad de procesamiento de los procesadores no se haya
visto mejorada (como en años anteriores), obligó a las empresas a
implementar modelos con varios núcleos. Ya se ha hablado de este
aspecto en entradas anteriores.
Ahora bien, con el modelo de
procesamiento con varios preocesadores, tenemos que recordar la parte
de núcleos heterogeneos. Con este modelo, podemos hablar del
procesamiento dedicado en varios núcleos. El ejemplo más común es
la parte de CPU y GPU, donde el CPU se utiliza para tareas comunes
del sistema operativo y el GPU funge como procesamiento de gráficas,
permitiendo un mejor uso de los recursos disponibles. Ahora, hablar
de paralelismo en CPU y GPU permitiría llevar la optimización de
recursos hasta su máxima expresión.
Posteriormente, estamos obligados a
tocar el tema de núcleos elásticos para cómputo en nube. La parte
de paralelismo y concurrencia es un tema común (sino es que
indispensable) en cloud computing. Hay que recordar que una de
las técnicas más usadas en la nube es el map-reduce. Con
esta técnica, hablamos del crecimiento “scale-out” de los
centros de datos. Esto quiere decir que en lugar de concentrarse en
un solo dispositivo, el
centro de datos tiene varios equipos pequeños siendo usados de
manera distribuida. Así, el procesamiento lo hace cada equipo de
manera concurrente y una computadora finalmente hace la operación de
reduce. Este es uno de los modelos de procesamiento más importantes
de la actualidad, ya que funciona con grandes volúmenes de
información en tiempos razonables.
Eso es todo por ahora, espero haya sido de su agrado :)¿Paralelismo? ¿Quieres saber qué significa?
¡Hola! En esta ocasión, discutiré un poco sobre el artículo "Parallel Computing on any desktop", escrito por Ami Marowka, el cual fue publicado en el Communications of the ACM.
El artículo habla acerca de paralelismo aplicado a distintos
equipos de cómputo. Hace algunos años, hablar de paralelismo no era muy común.
Solamente los equipos con un buen nivel de procesamiento eran los “indicados”
para realizar este tipo de tareas. Actualmente, hablar de paralelismo es no
solamente común, sino que se ha vuelto una necesidad.
El tema de paralelismo en computadoras que pueden ser
adquiridas por personas “comunes” es algo que implícitamente nos hace ver a los
programadores que tenemos que explotar todo el procesamiento disponible que
existe. Es importante saber que cuando se habla de “explotar”, no se refiere a
solamente hacer que el procesador trabaje al máximo de su capacidad, sino que todo
lo que el procesador trabaje sea efectivo dentro del programa.
En el artículo se propone como una solución a OpenMP. Hay
que recordar a OpenMP como una herramienta poderosa que permite configurar
código y permitir la ejecución de ciertas tareas de manera paralela. Si bien
existen herramientas tan buenas como OpenMP, hay que recordar que solo es eso:
una herramienta. El programador es quien se tiene que hacer cargo de comprender
la naturaleza del problema y posteriormente escribir código que sea thread-safe. La parte de comprender el
problema es sumamente importante, ya que mientras más se conozca el problema,
menor es la probabilidad de sufrir de alguna falla referente a datos que son
accesados por varios threads.
Finalmente, hay que remarcar la parte de equipos de cómputo
en ámbitos empresariales. Es cierto que a un buen equipo empresarial podría
sacar provecho de herramientas como OpenMP. Sin embargo, cuando hablamos de
empresas que empiezan a crecer en grandes dimensiones, es necesario explorar
otras alternativas, como el cómputo distribuido. Esta solución puede ser vista
como “factible”, debido a que el sistema puede estar construido con distintos
equipos caseros y que, usando cómputo distribuido, puede ser capaz de procesar
grandes volúmenes de información en un periodo de tiempo aceptable.
Eso es todo por ahora, espero haya sido de su agrado :)
Free Lunch? NOT TODAY!
¡Hola!
En esta ocasión, escribiré acerca del artículo titulado: “The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software”, escrito por Herb Sutter para la revista Dr. Dobb's Journal de marzo del 2005. Durante esta entrada, tocaré algunos temas de interés como lo son ley de Moore, arquitecturas de varios núcleos/hyper-threading y la respuesta de los desarrolladores de software.
Durante muchos años, la ley de Moore se cumplió de manera casi religiosa, dejando la impresión equivocada de que así sería por mucho tiempo. Por desgracia, no se tuvo en consideración que, como cualquier teoría que se cumplía de manera exponencial, llegaría hasta un punto donde se estancaría. En tiempos recientes, hemos visto como la velocidad de los procesadores no va más allá de los 5 GHz (viéndonos sumamente generosos). Ahora, es importante tocar varios puntos al respecto.
En esta ocasión, escribiré acerca del artículo titulado: “The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software”, escrito por Herb Sutter para la revista Dr. Dobb's Journal de marzo del 2005. Durante esta entrada, tocaré algunos temas de interés como lo son ley de Moore, arquitecturas de varios núcleos/hyper-threading y la respuesta de los desarrolladores de software.
Durante muchos años, la ley de Moore se cumplió de manera casi religiosa, dejando la impresión equivocada de que así sería por mucho tiempo. Por desgracia, no se tuvo en consideración que, como cualquier teoría que se cumplía de manera exponencial, llegaría hasta un punto donde se estancaría. En tiempos recientes, hemos visto como la velocidad de los procesadores no va más allá de los 5 GHz (viéndonos sumamente generosos). Ahora, es importante tocar varios puntos al respecto.
Primero que nada, hay que
discutir las expectativas que se tenían para tiempos actuales. Al
paso que la velocidad del procesador iba evolucionando, era
completamente comprensible que para estos años se esperaran
velocidades de entre 10 y 20 GHz. Por desgracia, esto no se cumplió
por distintas razones (como el exceso de calor y la dificultad para
disiparlo, por ejemplo). Hay que recordar que aunque la ley de Moore
no se cumplió para los ciclos de reloj, seguía siendo válida para
el número de transistores en un procesador.
Ahora, si sabemos que las
expectativas no se cumplieron, debemos preguntarnos ¿cuál fue la
solución alternativa? Es aquí donde entran los modelos de
procesadores com varios núcleos y técnicas como el hyper-threading.
Si bien son técnicas aceptables, hay que tener en cuenta que no es
lo mismo tener un procesador de x Hz a tener n procesadores con x/n Hz (el
modelo con varios procesadores tendrá un peor desempeño por razones explicadas más adelante).
La
parte importante viene ahora. ¿Qué se ha hecho en el ámbito de
programación para adapatarse a este cambio? Aunque no sea apreciable
a simple vista, el cambio de un solo procesador a estos modelos
representa cambios importantes para el desarollo de software. En
principio, los programadores desarrollaban software con el
pensamiento de que en un futuro cercano existiría un procesador que
fuera capaz de correr adecuadamente la aplicación desarrollada. Al
cambiar a un paradigma de varios núcleos, es importante tener en
cuenta que éstos podrían no aprovecharse al máximo. Es por ello
que se debe pensar en posibilidades de
hacer los programas de manera paralela. De esta manera, podemos
evaluar si paralelizar es una buena solución o es preferible dejar
la solución serial.
Esto es todo por ahora, espero esta entrada sea de su agrado. Si es de su interés, pueden encontrar el artículo aquí.
Esto es todo por ahora, espero esta entrada sea de su agrado. Si es de su interés, pueden encontrar el artículo aquí.
¡Que se presente el colado! :P
¡Hola a todos! :D
Esta es mi primera entrada en el blog de Programación Multinúcleo, y ahora que oficialmente ya no soy el colado de la clase, comenzaré dando una breve presentación sobre mi.
* Mi nombre (casi) completo es Edwin A. González (sí, tengo un segundo nombre).
* Al momento de esta entrada tengo 19 años de edad
* Me gusta jugar videojuegos, jugar ultimate frisbee y bailar hip hop
* Algunos de los libros que me gustan son 1984 - Orwell, El Código Da Vinci - Brown, Harry Potter Saga - Rowling, El Extraño Caso del Dr Jekyll y Mr Hyde - Stevenson.
* Casi no veo programas de TV. Las pocas series que veo y me gustan son Criminal Minds, NCIS, The Big Bang Theory, New Girl, The Simpsons.
* Algunas de mis películas favoritas son Despicable Me, Kill Bill (both), Pulp Fiction, V for Vendetta, The Avengers, Rise of the Guardians, Frozen, Wreck It Ralph, Hotel Transylvania, Scary Movies, Iron Man, Sherlock Holmes, Tangled, etcétera.
Del curso de programación multinúcleo, espero aprender acerca de como aprovechar el poder de procesamiento lo mejor posible, obteniendo tiempos de respuesa razonables para problemas que regularmente tomarían una cantidad mayor de tiempo.
Eso es todo por ahora. Espero les haya gustado esta entrada. Si quieren leer un poco más sobre mí, está disponible la sección Sobre el Autor.
Esta es mi primera entrada en el blog de Programación Multinúcleo, y ahora que oficialmente ya no soy el colado de la clase, comenzaré dando una breve presentación sobre mi.
* Mi nombre (casi) completo es Edwin A. González (sí, tengo un segundo nombre).
* Al momento de esta entrada tengo 19 años de edad
* Me gusta jugar videojuegos, jugar ultimate frisbee y bailar hip hop
* Algunos de los libros que me gustan son 1984 - Orwell, El Código Da Vinci - Brown, Harry Potter Saga - Rowling, El Extraño Caso del Dr Jekyll y Mr Hyde - Stevenson.
* Casi no veo programas de TV. Las pocas series que veo y me gustan son Criminal Minds, NCIS, The Big Bang Theory, New Girl, The Simpsons.
* Algunas de mis películas favoritas son Despicable Me, Kill Bill (both), Pulp Fiction, V for Vendetta, The Avengers, Rise of the Guardians, Frozen, Wreck It Ralph, Hotel Transylvania, Scary Movies, Iron Man, Sherlock Holmes, Tangled, etcétera.
Del curso de programación multinúcleo, espero aprender acerca de como aprovechar el poder de procesamiento lo mejor posible, obteniendo tiempos de respuesa razonables para problemas que regularmente tomarían una cantidad mayor de tiempo.
Eso es todo por ahora. Espero les haya gustado esta entrada. Si quieren leer un poco más sobre mí, está disponible la sección Sobre el Autor.
