Science Cloud 2010 paper

Hace ya un mes que comenzó el nuevo curso en la Universidad de Virginia, así que a la vuelta de vacaciones nos hemos encontrado con Charlottesville lleno de estudiantes de nuevo. Antes de empezar a planear este nuevo curso académico creo que es mejor hacer un resumen del último año, que me quedé después de aprobar los exámenes de cualificación. Este primer post va sobre el paper que nos aceptaron y presenté en Chicago en el workshop Science Cloud -asociado con la conferencia HPDC (High Performance Parallel and Distributed Computing).

El texto completo lo podéis encontrar en este enlace: http://dsl.cs.uchicago.edu/ScienceCloud2010/p01.pdf Un resumen por encima y para los que no estéis especializados en el tema es el siguiente: ahora mismo es posible alquilar ordenadores para ejecutar programas y/o guardar datos en intervalos muy pequeños, a partir de una hora, y a un precio muy barato. Es lo que se llama el cloud computing y hay empresas importantes como Amazon, Google y Microsoft que se están metiendo en este modelo de negocio. Hay muchas personas a las que este modelo les viene muy bien y nosotros ponemos como ejemplo a la comunidad científica. Por ejemplo, un científico tiene su modelo de cómo evoluciona el clima global y lo ejecuta en su ordenador personal. Sin embargo, el nivel de detalle que se puede conseguir con un solo ordenador (incluso de última generación con varios procesadores) es bastante pobre: digamos que el enorme estado de Virginia se modela con 5 puntos diferentes y cada punto nos da información sobre temperaturas medias, etc. Si queremos una resolución mayor, es decir, enterarnos de cómo va a afectar el nuevo clima a las temperaturas de la costa en Virginia Beach o más en el interior en la cordillera de las Blue Rigde Mountains el científico necesita acceso a más ordenadores. Digamos unos 200 ordenadores durante 10 horas. Comprar 200 ordenadores, instalarlos, mantenerlos, pagar por la electricidad, etc. es carísimo y no todos los científicos pueden permitírselo o tener acceso a un centro que lo tenga. Por eso sale mejor pagar a Amazon unos 10 centavos por hora por ordenador: $200 y el cálculo está hecho en una noche en vez de en tres meses.

Éste va a ser el contexto de mi tesis doctoral. A principios del año pasado mi grupo estuvo realizando diversos experimentos en la cloud (nube) de Microsoft, llamada Azure. Nuestra pregunta sería: estoy muy interesado en usar la nube pero la información que veo en las páginas web es bastante vaga, ¿cómo puedo saber cómo se va a comportar mi aplicación y cuál va a ser su rendimiento? ¿Cuáles son las limitaciones o “realmente puedo tener 200 ordenadores a la vez machacando mi base de datos”? Por supuesto, esto es una simplificación y las respuestas tienen muchos matices. Para los que estéis interesados echarle un vistazo al paper que representa mi trabajo del otoño de 2009. Aquí os dejo con el abstract:

A significant open issue in cloud computing is performance. Few, if any, cloud providers or technologies offer quantitative performance guarantees. Regardless of the potential advantages of the cloud in comparison to enterprise-deployed applications, cloud infrastructures may ultimately fail if deployed applications cannot predictably meet behavioral requirements. In this paper, we present the results of comprehensive performance experiments we conducted on Windows Azure from October 2009 to February 2010. In general, we have observed good performance of the Windows Azure mechanisms, although the average 10 minute VM startup time and the worst-case 2x slowdown for SQL Azure in certain situations -relative to commodity hardware within the enterprise- must be accounted for in application design. In addition to a detailed performance evaluation of Windows Azure, we provide recommendations for potential users of Windows Azure based on these early observations. Although the discussion and analysis is tailored to scientific applications, the results are broadly applicable to the range of existing and future applications running in Windows Azure.

Por cierto, la conferencia estuvo bastante interesante y entretenida, incluso nos llevaron en un yate/restaurante por el lago a cenar un día. Y por supuesto, visita al chicagüense de turno.

Grid 2008

Retomo este blog -olvidado desde hace más de un mes- para comunicar una excelente noticia: me han aceptado un paper en la conferencia Grid 2008 que se celebrará en Tsukuba, Japón. En este enlace pódeis ver el trabajo: http://www.cs.virginia.edu/~ar5je/bespp.pdf

