Beers & Talk (I) – Toni Cebrián

Hace un par de días tuve la oportunidad de charlar un rato – birras mediante – con Toni Cebrián (@tonicebrian), que aparte de ser un auténtico crack de Telefónica I+D trabajando ahora mismo con temas de Machine Learning y Sistemas de Recomendación en Tuenti, es mi compañero de equipo de fútbol sala. A continuación dejo algunos temas de los que estuvimos hablando que seguro que a muchos les resultarán interesantes.

(Toni tiene un blog que es la caña: http://www.tonicebrian.com/ y – cómo no – cuenta en GitHub: https://github.com/tonicebrian)

Nombre y Rango, soldado.

Soy Toni Cebrián, y soy especialista en Telefónica I+D

¿Qué estudiaste?

Estudié Ingeniería Técnica Telecomunicaciones, especialidad de Sistemas Electrónicos, porque me quería dedicar a Energías Renovables. Lo que pasa es que al final se me cruzó en medio un profesor que me hizo hacer un proyecto relacionado con Redes Neuronales y SVM, y me gustó tanto el tema que terminé re-enfocando mi carrera, olvidándome de transistores, circuitos y demás para dedicarme a la Informática, el Data Mining y similares.

¿Qué es SVM?

Son las siglas de Support Vector Machine, y es una técnica para hacer clasificación o regresión. En el año 99, que es cuando hice mi PFC, era algo muy novedoso, y este profesor me propuso hacer una comparativa entre redes neuronales y SVM para un problema de Farmacia que tenían, relacionado con la intoxicación por dixogina en tratamientos médicos. La dixogina es nociva a partir de cierta dosis, que no tiene un valor fijo sino que depende de varios factores como la edad, sexo o la constitución física. La idea era utilizar una serie de métodos estadísticos para intentar inferir en función de tus características físicas si ibas a estar intoxicado por una dosis determinada. Hice la comparativa y la verdad es que salió bastante bien. De hecho gané un premio con 500 mil pelas de entonces, que era una pasta para un estudiante y para ser el año que corría.

¿Cuál ha sido tu carrera profesional?

Tras un breve trabajo al salir de la carrera, en el año 2000 entré en Telefónica I+D, pasando 2 años en Madrid. Los primeros 5 años fueron haciendo proyectos de TELCO clásicos: C++, Oracle, sistema de gestión de enrutadores, enlaces… básicamente CRUD para este tipo de cosas. Cuando volví a Barcelona ya me moví a más temas de análisis de datos y similares: data warehouse, business intelligence, etc. Mi primer proyecto fue analizar el Fotolog de Argentina, porque no se sabía si la gente volvía, cuántas visitas tenían, qué hacían… la idea era tener un dashboard de lo que pasaba. Luego pasé a cosas más relacionadas con Data Mining, Machine Learning, y fue cuando empecé a especializarme en Sistemas de Recomendación durante unos 3 o 4 años. En cierto momento, por una serie de razones se consideró que era una tecnología suficientemente madura como para ser comprada a algún vendor en el mercado, por lo que se paró esa línea de trabajo, y me empecé a dedicar a hacer cosas relacionadas con análisis de datos, en proyectos más pequeños.

Actualmente haces la rotación en Tuenti. ¿A qué te has dedicado?

Comencé con un proyecto de recomendación de vídeos, y ahora me dedico a otro proyecto relacionado con mejorar la búsqueda de usuarios, partiendo del sistema que hay actualmente, basado en recuperación de la información textual – con Sphinx – a uno que intenta utilizar además de esa búsqueda textual una ordenación basada en la proximidad en la red social, de tal forma que, por ejemplo, al buscar “María”, en lugar de que aparezca cualquier María de la red, aparezcan la más cercanas a ti. Está actualmente en fase de evaluación/evolución, pero al haber un ciclo de desarrollo, despliegue y prueba, estoy a la vez haciendo otra tarea de data mining clásico, intentando descubrir los motivos por los que un usuario cuando entra en la red social, se mantiene activo – porque sube muchas fotos, crea mucho contenido, o habla con muchos amigos, por ejemplo.

¿Intentar establecer por qué un usuario es activo o no?

En efecto

¿A qué llevaría eso?

Si identificas que un usuario es activo porque por ejemplo sube muchas fotos, puedes intentar enfocarte en incentivar esa serie de comportamientos identificados como relevantes para el engagement de usuarios.

Hace poco nos diste una charla sobre proximidad en la red social. Cuéntanos un poco de qué trata.

Si utilizas una aproximación simple, como puede ser en cuántos saltos llegas de un usuario a otro y que podría ser una medida de proximidad válida, te das cuenta enseguida que una red social como Tuenti es muy compacta. De media, lo que se conoce como el diámetro de la red, está en 3 o 4 saltos – es decir, casi todos estamos a 3 o 4 amigos de distancia unos de otros. Eso no da una medida muy fiable para establecer la proximidad. ¿De qué se trata entonces? Se trata de intentar pensar en algo parecido a una “difusión de la influencia” de un usuario basándonos en otros criterios. Por ejemplo, un usuario con muchos contactos le daría poca importancia a todos ellos. Sin embargo, se podría asumir que un usuario con pocos contactos le da mucha importancia a los que están más próximos a él. Dicho de otra forma, si tienes mil amigos, todos ellos no son relevantes para discernir si son próximos a ti o no. En cambio, si solo tienes 5, se puede asumir que esos 5 son muchos más relevantes, a pesar de que en ambos casos la distancia es de tan solo un salto.

¿Cómo distingues la relevancia de la simple inactividad?

Actuamente no se toma en cuenta, pero podría hacerse. Por ahora se utilizan únicamente enlaces duros (en este caso amistad), pero se podrían construir enlaces inferidos, de tal forma que solo se conectan dos usuarios si cumplen una serie de requisitos, como por ejemplo un numero determinado de fotos en los que aparecen ambos etiquetados, o una serie de mensajes enviados en común.

¿Cuál es el mayor problema a la hora de implementarlo en Tuenti?

El mayor problema es no poder realizar una implementación directa, por el tamaño de la base de usuarios. Si por ejemplo se está definiendo una función de medida, que necesita a un usuario A y a un usuario B, y tienes millones de usuarios, terminas manejando una matriz de dimensiones enormes. Aún cuando puedas almacenanarla toda (con mucha capacidad de cómputo) te encontrarías con que no puedes acceder a toda esa información a la vez, porque no es factible. La otra opción es llevarlo a cabo a partir de aproximaciones matemáticas, que es lo que estamos haciendo ahora.

¿Y qué tal han ido?

Ahora mismo estamos haciendo esa aproximación usando el algoritmo Minhash y por lo pronto parece que va bien (aunque aún estamos en proceso de evaluación) Sin embargo, cabe destacar que todo esto es un proceso continuo, al cuál podrías dedicarle horas y horas de investigación. En algún momento, alguien te dirá que ya no te dediques a ello, pues el beneficio que podrías obtener de una mejor aproximación (por ejemplo de un 2%) no compensa un trabajo de 3 meses para conseguirlo. Es necesario llevar siempre un proceso algo ágil o lean, que te permita refinar los objetivos o el rumbo conforme se avanza.

¿Te consta que se esté haciendo algo similar en otro sitio?

Sí. Cuando estuvimos la etapa de research, vimos que se utiliza en muchos sitios: reconocimiento de imágenes, por ejemplo. Hay un paper de Google que lo utiliza para recomendar noticias, por lo que sí, se utiliza en otros sitios.

¿Está en voga?

Yo no diría que está en boga por ser algo muy específico de un nicho; no todos los sitios tienen un problema de estas dimensiones, ni tienen tantos usuarios o no tienen que encontrar similitudes entre usuarios.

Hace poco estuviste en unas conferencias en Japón.

Estuve en el Machine Learning Summer School. Las Summer School son unos eventos que ocurren dos o tres veces al año – aunque no sea verano – al que va gente sobre todo de Universidades a dar un curso enfocado en lo que están trabajando. El formato consiste en dar un curso de unas 3 o 4 horas muy específico en sus avances. Yo por ejemplo estuve 2 semanas y pude atender a cursos de unas 15 áreas de investigación diferentes, y hablar con ellos sobre lo que hacen. La idea no es ir allí esperando volver con algo que puedas aplicar directamente a tu trabajo diario, pero sí para tener una visión general de lo que está ocurriendo y los campos en los que se está avanzando. Si tienes suerte a lo mejor resulta que un método general puedes sacarle provecho en tu área de trabajo.

Hay entonces mucha variedad en los proyectos.

Si, porque no es un curso donde te dan una visión estructurada de la materia – es decir, no es un único curso de Machine Learning perfectamente articulado – sino una serie de tapas de muchas técnicas diferentes. Eso sí, cada una de ellas muy bien explicadas, presentadas normalmente por la persona que está tirando del carro en ese área en particular.

Me comentaste que te sorprendió ser el único asistente que no venía del mundo académico.

Sí. También me llamó la atención la motivación de los asistentes. Cuando haces un doctorado, en cierta forma te estás enfocando en una temática muy concreta, y en una área de especialización, pues el objetivo de tu doctorado es conseguir avanzar el “estado del arte” de la misma. Por esta razón entendía que para un doctorando lo mejor era ir a las conferencias especificas de su área de trabajo, pero luego al charlar con los asistentes me comentaron que su idea era ir allí para tener una visión general, y para ver si lo que de que se está hablando pueden reformular, aplicar, en su día a día. Por otra parte opino que si estás trabajando en algo relacionado con el tema, creo que puede serte de mucha utilidad asistir.

¿Cuáles son los mayores retos a los que se enfrenta el Machine Learning en general?

Es un campo muy grande. En general, la idea es tratar de replicar todas esas acciones en las que los humanos somos buenos y destacamos sobre las máquinas: lenguaje, visión, conceptualización (hay mucha investigación relacionada con hacer resúmenes de texto). Y también, en la también teórica del Machine Learning: qué cosas se pueden aprender y qué no, sabiendo de entrada la viabilidad al abordar un problema. Es un área de investigación interesante.

¿Y en sistemas de recomendación?

Algo que está muy en boga es el tema de la contextalización: tener en cuenta con quién estás, qué hora del día es, etc. Normalmente los sistemas de recomendación se han basado en el triplete . Sin embargo, esa valoración podría ser dependiente de otras dimensiones basadas en el contexto – localización, estado de ánimo, etc. Poder inclusir esa contextualización a la hora de recomendar podría ser muy interesante. También se solía trabajar en dominios digitales – música, películas – y muy atómicos – una película es lo que es, una canción es lo que es. Ahora hay sistemas de recomendación muy interesantes por ejemplo de ropa (que no es mala o buena por si sola, sino combinadas con otras cosas)

Otra area de trabajo podría ser la de recomendadores especializados en auto aprendizajes. Por ejemplo: quiero un sistema que me enseñe a apreciar la opera. Podría recomendarme aprender armonía, un poco cultura, historia, tipos distintos… O por ejemplo, quiero aprender sobre sistemas de recomendación: que te sugiera aprender álgebra, estadísticas, cálculo… un sistema que en lugar de recomendarte una cosa, te recomiendo un camino. Es otra área que particularmente encuentro muy interesante.

¿Hay alguna relación entre Big Data y Machine Learning?

Realmente no la hay directamente; son campos ortogonales, que no tienen por qué ir juntos – puedes utilizar Big Data sin Machine Learning, y al contrario también, con un sistema de Machine Learning con datos que te caben en memoria. Sin embargo, y creo que cito a Peter Norvig, más datos vencen a mejores modelos: si eres capz de reunir muchos datos – y cuando hablo de muchos estoy hablando de Big Data – consigues mejores resultados con peores modelos. Por tanto esa es la relación, si tiene Big Data, peores modelos de Machine Learing producen mejores resultados.

Me interesa el tema, ¿por donde comienzo?

Lo típico es hacer un master, una carrara relacionada con el tema. Pero por otra parte, los cursos de Coursera o similares están muy bien para comenzar (si estas trabajando por ejemplo). Al final hacer cosas de data análisis es como hacer cosas de matemáticas, estadística y software engineer a la vez. Necesitas tener un background en esas tres áreas, construyéndolo poco a poco – curso de estadística, tener las matematicas frescas, y por supuesto ser buen programador, porque si al final no eres capaz de llevarlo a la practica no sirve de nada.

También son muy interesantes las competiciones de data análisis (tipo TopCoder para programadores) Ahora mismo Kaggle.com es la web de referencia.

¿En qué consisten la competiciones?

Te dan un data set y te dicen qué tiene que conseguir tu modelo. Lo entrenas, y tras el periodo participación, se comprueban con un data set de ellos (distinto al de entrenamiento). El que tiene mejor predicción gana, y suele haber premios monetarios. Esas competiciones están muy bien, al consistir en un problema muy acotado, con datos que suelen estar limpios (cuando estás en la industria hay un trabajo enorme de limpieza, completado, adaptación). Si además has estado participando ello, puedes ver qué tal lo has hecho y compararte con los vencedores. Es un ciclo de hago, aprendo, hago, aprendo, que considero una buena opción para ponerse en marcha.

¿Cuánto informático y cuánto de matemático – u otra cosa – necesitas tener para desempeñarte en Machine Learning o Sistemas de Recomendación?

Si tienes problemas lo suficientemente pequeños para que te quepan en memoria, probablemente primer el ser matemático/estadista. Desde el momento en que no sea así, prima más la parte de programación, relacionado a lo que comentaba de mejores datos vencen mejores modelos: puedes tener unas nociones de estadísticas y aplicar un modelo sencillo, porque lo que importa es que sepas aplicarlo en sistemas grandes, modelos distribuidos, usar Hadoop, etc. Sin embargo, no es una cosa o la otra. En mi caso, y a pesar de usar aproximaciones matemáticas, los cálculos de los valores intermedios tuve que hacerlo distribuidos, usando Scala, actores.. Si lo usara en una sola maquina me hubiera llevado mucho tiempo; no puedes usar Matlab, porque la red de Tuenti no cabe… llega un momento en que hay que conocer que estás haciendo – más allá del plano teórico – y cómo funciona la arquitectura, por lo que la faceta de ingeniería de juega un papel muy importante.

¿Qué lenguajes de programación te gustan?

Los funcionales. Haskell es el que más me gusta, pero es una bestia parda. Scala también, que se queda a mitad, porque permite utilizar librerías de JAva, y también programación funcional, pero me sigue gustando más Haskell.

¿Libros, Blog, Artículos?

Esta entrada de Quora está cargada de material: How do I become a Data Scientist.
Bradford Cross, el creador de Prismatic, hizo un par de entradas en su blog acerca de lo que había que aprender para ser un Data Scientist. Esas entradas eran oro puro, pero no se por qué cerró su blog. Algunos han tratado de recuperar esa información aquí https://sites.google.com/site/mldmda/guide-1

¿Pasaremos a segunda ronda en el equipo de fútbol sala?

Tengo un modelo entrenado con los datos hasta ahora y dice que sí (risas).

Algunas palabras de despedida

Creo que todo esto es un área súper candente. Es como si hace 15 años sabías Java, que eras considerado el Rey del Mambo. Creo que es la misma situación en estos momentos para este tema.

Muchas gracias, caballero.

Igualmente.

Workshop de TDD

Hace un par de semanas tuve la oportunidad de dar en la empresa donde trabajo un taller de TDD a algunos compañeros interesados en el tema. La idea era explicar un poco en qué consiste y por qué es un cambio (para mejor, IMHO) en la forma de desarrollar software.

Normalmente todos estamos de acuerdos de la importancia de desarrollar una batería de pruebas automatizadas que cubra el software que implementamos; lo que no suele verse con tanta claridad son las ventajas de escribir dichas pruebas antes que escribir el código como tal. En la presentación intenté explicar las ventajas más inmediatas del TDD – como son una buena cobertura del código o la legilibidad que se obtiene mediante la continua refactorizacion – como otras ventajas que no suelen ser tan sencillas de ver a priori, pero que considero igual de fundamentales y que se notan una vez se empieza a desarrollar siguiendo esta metodología, como la consecución de un diseño emergente (evitando el over-engineering)

El taller lo dividimos en tres partes: una primera parte teórica, un Coding Dojo con un ejemplo en el monitor, para que la gente se hiciera una idea de la dinámica del ciclo de TDD (Red-Green-Yellow) y una kata de código en parejas para que todos pudieran poner en práctica lo que habíamos discutido.

Presentación teórica:

Al final del todo tuvimos una retrospectiva del taller como tal, de donde salieron algunas ideas interesantes para siguientes ejercicios:

  • Incluir algunos snippets de código real que pudieran analizarse y proponer cómo mejorarse.
  • Incluir un escenario de test client-server.
  • Tener mejor definidos los criterios de aceptación de los ejercicios.
  • Intentar incluir “trampas” que hagan a la gente pensar sobre el problema.
  • Plantear otro taller sobre principios de diseño SOLID.

En general creo que la experiencia fue bastante positiva y todos los asistentes salieron bastante satisfechos (tanto los que ya contaban con experiencia previa como los que estaban introduciéndose en la materia)

Si te interesa el tema del TDD y vives en Barcelona, RunRoom suele organizar todos los meses un Coding Dojo en sus oficinas a los que vale la pena asistir, sin importar mucho el nivel de conocimiento que tengas. Además, suele haber patrocinio de Gin Tonics por parte de Úbeda Gin&Tapas que ya hace que valga la pena darse un salto :-)

