Por favor, háblanos un poco sobre ti. He estado viviendo y trabajando en Silicon Valley durante aproximadamente 20 años, realizando primero trabajos de codificación y algorítmicos para varias empresas tecnológicas y luego para empresas más grandes. La mayor parte de ese trabajo estaba relacionado con software EDA para el diseño de chips. En realidad, estoy medio retirado (en el sentido de que todavía trabajo, pero principalmente en mis propios proyectos de investigación, no por un salario) desde que me despidieron de mi última empresa hace 6 años. Actualmente vivo en Cupertino, el corazón del país de Apple, aunque nunca he trabajo allí. Es agradable estar cerca de las colinas costeras, aunque los precios de los inmuebles y de los alquileres son realmente altos. Mi hermana y su familia (marido e sus hijos gemelos de 9 años) viven en North Bay, así que los veo con bastante frecuencia. En realidad, vengo de ciencias, pero no de ciencias de la computación: mis títulos de posgrado de la Universidad de Michigan son de Ingeniería Aeroespacial y Matemáticas. Mi tesis doctoral se centraba en la mecánica teórica de fluidos, específicamente en los flujos de vórtice. Muchas ecuaciones diferenciales, matemáticas aplicadas y análisis numérico. Mis conocimientos en codificación que salieron de la universidad eran de informática científica, es decir, Fortran. Aprendí por mi cuenta los principios básicos de C y C ++ después de mudarme a Silicon Valley, y adquirí en el trabajo la mayor parte del resto de conocimientos que necesitaba saber sobre estos lenguajes y algoritmos de estilo CS y estructuras de datos.
¿Cómo empezaste con los ordenadores? En un contexto de trabajo con algoritmos y programación, terminé haciendo ambas cosas durante mi trayectoria profesional y con una continua investigación. Es importante tener en cuenta que, recordando mis primerias experiencias de la universidad, era uno de los frikis de código menos prometedores de la historia. Era un estudiante novato de primer año de la Universidad de Michigan en el otoño de 1981, y como tal, pertenezco a una de las últimas graduaciones en ingeniería de programas que sufrió la programación de Fortran para cursos de ingenieros, tal y como estaba constituido por aquel entonces. El centro de cálculo estaba ubicado en una mediocre estructura que se encontraba literalmente debajo de un paso elevado de peatones, y que formalmente fue nombrado Edificio de la Universidad del Norte, pero conocido por todos por sus siglas, NUBS. Todo estaba basado en una configuración de tiempo compartido con coste escalonado basada en un macro-ordenador estándar, que era un sistema Amdahl. Estoy seguro que fue creado como una alternativa de coste más razonable a la serie IBM 360 líder en el mercado. El verdadero problema, como suele pasar en estos casos, reside en el software: un compilador de sistema no IBM significaba precisamente tener un compilador que no era de IBM, y aunque desconozco qué compiladores alternativos podían haber tenido Amdahl Corp. para ofrecer, sé que los usuarios del sistema tenían que cargar con un compilador un tanto experimental de Waterloo U. en Canadá. El problema era que los mensajes de error del mismo eran tan crípticos (a menudo simplemente códigos de error hexadecimales bastante confusos, incluso sin un número de línea de programa), que para nosotros los novatos era un sistema de mensajería de error de sintaxis binaria: 1 = " hay> = 1 errores de sintaxis en tu código, no me preguntes dónde, así que buena suerte con la búsqueda", y 0 = “¡felicitaciones! hay 0 errores de sintaxis en tu código, aquí están tus resultados (probablemente incorrectos) ". Incluso esto hubiera sido pesado pero factible, pero el segundo gran problema era que había muy pocos terminales de línea de impresión y aún menos terminales interactivos disponibles, todos estaban ocupados al 100% por estudiantes de posgrado en ciencias de la computación, así que estábamos limitados a las máquinas de tarjetas perforadas, para las cuales también había colas de espera. Así que una vez que finalmente conseguías un asiento en uno y transcribías todos tus esfuerzos iniciales escritos a mano en un programa para su asignación en tu pequeño pack de tarjetas de papel en forma de baraja, tenías que abandonar tu asiento, llevarte el pack de tarjetas a la máquina lector más cercana, quizás tenías que espera un poco en la cola que se formaba allí, luego te dirigías a la ventana del dispensador de papel impreso para recuperar tu listado de programas y, si tenías suerte, obtenías tus resultados. ¿Tienes un cripto-mensaje de error de sintaxis? Pasas un tiempo analizando tu lista de programas, identificas los posibles errores, después vuelves a la cola de espera de la sala de máquinas de la tarjeta perforada. ¿Sin errores de sintaxis, pero con errores en tus resultados? Más de lo mismo. El insulto final era que a los novatos se les asignaba una cantidad ridículamente pequeña de créditos en cuenta para el tiempo compartido. Creo recordar que eran 2$ de crédito para los proyectos de todo un semestre, sin opción de añadir más. Dado el sistema de precios que estaba vigente, la única forma de convertir dicha cantidad en un número remotamente razonable de ciclos de depuración de los que hemos descrito anteriormente era usar las instalaciones por la noche, cuando los precios estaban en su nivel más bajo. El resultado era que incluso la asignación de programación de 50 líneas más simple casi invariablemente se convertía en una horrorosa sesión de trabajo durante toda la noche.
Como consecuencia, durante el resto de mis días como estudiante universitario, el único tipo de codificación que llegue a hacer fue en mi fiel calculadora programable HP-41C. Si por aquel entonces alguien del futuro hubiera llegado y me hubiera dicho que terminaría escribiendo (casi completamente desde cero) y manteniendo un programa que consta de aproximadamente medio millón de líneas de código, le habría dicho que estaba loco. Por supuesto, el destino, como lo hace a menudo, tenía otros planes. Mientras estaba en la facultad, me saqué un dinero extra trabajando aproximadamente unas 20 horas a la semana realizando trabajos de carpintería y mantenimiento para un casero local, y pasé tantas horas como me quedaban disponibles realizando actividades al aire libre: Escalada en rocas y viajes de montañismo en verano, ciclismo, artes marciales.
En el verano de 1987, después de haber finalizado mi licenciatura estaba preparando para empezar un programa de doctorado en dinámica de fluidos experimental cuando durante una sesión de ciclismo de montaña sufrí un desagradable derrame celebrar y terminé con el cuello roto y una parálisis desde el pecho hacia abajo. Así que me hice con un laboratorio experimental lleno de equipos; mi trabajo con las matemáticas y la computación yacía dentro. Afortunadamente, los laboratorios de computación de la universidad se habían trasladado a estaciones de trabajo y PC, así que pude hacer la mayoría de la codificación de mi investigación de posgrado en estaciones de trabajo DEC Vax, con software de calidad, una experiencia muy diferente a la que tenía como estudiante de primer año.
¿Qué te atrajo a la plataforma ODROID? Como tome nota del artículo de números primos del mes pasado en ODROID Magazine, después de pasar gran parte de los últimos cinco años escribiendo código ensamblador para los diversos conjuntos de instrucciones aritméticas vectoriales SIMD x86 (SSE2, AVX, AVX2 + FMA3, AVX512), el último año también estaba considerando realizar una primera incursión para añadir soporte SIMD a una familia de procesadores que no fueran x86, y la compatibilidad con vectores de 128 bits de la familia de CPU ARMv8 encajaba perfectamente. Tras realizar algunas tareas con una plataforma de desarrollo de bajo coste, pero razonablemente de alto rendimiento para esta tarea de codificación, el ODROID-C2 surgió como la mejor opción. Obtuve un 50% más de rendimiento con mi código en el C2 que en el Raspberry Pi3. También he recibido los resultados de las pruebas de rendimiento de una versión preliminar del ODROID N1 gracias a un usuario del foro ODROID que fue seleccionado como uno de los analistas beta para el N1, y parece muy prometedor, utilizando las dos CPU del N1 (dual-core Cortex a72 y quad-core Cortex a53), se consigue más o menos el mismo rendimiento que el "pequeño" socket a53 de un C2 (que está basado en la misma CPU quad-core), y el 'big' CPU dual-core a72 ofrece aproximadamente 1.5 veces ese rendimiento. La ejecución de los trabajos en ambos sockets se reduce simultáneamente aproximadamente un 10% en cada uno de esos socket, por lo que no conseguimos 2,5 veces el rendimiento total del C2, pero sigue siendo más del doble que el del C2. De modo que, el C2 definitivamente fue una buena opción como mi primer ODROID.
¿Cómo usas tus ODROID? El año pasado, los 4-5 meses posteriores a la compra de mi C2 me dedique a la codificación del ensamblaje online para tareas pesadas, la depuración y a reajustar el rendimiento. Desde que liberé el código ARMv8 he usado mi C2 más o menos de la misma forma que espero que lo hagan los usuarios de mi código, indagando primero en el proyecto de computación distribuida GIMPS. (En caso de que alguien se lo esté preguntando, no elegí el acrónimo del proyecto ni cometí ninguna falta). También es muy útil tener una máquina con una versión diferente de Linux y GCC instalada ya sea mi Macbook o mi gran sistema Intel quad-core, en caso de que necesite localizar un problema de compilación que parece estar relacionado con el compilador o la versión del sistema operativo.
¿Cuál es tu ODROID favorito y por qué? El ODROID-C2 por supuesto, al menos hasta que el N1 salga a la venta.
¿Qué innovaciones te gustaría ver en futuros productos Hardkernel? Soy un gran consumidor, así que supongo que mi respuesta se reduce a "¡más sockets!". En particular, estoy interesado en cuántas placas ODROID necesitaría para competir con un sistema quad Intel de gama alta, y cómo los respectivos precios de esas opciones de rendimiento similar se compararían. Basándome en el rendimiento relativo de mi Intel quad Haswell y ODROID-C2 y N1, necesitaríamos unos 20 C2 para poder competir con el Haswell y alrededor de 10 N1. Una vez que llegásemos a "alrededor de 10", este tipo de paquete compacto multi-placa ya sería un poco excesivo. El precio al consumidor estimado para el N1 sigue siendo un poco más alto de lo que a uno le gustaría, pero no mucho. De todos modos, estos son los típicos sueños que tiene este ODROIDer. También creo que los micro PC Linux son una excelente manera de que los niños se interesen por los ordenadores de una forma que evite el efecto "Recinto cerrado" que tiene los PC con sistemas operativos propietarios; Pienso que tal vez algún tipo de iniciativa a nivel de educación que pusiera estos sistemas en manos de niños con bajos recursos escolares valdría la pena que la gente de Hardkernel analiza. Este es el tipo de cosas que podría atraer subvenciones del gobierno o de fundaciones privada para su patrocinio.
¿Qué hobbies e intereses tienes aparte de los ordenadores? Siempre he sido una persona a la que le gusta trabajar no solo con la cabeza sino también con las manos. Una cosa que le falta a las matemáticas y a la codificación es la satisfacción tangible que conlleva la construcción física de algo, de modo que siempre me gusta tener algún tipo de proyecto manual que satisfaga esa necesidad. Hace un par de años construí un banco de trabajo realmente resistente con madera de salvamento, en su gran mayoría pallets ya desechados que eran usados a nivel industrial para el envío de equipos informáticos. El proyecto de este invierno fue construir un soporte de exposición para un gran meteorito de hierro (45 kg) que compré hace algunos años, a partir de una base de piedra caliza travertino cubierta con un bloque de piedra arenisca natural perforada para sostener tres barras de acero que actuasen a modo de trípode para sujetar el meteorito. La perforación resultó ser la parte más difícil: uno espera que la arenisca sea bastante blanda y fácil de trabajar, pero este bloque era arena que aparentemente se había erosionado a partir de algún tipo de mineral duro, lo conseguí gracias a una broca de punta hueca recubierta de diamantes y varias horas de continua y fuerte presión con un taladro y agua para lubricar las partes. ¡Las pase canutas tomando mucho ibuprofeno esa semana!
¿Qué consejo le darías a alguien que quiere aprender más sobre programación y matemáticas? Buscar un problema que realmente le interese y que le pueda servir como medio de aprendizaje para estos temas. He tenido varios de estos en mi carrera, ya que mi investigación de doctorado tenía aspectos de ecuaciones diferenciales, análisis asintótico, teoría de perturbaciones, álgebra lineal y sistemas propios. Mi trabajo con números primos implica aritmética de grandes números enteros y algoritmos de procesamiento de señales, código ensamblador aritmético vectorial, además de una fascinante y rica historia sobre algunos de los lumbreras más brillantes de la historia de las matemáticas. El mundo de la ciencia está lleno de problemas así de interesantes; Créeme, sabrás cuando algo así te atrape. Tener tiempo en nuestro moderno mundo lleno de distracciones y gobernado por el dinero para conseguirlo, este es quizás el problema más complicado.
Be the first to comment