Para los no iniciados, la publicación de tu trabajo de investigación es una parte fundamental de tu carrera, ya que sin una publicación revisada por tus pares en una conferencia/revista/journal es como si no hubieras hecho nada. El número de publicaciones y el impacto que están tienen en la comunidad determinan el éxito de tu carrera. En mi campo, Ciencias de la Computación (Informática) las organizaciones principales que organizan las conferencias y publican los trabajos son el IEEE y la ACM (Association for Computer Machinery). Éstas organizaciones financian diferentes conferencias, normalmente anuales, y cada una con una tématica bien definida: Grid obviamente agrupa a la comunidad que desarrolla su investigación en Computación Grid. En mi grupo también solemos participar en SuperComputing. Al frente de cada conferencia está el Program Committee, formado por expertos en el área que provienen de universidades o compañías privadas (como Intel, HP Labs, Microsoft Research, etc.).

El proceso para publicar es el siguiente: una vez realizado tu trabajo de investigación debes escribir un artículo (normalmente entre 8 o 10 folios a doble columna) y enviarlo para su revisión por parte del comité del programa. En este artículo tienes que describir el problema que estás considerando, tu solución propuesta y una evaluación rigurosa que permita concluir que tu solución mejora anteriores propuestas. El comité del programa va a considerar solamente el artículo, y es lo único que se publica, con lo que tienes que sintetizar todo tu trabajo en él. Una vez pasado la fecha límite para enviar artículos, el comité del programa los revisa. Cada artículo es asignado un número de revisores (entre 3 y 5 normalmente, a los que tú como autor desconoces quiénes son) que analizan el paper y comentan sus puntos fuertes, debilidades y su contribución a la comunidad científica. Al final los mejores artículos son seleccionados para la presentación en la conferencia y su publicación. Este proceso de revisión científica intenta asegurar que los resultados publicados son verdaderamente rigurosos trabajos de investigación de calidad. Sin un proceso de revisión independiente tus resultados no tienen credibilidad ya que no se puede asegurar que hayan sido obtenidos científicamente.

Aparte del número de publicaciones también se tiene en cuenta el impacto. Como podéis ver en mi artículo es imprescindible tener una sección que mencione investigaciones similares, y una bibliografía que cite estos trabajos relacionados y todos los resultados anteriores en los que te apoyas (ya que siempre nos alzamos sobre los hombros de gigantes). Así, cuanto más se cite tu trabajo en otros artículos, más impacto se considera que tiene.

Este es mi primer artículo listo para publicación -el segundo vendrá dentro de poco-, y además soy el primer autor, que en Ciencias de la Computación se interpreta como el que realiza la mayor parte del trabajo (no es así en otros campos, en matemáticas se hace por orden alfabético). Volar a Japón es caro, así que no sé si me será posible presentarlo. Pero por lo menos ya se puede decir que acabo de dar el primer paso de mi carrera como científico.

Master’s Project Presentation by Arkaitz Ruiz-Alvarez

Hoy me he dado cuenta que hace un mes que no escribo ningún artículo en el blog. Hasta ahora he tratado de mantenerme en un post por semana, pero he estado bastante distraído últimamente. Una de las “distracciones” es mi proyecto de Master. Es relativamente sencillo sacarse el título de Master mientras estudias en el programa de doctorado en esta universidad. Así, con una presentación de una parte de mi trabajo puedo graduarme en Mayo con el flamante título de “Master of Computer Science” otorgado por la Universidad de Virginia. Aquí tenéis el email con el anuncio a los miembros de la facultad sobre mi presentación:
UNIVERSITY OF VIRGINIA
SCHOOL OF ENGINEERING AND APPLIED SCIENCE
DEPARTMENT OF COMPUTER SCIENCE

Date: April 18, 2008

MEMO TO: Faculty and Students

FROM: Marty Humphrey, Advisor

RE: Master’s Project Presentation by Arkaitz Ruiz-Alvarez

All faculty and students are cordially invited to attend the Master’s Project presentation
by Arkaitz Ruiz-Alvarez to be held on Thursday, April 24, 2008, in Olsson Hall Conference
Room 236D at 2:00 pm. The committee members are Andrew Grimshaw, Chair;
and Marty Humphrey, Advisor.

BES++: HPC Profile Open Source Implementation