Agradecer a @_dcampoy, @jmbarroso, @freyes y @carlosble por su feedback respecto al taller y sus ánimos para impartirlo.

Libro: NoSQL Distilled

Hace poco he terminado de leer el libro NoSql Distilled [M. Fowler & P. Sadalange]. Es una introducción bastante concisa (unas 150 páginas) sobre NoSQL: Qué es, qué viene a cubrir en contraposición a las bases de datos relacionales de toda la vida, por qué surgieron, cuáles son los tipos de bases de datos NoSQL más famosos y algunos consejos sobre cuándo utilizar unos u otros.

No entra en mucho detalle en ninguno de los apartados que menciona, pero lo que cubren basta para aportar una idea general sobre NoSQL, qué hay bajo el paraguas de esta (por otra parte bastante laxa) definición, y las opciones que se tienen a la hora de elegir cuál es la mejor opción en la capa de persistencia de nuestra aplicación.

Los primeros capítulos explican el motivo por el que el término NoSQL está en alza, así como los modelos de datos que se usan en este tipo de bases de datos (Aggregate Data Model). También explica cómo conseguir modelos distribuidos, bien a través del particionado (sharding) o la replicación, siendo ambas técnicas no excluyentes entre sí.

En el capítulo de Consistencia, se explican los distintos conflictos que se pueden obtener, así como el teorema del CAP (Consistency – Availability – Partition tolerance) y por qué (en principio) no se pueden conseguir las tres propiedades en un sistema distribuido. Otro apartado que podría tratarse como Consistencia es el de los Version Stamps, que ayudan a detectar conflictos de concurrencia entre versiones del mismo dato. La técnica de Map-Reduce (en la que se basa p.e. Hadoop) también es explicada más o menos en detalle.

