Capacidad de convicción

En los últimos dos meses he pasado gran parte del tiempo discutiendo con ingenieros de hardware. La discusión más encarnizada que tuve duró cosa de dos semanas.

Resulta que el hardware con el que estábamos trabajando tenía cierta limitación hasta el momento no había sido un gran problema pero que sabíamos que lo sería en un futuro cercano. El manager del equipo de hardware insistía en que teníamos que solucionar el problema de alguna manera mediante software. Los ingenieros de software le respondían que iba a ser muy costoso tanto en tiempo de desarrollo como en rendimiento. La tensión era palpable y ninguno de los 15 ingenieros implicados sabían cómo salir del atolladero.

En esto que le pregunto de qué se trata el problema a Andy Gruber, el arquitecto jefe de la GPU de la Xbox 360. Él me lo explica, y pensando un poco en ello se me aparece una lucecita encima de la cabeza. ¡Eureka! Sé cómo solucionar el problema, y la solución además es más eficiente y más elegante que el diseño actual.

Entonces escribo un email largo explicando este nuevo diseño, por qué soluciona la limitación anterior, por qué es correcto en todos los casos, y por qué es más eficiente. El manager del equipo de hardware me responde diciendo que el algoritmo es tan desastroso que no funciona en ningún caso.

¿Me amedrento? ¡No! Le respondo por qué su análisis es erróneo, y escribo una prueba semi-formal de por qué el diseño que propongo es correcto en todos los casos. El tío todavía se resiste, y encuentra un error en el algoritmo que propuse. La idea fundamental era correcta, pero cometí un error en la implementación.

Tras dos semanas de discusión y de convencer a varios ingenieros uno por uno, finalmente el manager admite que el nuevo diseño funciona, no tiene pegas y da mejor rendimiento que el anterior. Todo un éxito, ¿verdad?

Pues todavía hay más: hoy recibí un email que dice que la empresa va a intentar patentar la idea. No es particularmente compleja, pero los ingenieros implicados piensan que es patentable. Así que hay una pequeña probabilidad de que haya una patente de hardware conjunta con mi nombre escrito en ella.

La situación me parece de lo más graciosa. El manager pasó de pensar que la idea era completamente equivocada a pensar que deberíamos patentarla en menos de un mes. ¿Y qué diablos hago yo en una patente de hardware?

Esto también tiene relación con la entrada anterior. El motivo de que un ingeniero de software puede colaborar en el diseño de hardware es porque en el fundamento de ambas disciplinas es la computación, y ambos tipos de ingenieros pueden colaborar y entenderse. A fin de cuentas todos estamos hablando dialectos distintos de un lenguaje común.

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.