The use of computational (HPC) clusters continues to increase among companies, enterprises, universities and research institutions. There are several software products that manage these computational clusters: among them, the Portable Batch System (SGE), the Sun Grid Engine (SGE), Platform’s LSF and, recently, Microsoft Windows HPC Server 2008. Each software uses their own specific format for job description, submission and management. Thus, an organization with more than one cluster must often support multiple, idiosyncratic interfaces to largely similar backend capabilities.

The HPC Basic Profile is a Web-services-based specification aimed to create a common interface to computational clusters by focusing on the basic use case of an HPC system. The HPC Basic Profile specification is applicable to every cluster management software since it is based on a basic set of functionalities that every cluster management software provides, despite the differences in interfaces and data formats. This specification is based on the OGSA Basic Execution Service and the Job Submission and Description Language and offers an abstraction of the most basic interactions with a computational cluster: create a job, check the status and attributes of a job, delete the job and check
the status of the cluster.

In this talk, I present BES++, which is an open-source project that we have created with Platform Computing (LSF). BES++ implements the HPC Basic Profile and is architected to layer on any existing queuing system. We currently have support for PBS, LSF and SGE clusters. In addition to the HPC Basic Profile features, BES++ has been extended to support several extensions such as File Staging and Advanced Filter. We have also added the capability of job metascheduling and the support for legacy client tools such as PBS’s qsub. We present a performance evaluation and an analysis of our implementation.

Semana de Ingeniería en UVA

Atención al email con los eventos para hoy:

Tuesday’s E-Week Events:

8:30am – 10 am, Muffins and Juice, Stacks

1 – 2pm, Four-Square, Darden Court

3:14pm, Pi Eating Contest, Darden Court

8pm, Capture the Flag, Darden Court

RFID y ONS

Hace bastante que no posteo en el blog, pero la vida del ‘grad student’ a veces no te deja mucho tiempo libre -sobre todo cuando la conferencia SuperComputing se acerca-. Hace un par de semanas empezamos en la universidad un grupo de computación distribuida. Nos juntamos cada un par de semanas, en las que una persona comenta un paper en el que esté trabajando o simplemente lo encuentre interesante y discutimos sobre él. El tema de esta semana ha sido los famosos chips RFID y un estándar asociado propuesto, ONS.

Para los que no lo sepáis, RFID puede ser una de las más peligrosas invasiones de la privacidad personal a la que nos enfrentemos en los próximos años -ver info en la Wikipedia española-. Seguro que habéis visto ya estos chips en la vida real adheridos a los productos que compramos. Básicamente es una antena con una mini-memoria conectada que se puede leer a distancia -y sin necesidad de electricidad en el propio chip-. Está diseñado para sustituir a los códigos de barras. Los códigos de barras identifican el tipo de producto, RFID podemos asignar un identificador único a cada producto: caja de cereales, jersey, libro, etc. ya que tenemos memoria suficiente para asignar billones de identificadores únicos. Wal-mart -la cadena de tiendas más popular- quiere obligar a todos sus proveedores a usar estas etiquetas en todos y cada uno de los productos. Entonces, simplemente con acercar tu carro al lector de RFID se podrían leer al instante y generar la cuenta rápidamente. O los proveedores pueden recoger información de dónde está cada producto más fácilmente, etc.

RFID tiene muchos usos legítimos, pero también puede ser utilizado para vigilar a personas. Una persona en unos años llevará varios chips RFID encima sin saberlo. Simplemente por pasar cerca de un detector se puede saber qué es lo que llevas encima: tarjetas de crédito, llaves del coche, qué tipo de teléfono móvil o PDA, marcas de ropa, etc. Y cada uno de estos objetos con un identificador único de producto. Esto requiere tener que escanearte con un lector, con lo que requiere estar cerca, aunque no hace falta contacto físico. Pero ahora es cuando entra en juego el ONS: Object Name Service.