Hay un capítulo para cada uno de los tipos “principales” de bases de datos NoSQL: los de almacenamiento Key-Value (p.e. Redis), Documents (p.e. MongoDB), Graph Databases (p.e. Neo4j) o Column-Oriented (p.e. Cassandra), así como sus puntos fuertes/débiles, y bajo qué dominios de aplicación se deberían usar unos u otros.

Los últimos capítulos versan sobre la persitencia políglota (Polyglot Persistence) o como usar la tecnología que mejor se adapte al dominio del problema, sin necesidad de utilizar siempre el mismo sistema (p.e. información de sesiones en key-value, datos de negocio en una base de datos relacional y el sistema de recomendaciones en una base de datos de grafos)

Por último, comenta que los dos principales motivos para utilizar NoSQL son para mejorar la productividad de los desarrolladores a través del uso de bases de datos que se adaptan mejor al dominio de la aplicación, o para mejorar el rendimiento de acceso a los datos. Sin embargo, aconsejan llevar a cabo una etapa de pruebas antes de decidirse finalmente por una solución NoSQL.

En la web de M. Fowler se puede encontrar una sección completa con la documentación que recabaron para escribir el libro: NoSQL. En particular, se pueden encontrar los puntos claves de muchos de los capítulos del libro, que sirven como un buen resumen general del mismo: Key Points from NoSQL Distilled

