Rigel en Inglaterra

jueves, julio 09, 2009

Rigel reloaded

No es que no haya pasado nada interesante en los últimos meses, más bien es que han pasado demasiadas cosas y no sé muy bien como organizarlas en una entrada de blog.

A finales de mayo empecé a trabajar en Qualcomm, otra de estas empresas enormes. Curiosamente el estilo de trabajo es muy distinto a AMD –se parece más y más a Dilbert.

En cuanto al día a día he estado haciendo tareas que nunca había hecho antes, tales como hacer planes de proyecto. La más interesante ha sido revisar ciertas especificaciones de hardware y sugerir mejoras. Como las GPUs son procesadores de propósito específico, podemos cambiar su arquitectura y repertorio de instrucciones como nos parece. No es como diseñar una CPU que tiene que seguir estrictamente el repertorio x86.

Me ha costado semanas de discusiones y justificaciones, pero finalmente los ingenieros de hardware han aceptado todas mis propuestas. ¡Mola mucho haber diseñado/mejorado la semántica de unas cuantas instrucciones!

Por cierto, uno de los ingenieros  con los que he trabajado fue el arquitecto jefe de la GPU de la XBox 360. Menuda cagalera me daba hablar con este tipo al principio... menos mal que es un tipo de trato muy normal –aunque sea jodidamente listo.

Hay una reflexión que quiero compartir con vosotros. El trabajar diariamente a tan bajo nivel, pensando al nivel de bits y de instrucciones de código máquina, hace que la diferencia entre software y hardware se emborrone completamente.

Cuando era un estudiante estos dos conceptos eran diametralmente opuestos. El hardware era algo fijo e inamovible, testeado a fondo y sin posibilidad de contener errores. El software era flexible, continuamente cambiante y siempre con cierta cantidad de bugs. El hardware era una roca y el software era la ola que chocaba contra ella.

Nada más lejos de la realidad. El hardware se programa de manera similar al software; sus especificaciones y funcionalidad también varían. Por supuesto que contiene errores, y son los programadores de los drivers los que tienen que hacer encaje de bolillos para sortear los bugs.

A fin de cuentas, tanto si un algoritmo está implementado en hardware como si está implementado en software, sigue siendo el mismo algoritmo. El software se compila, y una vez tiene la forma de un ejecutable es básicamente fijo e inamovible. Con el hardware pasa lo mismo: inicialmente tiene forma de código fuente con sus comentarios y demás. Luego pasa por unas etapas equivalentes a compilar y enlazar. Ese es el punto en el que la mayoría de los programadores obtienen acceso al hardware: cuando ya está congelado.

Para el usuario del software, éste es tan fijo como el hardware sobre el que se ejecuta. El software es sólo "soft" para nosotros los programadores que tenemos la oportunidad de modificarlo. El hardware nos parece "hard", pero solamente porque hemos llegado tarde. Si hubiésemos visto cómo fue desarrollado descubriríamos que en realidad todo es software. O mejor dicho, todo es computación. La diferencia es púramente conceptual.

Tras esta reflexión tan Zen os dejo para que podáis pensar en ello por vosotros mismos.

6 Comments:

  • Podrías darle una paliza al arquitecto de la GPU de la 360 de mi parte?

    By Blogger Gabriel, at 10:01 a. m.  

  • Si tienes alguna queja en particular puedo redirigirsela (no prometo nada).

    Que tiene de malo esa GPU? Nuestra GPU actual es una version muy simplificada de la que viene en la xbox 360 y funciona sin problemas. No creo que tarden mucho en salir moviles con este chip.

    By Blogger Rigel, at 3:23 p. m.  

  • Pues me ha gustado la reflexión. No hace tanto que supe que la verificación formal, en especial la "rama dura" de la misma, se usa mucho más para validar hardware que software. No sé si será mucho preguntar (si lo es sólo tienes que decirlo) pero, ¿qué métodos de testing se utilizan por ahí?

    By Blogger _luara_, at 7:21 a. m.  

  • Laura, me alegra que hagas esa pregunta. Tanto para la verificación de software como para la verificación de hardware usamos baterías de tests. No conozco ningún equipo en empresa real en la que usen métodos formales para ninguna tarea. Siento decepcionarte.

    By Blogger Rigel, at 10:38 p. m.  

  • No me decepcionas X-D. ¿Esas baterías de tests se generan y mantienen manualmente?

    By Blogger _luara_, at 10:32 a. m.  

  • Las baterías de tests para software se hacen completamente a mano y se mantienen a mano. Se ejecutan automáticamente al menos una vez al día.

    Sobre los tests de hardware, como te imaginas, no sé tanto. Preguntaré.

    Además de los test propiamente dichos, parte de la seguridad que tienen de que el hardware está bien escrito procede de que antes de escribir el hardware crean en C un software que emula el comportamiento del hardware futuro. Tanto el emulador como el hardware deben producir exactamente los mismos resultados en todos los tests.

    Estrictamente hablando hay errores que solamente se pueden detectar en el hardware final puesto que dependen de secuencias temporales muy delicadas que el emulador en C no puede reproducir. Estos bugs a veces sólo aparecen tras pasar horas ejecutando el mismo test repetidamente. Te puedes imaginar que son un latazo de corregir, porque cada vez que quieres comprobar si has corregido el error tienes que esperar otras N horas (20, 30, 40 horas...).

    Esto que te cuento son prácticas comunes a todas las empresas en la que he trabajado. A mí personalmente me ha sorprendido ver que la metodología de trabajo es muy similar en todas partes. Está muy bien establecida.

    By Blogger Rigel, at 2:58 p. m.  

Publicar un comentario

<< Home