ONS está diseñado encima de DNS (Domain Name Service) y tiene como objetivo conseguir, dado un tipo de producto, un servicio web asociado. Por ejemplo, una lavadora puede leer los RFID de la ropa que tiene dentro, conectarse a los servicios web apropiados y obtener el tipo de lavado que requiere – sólo blancos, algodón, delicados, etc.-. El problema está en que DNS permite hacer muchas cosas malignas. Obtener el servicio web asociado con un chip RFID implica contactar con múltiples servidores DNS: si queremos buscar el producto 54.nike.ons (esto nos lo da el lector de tarjetas al acercarte llevando tus zapatillas) la pregunta pasa por los servidores *.ons, *.nike.ons. Una persona llevará encima un conjunto de RFID tags lo suficientemente único -con alta probabilidad- como para identificarte usando sólo el tipo de producto (y sin recurrir al identificador único). Y los lectores de RFID van a estar en muchas partes. Con lo cual yo puedo apuntar mi programa de seguimiento a múltiples servidores DNS (primero a los de primer nivel, luego va progresivamente bajando de niveles) y preguntar por si han resuelto recientemente (la tienen el la caché) el producto 54.nike.ons (ya que yo sé qué zapatillas llevas). Añadiendo la información sobre el tipo de tu tarjeta de crédito, llaves del coche, etc. puedo conseguir la localización de los lectores de RFID por lo que has pasado en los últimos minutos, ya que la dirección IP de estos lectores lleva cierta información geográfica asociada. En resumen, sólo sabiendo algunos de los productos que llevas puedo seguir tus movimientos (cada X minutos y en un área más o menos pequeña) desde casa haciendo consultas DNS a un número de servidores lo suficientemente pequeño para no levantar sospechas. Y esto por un error de diseño, no por una vulnerabilidad en la implementación de ciertos servidores DNS o ONS.

Aún hay más. Imaginemos que fabrico productos con identificador *.evil.ons. Si consigo que compres un producto manufacturado por mí (el atacante) y te acercas a un lector RFID éste resolverá la dirección 32.evil.ons, por ejemplo. En la respuesta DNS puedo decir que soy responsable también de *.nokia.ons, con lo que si llevas un producto con esa etiqueta encima se enviará a mi servidor y sabré qué otros productos llevan los que hayan comprado los míos (o si he comprometido un servidor ONS, los de esa compañía).

En mi universidad Karsten Nohl (estudiante de doctorado) es el que está trabajando en estos temas y el que nos dio la presentación sobre estos ataques, para los que hay un par de posibles soluciones. Veremos cómo evoluciona esto. Si no, ya sabéis: un par de segundos en el microondas probablemente son suficientes para dañar los chips RFID. O recubrirse de papel de aluminio.

Escrito en CS UVA, Planet. 1 comentario

Criptoanalistas del FBI

Zodiac, aparte de una película reciente, fue un asesino en serio que actúo entre 1968 y 1969 -que se conozca- en el área de la bahía de San Francisco. ¿Cuál es el interés de este caso? Este lunes pasado he asistido a una conferencia especial organizada por el departamento de Ciencias de la Computación. Normalmente suelen invitar a personas que vienen del mundo académico o de la industria que se dedica a investigación -IBM research, HP labs, etc.-. Esta conferencia, sin embargo, fue presentada por Daniel Olson, jefe de la unidad del FBI -Federal Bureau of Investigation- que se dedican a la criptografía. Una charla muy entretenida, en el que el ponente dio un repaso a lo más destacado de su trabajo. Aquí tenéis el PDF

Muchos nos imaginaremos un unidad que trabaja en casos en el que el ordenador hace el trabajo de cifrado. Sin embargo, la realidad es bastante diferente, y de hecho el uso que hacen de las herramientas computacionales es limitado. Nos mostró una lista de los tipos de personas que usan cifrados hechos a mano, en la que destacan: prisioneros, terroristas -tanto internacionales como grupos neonazis locales- y las bandas callejeras.

Por ejemplo, nos enseñó una carta de un dirigente de una violenta banda de la costa este. Al haber leído bastantes cartas sobre él -al parecer él se expresaba normalmente de una forma muy grandilocuente- el lenguaje usado en esta carta se salía de lo normal. En un segundo vistazo apareció el mensaje secreto: si se consideraba sólo una palabra de cada cinco la carta cambiaba completamente de sentido, de saludo informal a discusión de la sentencia de muerte a uno de los miembros. Al parecer esta banda tiene sus propias leyes, y aunque procesan y distribuyen drogas pueden condenar a muerte a alguno que las consuma -Fred en este caso-. Desafortunadamente para Fred, éste llevaba muerto un par de años cuando encontraron la carta. Éste es un ejemplo de esteganografía.