Personalmente el libro me ha gustado. Es fácil de leer, y aporta una visión general del ecosistema de bases de datos NoSQL, las características de cada uno de ellos, así como los motivos por los cuáles se podría elegir alguna solución u otra (o combinar varias). Sirve también como punto de partida para abordar libros más específicos sobre cada una de las tecnologías que relata.

Por qué Google necesita ganar en el tema social

Google está tratando desesperadamente de dar un paso adelante en el tema “social”. De hecho, el nuevo CEO Larry Page ha condicionado el bono de los empleados de la compañía al éxito de la estrategia social de Google.

Por una parte tiene sentido: Facebook es un negocio enorme, cada vez más importante y que crece a un ritmo vertiginoso, por lo que Google no debería quedarse atrás en el tema social.

Pero por otro lado, también es un poco desconcertante ¿Por qué a Google debería importarle tanto las redes sociales? Está claro que son interesantes, pero ¿por qué debería ser tan vital para una compañía de búsquedas entrar en el tema social? Actualmente no se puede decir que está perdiendo dinero. De todas formas, ¿no es “social” una palabra de moda bastante vaga?

Hay más razones: Facebook está inventando nuevas formas de publicidad y parece que se va a hacer con una gran parte del display advertising, el cuál Google necesita para crecer más allá de su ya bastante maduro negocio de búsquedas; Facebook tiene mucha información valiosa sobre los intereses y preferencias de sus usuarios, y Google quiere obtener una cantidad de información similar. Facebook también compite muy exitosamente contra Google por los mejores cerebros y talentos del sector, y Google necesita ser vista como la compañía más puntera para atraer a los mejores ingenieros. Todo eso es correcto.

Pero nada de eso explica por qué Google está tratando a Facebook como una amenaza mortal que cada vez parece serlo más.

El mayor motivo es obvio aunque nadie suele comentarlo: en internet, el tráfico es dinero y poder, y la compañía que controla el tráfico obtiene el dinero y el poder.

Es por eso que el tema “social” es más que una palabra de moda (si bien es cierto que lo es), y por qué es realmente enormemente importante. Las redes sociales se están llevando un porcentaje cada vez mayor del tráfico en Internet, que al final se traduce en dinero y poder.

En un sentido estricto, la gente siempre buscará cosas en internet, y entre esas cosas siempre habrá cosas que se pueden comprar y a las que las compañías querrán darle publicidad, por lo que siempre habrá muchísimo dinero para la empresa con el motor de búsquedas más importante.

Pero también hay dinero para construir mainframes y vender servicios de consultoría, y sin embargo nadie ve a IBM como la compañía tecnológica más poderosa del mundo, aún cuando lo fue durante muchas décadas y aún sigue siendo una compañía enorme.

Pensémoslo desde la perspectiva del propietario de un sitio web, que bien podría ser un blog o Amazon. Durante la mayor parte de la década pasada, la mayor fuente de tráfico fue, de lejos, los buscadores. Por lo que el tema que más te preocupaba si querías tener éxito en tu web eran las búsquedas, bien mediante SEO o mediante Márketing en las ellas. Toda el entorno de la web giraba alrededor de las búsquedas. Compañías enteras fueron concebidas y construidas alrededor de este hecho.