Otro ejemplo que puso es el de el grupo neonazi Aryan Brotherhood. Aunque los reclusos son menos del 1% en prisiones federales, son responsables de al menos el 18% de los asesinatos producidos en las cárceles. Hace unos años cerraron una prisión federal y repartieron los reclusos -en su mayoría de raza negra- entre otras prisiones federales. Los dirigentes de la banda planearon un ataque simultáneo en varias prisiones federales -el mismo día, en un espacio de 15 minutos-. Una de las cartas de los dirigente al exterior hablaba sobre la experiencia de ser abuelo por primera vez. El caso es que no tiene hijos conocidos, y un vistazo a la grafía de la carta revela caracteres escritos de forma diferente. Estos caracteres son el código, cifrado con el método de Bacon. Esta carta es la que daba lu verde a la operación, y fue usada como prueba en el posterior juicio. Aunque no pudieron romper el código al principio, la mayor parte de los asesinatos no se llevaron a cabo ya que hubo un error de comunicación y en una de las prisiones se cometieron dos asesinatos el día anterior, por lo que el resto de las prisiones federales estaba en situación de lockdown al día siguiente.

Muchos de los códigos se rompen después que se ha cometido el crimen, ya que es muy difícil sin la información de contexto analizar la información que les llega. Un ejemplo sacado del informe de la comisión del 11S refleja esta conversación entre Mohammad Atta, líder de los ataques, y uno de los coordinadores en Pakistán:

Atta: “Two sticks, a dash and cake with a stick down. What is it?”

Ramzi Binalshibh: “Did you wake me up just to tell me this?”

Posteriormente, se entiende que estaba comunicando la fecha del ataque (11-9), pero este tipo de códigos son difíciles de descrifar antes de que se cometa el crimen.

Otros ejemplos menos elaborados incluyen cifrados con cambio de alfabeto, con lo que con son vulnerables al análisis de frecuencia. Aunque algunas personas usan varios alfabetos, o un alfabeto mayor que el original con múltiples símbolos que se mapean a un único símbolo original para equilibrar las frecuencias de las diferentes letras. Muchos de estos códigos se rompen más o menos fácilmente, dependiendo de la complejidad y el número de cifrados. Aunque también es muy común hallar errores tontos como en esta conversación telefónica entre drug dealer 1 y 2 -transcribo de memoria-:

Drug Dealer 1: I have picked up the girls. They look pretty good.

Drug Dealer 1′s wife (background): You have picked up what?!?!?!

Drug Dealer 1 to his wife (background): I’m talking about the drugs…

Drug Dealer 2: !

Con lo cual queda claro que girls=drugs y que no todos los delincuentes son maestros del cifrado -más bien al contrario-. Un caso curioso fue el de esta persona que trabajo en inteligencia del Pentágono y se hizo con documentos secretos -información sobre satélites, etc.- Esta persona era completamente paranoica, incluso creía que le estaban filmando en su casa. Así que enterró los documentos en parques naturales en Virginia y Maryland con un sistema curioso. Primero guardaba las coordenadas de un árbol. En el árbol había clavado un clavo que indicaba la dirección en la que caminar. A partir de ahí también almacenaba la distancia en pies al lugar donde estaba enterrado. Al finalizar tenía una lista de 19 coordenadas y distancias que cifrar. Fue detenido por el FBI intentando salir del país para contactar con espías de otros países -Libia y otros que no recuerdo- en Europa. El FBI quería recuperar los documentos y tenía en su poder el documento cifrado, pero no podía descifrarlo. A cambio de beneficios penitenciarios el espía accedió a ayudarles pero no se acordaba del código, aunque estaba relacionado con el libro de su graduación. Esta persona había tomado las coordenadas, sustituyó las coordenadas por letras, y codificaba cada letra según este método: a partir de su foto en el anuario, contaba el número de personas adelante o atrás cuyo apellido empezaba por la letra que quería codificar. La mala suerte de graduarse en una de las pocas escuelas que no tenía a nadie que se apellidaba con la letra F le hizo cambiar el nombre a una persona en el anuario -que aparece como “el misterioso hombre de la máscara- por Frank. Al ser un código complicado que el mismo olvidó con el tiempo, escribió el mensaje en texto claro a continuación del mensaje cifrado -wtf?-.