Sin embargo, en la actualidad empresas grandes y pequeñas están diversificándose y alejándose de su dependencia de Google.

Las redes sociales conforman entre un 30% y un 50% del origen de las visitas a los principales media sites. Las fuentes de tráfico que más crece a sitios comerciales, que es donde está el dinero, son las redes sociales, y si hay algo que la historia de internet nos ha enseñado es que si algo es pequeño pero crece muy rápido, probablemente con el paso del tiempo se convertirá en enorme. La mayoría de las startups de hoy en día – reconociendo que tienen recursos limitados y que el SEO ha convertido a Google en víctima de su propio éxito, al tener un exceso de resultados de búsqueda – están basando su estrategia de distribución en Facebook y en Twitter, no en Google.

Cuando la gente habla sobre la amenaza que representan las redes sociales a Google, suelen referirse al modo en que las personas están buscando información, preguntando primero a sus amigos antes de ir a Google. Sin embargo, la gente seguirá usando casi siempre los ordenadores para buscar información, puesto que el resultado suele ser eficiente.

Por tanto, la amenaza de las redes sociales a Google no es que lo social pueda reemplazar a la búsqueda como tal, sino que parece inevitable que lo social se convierta en una fuente de tráfico igual o mayor a las búsquedas, y por tanto en mayor poder y dinero que éstas últimas.