En definitiva una interesante charla para conocer de primera mano el uso de la criptografía por delincuentes. Por cierto, el mensaje 340 de Zodiac no se ha descifrado aún -en la peli dicen que sí, pero el FBI no considera que la solución tenga sentido-. Al que descifre este mensaje se le ofrece instantáneamente un puesto de trabajo en el FBI -buscad en Internet Zodiac 340, el mensaje cifrado real tiene una correción en un carácter-.

Facebook

Una de las redes sociales más populares en Estados Unidos, sobre todo entre los estudiantes universitarios, es Facebook. Tipo Myspace, pero surgió en el ámbito universitario, concretamente en Hardvard. Al principio sólo podían unirse los estudiantes de esta universidad, para después expandirse al área de Boston y hasta hace un año, cualquier universidad de Estados Unidos (controladoque los correos electrónicos tengan dominio .edu). Hace poco lo decidieron hacer accesible para todo el mundo, con lo que últimamente me he encontrado a gente que conozco de la Universidad de Deusto y CodeSyntax. ¿Para qué sirve esto de las redes sociales? Pues para los estudiantes de postgrado, para perder el tiempo en Internet en vez de trabajar (la célebre procastination):

PHD Comics by Jorge Cham

Ahora más en serio, es una red social en la que puedes comunicarte con la gente cercana a ti: amigos, estudiantes de una misma universidad (o trabajadores de un mismo sitio) o residentes de un área. Está inspirado en los anuarios de los high schools de Estados Unidos, y con el tiempo han ido añadiendo los álbumes de fotos -más fotos añadidas que en Flickr!-, los eventos -puedes preparar una fiesta, invitar a la gente y ver quién ha respondido a tu invitación- o los grupos de interés -como el Eghost o Virginia Atheist and Agnostics club-. En este enlace podéis ver un diagrama del modelo de datos que usan.

Aunque es una herramienta muy popular, hay que tener en cuenta que expones una parte importante de tu vida privada. Por ejemplo, si alguien cambia su “relationship status” éste es visible para tu grupo de amigos -depende de tu configuración, pero es así para mucha gente-, con lo que te enteras de las idas y venidas de las parejas en Internet antes que en persona. Hay que tener cuidado con la gente a la que das acceso a tu perfil, que pueden llegar a ser cientos de pesonas -si tu principal red social es la universidad-. Además, he oído rumores que su creador, Mark Zuckerberg trabajaba enviando spam (y ahora tiene los datos de millones de personas ummm).
Si os animáis a probad Facebook, ya sabéis donde encontrarme (no hay muchos Arkaitz de momento xD).

Escrito en CS UVA, Planet, USA, UVA. 1 comentario

Last.fm

Para los que no lo conozcáis, last.fm es una página web/servicio/programa instalable que puedes usar para tener un registro de todas las canciones que escuchas (a través de iTunes, por ejemplo). Con tu perfil de usuario ya creado, se pueden hacer muchas cosas, como buscar más información sobre los grupos que te gustan, encontrar otros usuarios con gustos parecidos, etc. La base de datos que tienen de usuarios es bastante grande, y cada usuario puede añadir etiquetas a cada canción, con lo cual se abren posibilidades muy interesantes como la de tener tu propia radio en Internet personalizada. En base a la música que escuchas te envían grupos similares -está muy bien para descubrir nuevos grupos-, y puedes ajustar más los filtros indicando si te gusta o no lo que te van poniendo.
El caso es que estaba escuchando la radio y pusieron una canción de unos de mis grupos favoritos, Dire Straits. Además de todos los datos de la canción (y un enlace a Amazon por si quieres comprar el álbum) te pone el enlace a una bio del grupo con la historia, éxitos y demás. Me dio por leerla, y en ésta se mencionaba que el videoclip de Money for Nothing (del álbum Brothers in arms) usaba groundbreaking computer-animated video. Me picó la curiosidad por ver este vídeo del año 1984, así que me puse a buscar en Youtube (¿dónde si no?) y este es el resultado:

Escuchar una radio personalizada, encontrar información de un grupo con un sólo click de ratón y encontrar un vídeo musical de 1984 en menos de dos minutos. La verdad, me parece increíble lo que se puede lograr con estas herramientas que se basan en la colaboración entre usuarios.

We are sorry to inform you