Visto así, puede o no suponer una amenaza mortal al core del negocio de las búsquedas de Google. Lo que sí es seguro, es que plantea una amenaza mortal a la forma que tiene Google de verse a si misma, no sólo como la compañía en internet más rentable y poderosa, sino como el centro mismo de internet, alrededor de la cuál giran las demás.

Eso es lo que tiene aterrado a Larry Page. Y tiene razón para estarlo.

(Traducción bastante libre del artículo The Obvious Reason Why Google NEEDS To Win Social That Nobody Talks About)

Primeros pasos con Threading Building Blocks

Hace poco, como tema de una presentación en la Facultad, @jmbarroso y yo estuvimos “jugando” con una librería de paralelización de Intel de la que no tenía ni idea de su existencia y que me dejó francamente sorprendido. Se llama Threading Building Blocks (TBB), lleva algunos años en el mercado y en este post explicaré someramente qué es, para qué sirve, y qué viene a mejorar en el mundo de la paralelización.

TBB – Qué es

TBB es una librería escrita en C++, para programas hechos en este lenguaje (por ahora), que facilita la paralelización de los mismos en procesadores multicore gracias a las funciones y estructuras que provee. Su objetivo es lograr un paralelismo escalable, haciendo uso de C++ estándar, que además abstraiga al programador de los detalles de la plataforma y del manejo de hilos, que exprese el paralelismo de una manera más simple y que realice un mejor aprovechamiento de los recursos de los procesadores.

TBB – Ventajas

TBB permite expresar el paralelismo como Tareas en lugar de Hilos. De esta forma, no es necesaria llevar a cabo manualmente la gestión de los mismos: no más create, join, manage, etc. Dichas tareas son asignadas automáticamente a hilos, haciendo un uso eficiente de los recursos del procesador.

Una característica curiosa es el uso de una técnica denominada task stealing; la librería se encarga de asignar/desasignar tareas entre procesadores de manera transparente al programador, según la carga de trabajo actual, para equilibrar el trabajo de todos. Toda esta “abstracción” permite desarrollar soluciones más simples de alto nivel.

Además, es compatible con otros paquetes de paralelización, por lo que se puede optar por usar algunos componentes de TBB bajo ciertas circunstancias, y usar diferentes soluciones (OpenMP, gestión de hilos manualmente) en otras.

TBB – Contenido

La librería provee soluciones de distinta índole para facilitar la paralelización de las aplicaciones, que se pueden dividir en:

Algoritmos básicos:
• parallel_for
• parallel_reduce
• parallel_scan

Algoritmos avanzados:
• parallel_while
• parallel_do
• pipeline
• parallel_sort

Contenedores:
• concurrent_queue
• concurrent_vector
• concurrent_hash_map

Reserva de memoria escalable:
• scalable_malloc
• scalable_free
• scalable_realloc
• scalable_calloc

Exclusión mutua:
• mutex
• spin_mutex
• queuing_mutex
• spin_rw_mutex
• queuing_rw_mutex
• recursive mutex

Operaciones atómicas
• fetch_and_add
• fetch_and_increment
• fetch_and_decrement
• compare_and_swap
• fetch_and_store

Timing:
• Método thread_save portable para procesar el tiempo transcurrido.

Planificador de tareas
• Acceso directo para controlar la creación y la ejecución de tareas

Instalando TBB.

La última versión estable de la librería para Windows, Linux y Mac se puede encontrar aquí.

La instalación resulta bastante sencilla. En mi caso con la versión para Mac OS, que no diferirá mucho de la disponible para Linux:

Se descomprime el tgz descargado. Yo lo hice en un directorio de mi home donde instalo los frameworks y librerías que utilizo (grails, maven, gradle, mercurial, etc) pero /opt/ podría ser otra ubicación adecuada. También he creado un enlace simbólico “tbb” que apunte a la última versión, para usarlo al referirme a la librería, en vistas a simplemente actualizar el enlace en caso de que siga descargando en el futuro versiones de la librería y quiera cambiar fácilmente entre ellas:

juanjo:bin juanjo$ pwd
/Users/juanjo/bin
juanjo:bin juanjo$ ls -ltr
drwxr-xr-x   4 juanjo  juanjo       136 24 ene 17:21 tbb30_20101215oss
juanjo:bin juanjo$ ln -s tbb30_20101215oss/ tbb
juanjo:bin juanjo$ ls -ltr
drwxr-xr-x   4 juanjo  juanjo       136 24 ene 17:21 tbb30_20101215oss
lrwxr-xr-x   1 juanjo  juanjo        22 24 ene 17:28 tbb -> tbb30_20101215oss/

Es necesario modificar el archivo bin/tbbvars.sh para asignar a la variable TBB30_INSTALL_DIR la ruta al directorio raíz de la librería:

juanjo:tbb juanjo$ pwd
juanjo:bin juanjo$/Users/juanjo/bin/tbb
juanjo:bin juanjo$ cat -n bin/tbbvars.sh
 
# Threading Building Blocks Home
    30    TBB30_INSTALL_DIR=/Users/juanjo/bin/tbb

Cargamos las variables definidas en el fichero, que se deberá hacer cada vez que se abra una terminal y se desee trabajar con la librería. La alternativa es añadir la línea al fichero ~/.bash_profile para hacerlo automáticamente al cargar sesión:

juanjo:bin juanjo$ source bin/tbbvars.sh

Para probar si todo está configurado correctamente, intentamos compilar y ejecutar uno de los ejemplos incluídos en la distribución:

juanjo:tbb juanjo$ cd examples/GettingStarted/sub_string_finder/
juanjo:sub_string_finder juanjo$ make
g++ -O2 -DNDEBUG  -o sub_string_finder sub_string_finder.cpp -ltbb
g++ -O2 -DNDEBUG  -o sub_string_finder_extended sub_string_finder_extended.cpp -ltbb
g++ -O2 -DNDEBUG  -o sub_string_finder_pretty sub_string_finder_pretty.cpp -ltbb
./sub_string_finder_extended
Done building string.
Done with serial version.
Done with parallel version.
Done validating results.
Serial version ran in 8.01188 seconds
Parallel version ran in 4.1834 seconds
Resulting in a speedup of 1.91516

En efecto, todo funciona, y ya estamos en disposición de empezar a utilizar los componentes que nos provee TBB. De hecho, en el ejemplo que lanzamos se observa una de las bondades: un speedup del 91% que no está nada mal.

En el próximo artículo veremos cómo hacer uso de los componentes incluídos en la librerías, paralelizando un código secuencial y desgranando el código fuente del mismo.

Más información:

• Página Oficial de Threading Building Blocks.