Ya se terminaron mis vacaciones – que ya comentaré en otro post- y estoy de vuelta en la oficina. Uno de los correos electrónicos pendientes que tenía era la decisión del comité del programa de Micro 40 sobre el artículo que envié. Desafortunadamente, es un rechazo (aunque era previsible, Micro es una conferencia muy competitiva y no tuvimos tiempo para terminar el paper). De todas formas, el correo empieza con la típica frase “We are sorry to inform you …”, lo que me ha recordado a un artículo que leí hace tiempo en una de las publicaciones del IEEE: We Are Sorry to Inform You … Santini, S.

Este artículo es una recopilación de las más desafortunadas equivocaciones de los revisores que participan en el peer review. No tiene desperdicio las críticas a la programación structurada de Dijkstra, el modelo de bases de datos relacionales de Codd, etc. Mi favorita, el comentario sobre el artículo de Turing: si no se puede computar es porque el número está fuera del rango o el ordenador está roto. Ah, y que no se le olvide a Turing traducir Entscheidungsproblem al inglés (pobre Hilbert).

Menos mal que los respectivos autores no cejaron en su empeño de publicar sus artículos. El método de revisión por pares es esencial en el mundo científico, pero dista mucho de ser perfecto. Imaginaos que el revisor tiene un mal día y nos quedamos sin la programación estructurada…

Micro 40

Estas tres últimas semanas he estado muy ocupado trabajando en un paper, así que no he tenido tiempo para escribir posts. Pues bueno, éste es el primero de algunos post que tengo en mente y cómo no, voy a hablar del paper que hemos entregado para la conferencia Micro en su edición 40 (una conferencia ya veterana en Ciencias de la Computación). Esta edición es en Chicago a primeros de Diciembre. La temática de esta conferencia está enfocada a la microarquitectura, aunque tienen su sección para sistemas que instrumentan binarios dinámicamente. Este área está entre arquitectura y compiladores, así que las conferencias importantes sobre estos dos temas suelen tener una sección dedicada a ello. Ya hablé sobre Pin en un post anterior, y de la utilidad de estos sistemas. También hablé sobre la clase a la que asistí el semestre pasado, Virtual Execution Environments.

Pues bien, al terminar el semestre la profesora, Kim Hazelwood, me animó a extender el proyecto de clase para enviarlo a Micro. El mayor problema estaba en el tiempo disponible. El plazo terminaba en dos semanas, así que hubo que ponerse las pilas, y bien. Después de dos semanas intensas, repitiendo simulaciones y experimentos, acabé de escribirlo en el aeropuerto de Dulles, junto antes de embarcar en un vuelo a Chicago (mini-vacaciones planeadas antes de que supiera nada del paper). Acto seguido, Kim lo revisó en una habitación de hotel en San Diego (daba un tutorial de Pin al día siguiente) y lo envió justo a tiempo. Literalmente minutos antes de que se acabara el plazo. Así que podéis haceros a la idea. Una experiencia muy estresante.

Para los informáticos, os dejo el abstract, a ver que tal os suena. Se aceptan comentarios:

Dynamic binary instrumentation systems offer a wide range of new applications such as program instrumentation, optimization, and security. DBIs use a JIT compiler to add instrumentation and store the instrumented traces in a software code cache. The code layout in the code cache greatly differs from the code layout of the original program. It is widely assumed that the system cache performs better with instrumented code due to trace layout, although there is no formal evaluation of these icache effects in the literature. This paper provides an exhaustive, cross-architecture, cross-platform analysis of the performance of the instruction cache and other structures of the micro-architecture while a DBI executes.


In order to perform our evaluation, we have developed two tools: one that uses simulation to evaluate the locality of the application, and another that directly accesses the hardware performance counters to determine actual icache miss counts. Our results show that when executing an application under the control of a DBI, icache miss count actually increases anywhere from 2X to 4X, depending on the DBI used. This performance degradation is due to the impact of the instructions added by the DBI, which increases the memory use of instrumented programs and the number of instructions that are finally executed. We find that these observations hold regardless of the trace length and code cache size. These surprising results provide a better understanding of the efficiency of current instrumentation tools, and overturn the prevailing assumption that trace-based systems improve instruction cache performance.

En definitiva, ha estado bien como experiencia. Y si lo aceptan en una conferencia importante como Micro tendré motivos para estar muy satisfecho (aunque no sé si la contribución del paper es suficiente). En los próximos días ya comentaré algo sobre Chicago.

Seguir

Get every new post delivered to your Inbox.