Che, leí la transcripción entera (es la charla de Jim Keller, con esa introducción medio caótica al principio). Te tiro el resumen en párrafos, técnico y sin vueltas.
Keller arranca haciendo historia personal: lleva 40 años en esto, empezó en 1982 con la VAX 8800 en Digital Equipment, una máquina que costaba medio millón de dólares, tardó 150 personas cinco años en construirse, corría assembly y C, y tenía como 5000 compuertas (60 gate arrays de 200 compuertas cada uno). El dato fuerte es que esa máquina tuvo 500 bugs encontrados en el chip, y él mismo bromea que hoy un solo diseñador de RTL puede meter 500 bugs solo, la diferencia es que ahora las herramientas de verificación son muchísimo mejores.
La idea central de toda la charla es la de las capas de abstracción. Cuenta que aprendió esto de un spec de networking de los 80 que definía capas (física, enlace, transporte, etc.) y que la genialidad de ese diseño es que podés innovar en una capa sin tocar las demás, hacer algo diez veces más rápido en una capa sin romper nada arriba o abajo. Esto lo traslada al diseño de chips: fabricar silicio se reduce a cuatro operaciones básicas (depositar material, pulir, patronar y grabar/etch), y un proceso de semiconductores moderno tiene entre 60 y 80 capas, con unos 8 pasos por capa, o sea del orden de 600 pasos. Su punto es que nadie es “genio” haciendo un chip de 80 capas átomo por átomo; es la iteración de un proceso simple repetido por cientos de miles de personas durante 40 años. Complejidad, dice, es “demasiadas cosas juntas en un solo lugar”, y la solución siempre es descomponer en pasos, igual que aprender física heavy o subir una montaña.
Aplica esto al flujo de diseño de un chip: aplicación → especificación de arquitectura → modelo de referencia → modelo de performance → microarquitectura → estrategia de verificación → implementación. Cada etapa es un skillset distinto y según él la gente entra por verificación (dice que la gente de verificación tiene una psicología particular, “se enoja cuando las cosas no andan”, están para desconfiar de todo), después pasan a implementación (perfil conscientious, cuidadoso), y los arquitectos —él se define como arquitecto— tienen la actitud opuesta: optimismo temerario, “sí, podemos hacerlo, ya lo vamos a resolver”. Aclara que no hay un camino obligado de carrera: vio pibes recién salidos de la facultad arquitectando cosas grandes, y gente sénior en verificación.
Un dato técnico interesante es la comparación entre cómo piensa el cerebro humano (en paralelo masivo, 10 mil millones de neuronas disparando algo así como 10^20 operaciones por segundo) versus cómo se ejecuta un programa de computadora (una narrativa serial estricta, instrucción por instrucción). Su punto es que aunque nuestro pensamiento consciente se siente lineal (“si esto es más grande que esto, hacé esto”), por debajo el hardware biológico no tiene nada de serial, y sin embargo los programas de C, Java, HTML, todo lo que hicimos en 50 años de compute, terminan compilando al mismo modelo serial de siempre aunque el hardware haya cambiado radicalmente (mainframe → mini → estación de trabajo → PC → celular, la “ley de Bell”).
Sobre Moore’s Law, dice que la curva sigue moviéndose (menciona que el M1 Ultra de Apple está justo sobre la línea de la curva en cantidad de transistores) y hace una observación técnica sobre litografía: cuando reducís la longitud de onda de la luz para hacer features más chicos, la energía por fotón aumenta (relación inversa), y esos fotones más energéticos empiezan a mover átomos que no querés que se muevan — un problema físico real de los nodos de proceso más avanzados. Como contraparte, menciona que la biología es muy buena colocando átomos con precisión, y que él está trabajando con estudiantes en “self-patterning / self-replication”, sugiriendo que la industria de semiconductores todavía no exploró ese camino en serio.
En cuanto a nombres y contexto externo: menciona el x86-64 instruction set (crédito histórico), el A4/A5 de Apple, y su paso reciente como “CPU” de una empresa que categoriza como orientada a IA y RISC-V. Cuenta que esa misma semana tenía programada una charla con el primer ministro de India sobre cómo India puede liderar en tecnología de chips, y admite con humor que todavía no sabe qué le va a decir. No cita libros o papers específicos por nombre en este fragmento — la única referencia externa que da es “andá a Wikipedia” para ver el detalle de los pasos de fabricación por capa.
Sobre lo controvertido: en este tramo puntual de la transcripción no hay declaraciones personales fuertes (nada de vacunas, política partidaria, parejas, etc.) — es prácticamente todo técnico e historia de ingeniería. Lo más “picante” es la crítica implícita a la cultura de RTL moderna (un solo ingeniero puede generar tantos bugs como todo un equipo de los 80), y la certeza con la que dice que la narrativa de “la próxima generación de litografía no va a cruzar en costo” siempre resultó falsa históricamente — una pica indirecta a los fabricantes (Intel/TSMC) que hacen ese pronóstico cada tanto.
Che, seguí con esta parte, que es más densa técnicamente todavía (PCIe, el chip de Tesla, el proyecto RISC-V que están armando ahora, y empieza a meterse con compiladores y basic blocks). Va el resumen.
Arranca con un ejemplo de diseño de IP concreto: un controlador PCI Express que armó en una startup con solo tres personas (uno hizo el controller, otro el PHY, otro la verificación), para un gen 1/gen 2, y que incluso metieron una feature rara: podían stremear datos de Ethernet gigabit directo por PCI Express, troceando paquetes de 1500 bytes (el MTU típico) para adaptarlos al tamaño de bloque más chico que maneja PCIe. Dice que la verificación fue la parte difícil y que no la pensaron lo suficiente al principio. Contrapone esto con lo que vio después en Intel, donde había cinco grupos distintos trabajando en el controlador PCIe, cada uno con 50-60 personas, para algo con un I/O controller de unos 100 millones de transistores (mil veces más transistores que toda la VAX 8800 de la charla anterior). La idea que remarca es que un controlador PCIe gen 4/5 de nivel servidor se parte en: interfaz coherente, buffer manager grande (por la latencia de memoria con muchos streams), link error controller para confiabilidad, y una parte digital (DSP simple) separada de la parte analógica.
Después cuenta el caso del chip de Tesla, el de Full Self-Driving, armado por su equipo en menos de 18 meses. La arquitectura era un SoC con un memory controller, un bus interface, un cluster de 12 CPUs, un controlador PCI Express, y lo único que diseñaron desde cero fue el motor de IA (el NNA, aunque no lo nombra así acá). Ahí tira una idea técnica fuerte sobre Caffe (el framework de deep learning viejo): normalmente el compilador toma el output de Caffe (una lista de instrucciones tipo matrix multiply, convolution) y lo compila a un lenguaje SIMD genérico, lo cual es un compilador complicadísimo si querés que ande rápido. En Tesla, como sabían de antemano el tamaño exacto de la imagen y cuánto “peso” (latencia) se podían permitir sin que la gente se muera (auto autónomo, tiempo real), construyeron un motor de ejecución que ejecutaba las operaciones de Caffe directamente, sin la capa de traducción a un lenguaje intermedio — se comieron una capa entera de abstracción a propósito porque conocían el caso de uso específico. El chip completo tenía miles de millones de transistores: 12 procesadores, GPU, procesador de imagen, DisplayPort, etc., pero a nivel top-level SoC solo había 6-7 bloques físicos conectados por tres cosas (menciona “noc”, clock, y algo de scan/test), y por eso casi nunca encontraban bugs a ese nivel — la complejidad estaba contenida dentro de cada bloque, no en la interconexión.
Cuenta también, con bronca contenida, que en su paso por Intel armaron un plan real para hacer Zen 1, 2 y 3 (asumo que se refiere al período previo, en su etapa AMD/Intel, la cronología es confusa en la transcripción) basado en la observación de que ARM y x86 modernos son básicamente máquinas RISC por dentro, con el front-end decoder como el único bloque que realmente cambia entre instruction sets; el resto (ejecución, front decode, I-cache) puede compartirse. Dice que el proyecto lo cancelaron (“stupidly”, con bronca explícita) por management. En 40 años, dice, pasamos de máquinas no pipelined a pipelined, superpipelined, superscalar, out-of-order, con transistores yendo de miles a cientos de millones, y estima una mejora de rendimiento del orden de 25x solamente por la microarquitectura del pipeline (separado de Moore’s Law).
Hay un dato técnico específico sobre instruction set matching: comparando ARM vs x86 en floating point, la mayoría de los programas reales usan un subconjunto chico de instrucciones (multiply-add y poco más), y el resto de instrucciones “raras” casi no aportan al tiempo de ejecución real, aunque estén en el ISA. También habla del modelo de memoria: ARM tiene un modelo de memoria débil (weak memory model), y aunque uno podría construir una CPU con memory ordering fuerte tipo x86 (store ordering estricto), en la práctica correr código ARM sobre eso no te ahorra mucho tiempo de pared (wall-clock) — el costo/beneficio del modelo débil no es tan grande como la gente cree. Menciona un proyecto llamado K12 (creo que se refiere al proyecto ARM de AMD, K12, que fue cancelado) donde iban a compartir un back-end común (L2/L3, cache coherency fabric) entre dos front-ends distintos (ARM y x86), y que también lo cancelaron después de que él se fue — otra vez atribuye esto a que “los managers se asustan de cambiar cosas” y remarca con orgullo que él como arquitecto “no tiene miedo”.
La parte final es sobre el proyecto RISC-V que está armando ahora (2023, por el contexto). Cuenta el proceso de diseño: primero deciden qué van a correr arriba (Linux, programas vectoriales, programas de IA, scheduling de IA, aceleración de redes, “data prep”, aceleración de storage), y de ahí derivan decisiones de arquitectura: alto ancho de banda de fetch, unidades vectoriales grandes, cache coherency (porque van a clusterizar procesadores), L2 cache grande con posibilidad de streaming de datos sin cachearlos completamente. Usan el modelo “Whisper” de RISC-V (dice que el creador de esa herramienta trabaja para ellos) con extensiones propias, y agregaron capacidad de tracing que planean open-sourcear, con la idea explícita de que estudiantes que hacen proyectos de arquitectura pierden demasiado tiempo armando su propia infraestructura de traces en vez de experimentar con cosas como predicción de saltos (branch prediction). El spec de arquitectura que da: fetch de 8 instrucciones anchas, 64-bit, dos direccionadoras (directory units), dos load-store units, cuatro unidades de… (corta, probablemente ALUs/execution units), L1 tightly-coupled conectada a un L2 compartido. Empezaron el equipo a comienzos del año anterior, armaron primero un “baby RISC-V” chico para validar metodología, después decidieron duplicar su performance, y para fin de año ya tenían el core de tamaño mediano con RTL corriendo, un vector unit de 128 bits, y entorno de verificación funcionando, aunque todavía en construcción.
Cierra explicando “el secreto” de cómo los compiladores generan basic blocks: en promedio un basic block tiene unas 6 instrucciones (con altísima varianza, de 1 a cientos), y estos se agendan por el compilador con algo de code motion (mover instrucciones antes del salto si no dependen del resultado del branch), hasta que llega un salto condicional que rompe el flujo de control — quedó cortado ahí mismo explicando esto, probablemente para meterse con out-of-order execution y cómo el hardware explota el paralelismo entre basic blocks.
En este tramo no hay nada personal ni controvertido no técnico (nada de vacunas, parejas, política). Lo más “picante” es netamente técnico-corporativo: la crítica directa y repetida a los managers de Intel/AMD por cancelar dos proyectos (el de compartir backend x86/ARM tipo Zen, y el K12) por miedo al cambio, con la línea textual de que él como arquitecto “no tiene miedo” — es una tirada de perfil bastante clara contra la cultura gerencial de esas empresas grandes versus su propio estilo en startups (Tesla, y ahora esta empresa nueva de RISC-V/AI, que da a entender es Tenstorrent aunque no la nombra en este fragmento).
Dale, esta parte es la más jugosa técnicamente — se mete de lleno en out-of-order execution, seguridad/exploits de iPhone, la movida de RISC-V, y cierra con una observación filosófica fuerte sobre software 1.0 vs 2.0 y su relación (medio de outsider) con el mundo de la IA. Va el resumen.
Sigue con la explicación de out-of-order execution que había cortado antes: el punto es que el software asume ciertas dependencias entre instrucciones, y muchas de esas dependencias “asumidas” en realidad se rompen o se predicen — específicamente el branch flow (hacia dónde salta un salto condicional) y los load-store mispredicts (si un load depende de un store anterior o no). Cuenta la evolución histórica bien concreta: primero máquinas single-issue in-order, después two-wide, luego el compilador tuvo que empezar a ayudar activamente porque a partir de tres-wide ya no se pueden emparejar instrucciones fácil solo con hardware, y ahí aparece toda una era de investigación en tecnología de compiladores para exponer paralelismo (VLIW-style scheduling, básicamente, aunque no usa ese término). Con máquinas four-wide out-of-order la ventana de instrucciones en vuelo eran unas 20 instrucciones (3-4 basic blocks), lo cual ya daba overlap real entre bloques básicos. Explica la técnica de “fill the window”: si agrandás la ventana a 600 instrucciones (unos 100 basic blocks), no podés permitirte fallar en la predicción de esos 100 branches intermedios, porque cada misprediction te obliga a flushear todo lo que ejecutaste especulativamente — aunque menciona que hay trucos para no perder ese trabajo (guardar resultados de caminos especulativos por si el programa vuelve a pasar por ahí). Da un dato numérico concreto: sus predictores de rama actuales tienen un historial de unos 5000 (bits/entradas) y logran algo así como 1 error cada 1000 branches, lo cual cambia el trade-off de cuánto conviene agrandar la ventana de ejecución.
Como arquitecto, dice, tenés que mirar across applications: para server workloads te conviene ir a instruction windows más chicas (menciona “six” sin terminar de aclarar unidad), pero para HPC y AI conviene meter más recursos en L1 vs L2, y esas decisions siempre terminan siendo gráficos de sensibilidad con zonas lineales y luego un plateau (rendimientos decrecientes) — el trabajo del arquitecto es encontrar el codo de esa curva, y ahí es donde arquitectos e implementadores “forcejean” sobre qué vale la pena pagar en área/costo. Un detalle técnico interesante: dice que abandonaron el truco clásico de dimensionar el data cache L1 según los bits de índice virtual/físico (por ejemplo 32KB con 8-way para que quepa en una página de 4KB sin necesitar traducción), y en cambio predicen esos bits directamente y cachean la predicción — y tira una cifra llamativa: hay unos 15 predictores distintos en la máquina (stride streams, alineación, branches, calls/returns, decode alignment, load-store ordering, L1/L2 fetch, etc.).
Sobre seguridad, hace un comentario fuerte y directo: dice que la mayoría de superficies de ataque no están en el procesador en sí sino en la “lógica de control rara” — JTAG combinado con power manager, con frequency scaling, con sincronizadores. Cuenta que trabajó en algunos “security incidents” y compara los exploits con encontrar una grieta que se alinea con otra grieta: no importa cuán complicado sea el sistema, si podés armar un script que atraviese esa alineación de grietas, entrás. Menciona un exploit de iPhone específico basado en poner código arbitrario en el stack y hacer saltar la ejecución ahí, y dice que se arregló trivialmente marcando el stack como no-ejecutable (NX bit, básicamente), aunque reconoce que el exploit original era “amazing” técnicamente.
Después viene el elogio a RISC-V: menciona a David (Patterson, se entiende por contexto) y “Krista” (probablemente Krste Asanović) y a estudiantes de Berkeley que hicieron el Rocket Core y el BOOM core, escritos en Chisel (lenguaje de descripción de hardware de más alto nivel que Verilog/paralog). Cuenta que los bajaron, los corrieron, los sometieron a verificación profesional, y encontraron solo un par de bugs — elogio directo a la calidad de ese trabajo académico. Nombra empresas/proyectos RISC-V actuales: SiFive, Ventana, y “Tenstorrent” (dice “ten star”, clara transcripción errónea) que están abriendo oficina, con un llamado abierto a sumarse. Cuenta la razón concreta por la que terminaron en RISC-V para su chip de IA: quisieron licenciar un procesador con floating point, x86 no era opción porque no licencia, ARM directamente dijo que no porque no quieren diverger su arquitectura, y RISC-V (a través de SiFive) sí aceptó meter sus cambios en el próximo release. Su conclusión: “la innovación pasa cuando tenés un problema, lo podés resolver, y seguís” — y predice que RISC-V va a acelerar y expandirse.
Sobre la microarquitectura del núcleo que están construyendo: la filosofía es interfaces bien definidas bloque por bloque (fetch, decoder, renamer, scheduler, execution), cada bloque funcionando casi como “una computadora en sí misma” con su propia interfaz de instrucciones, de memoria, de “kill” (para flushear instrucciones) y de sincronización — todo pensado para que verificación pueda testear interfaces aisladas y reusarlas en otros diseños. El pipeline que mencionan es de 14 ciclos (con algún ciclo extra reservado para expansión futura). Da un ejemplo de latencia real: una instrucción puede quedar colgada 500 ciclos esperando un dato de memoria aunque no tenga ninguna dependencia real —simplemente cayó en un camino especulativo tras un branch bien predicho y quedó ahí esperando.
Metiéndose en historia de Moore’s Law otra vez, menciona el EV6 (Alpha 21264), que diseñó en 1995: out-of-order de 4-wide, 300mm², proceso de 0.35 micrones, 200 personas, tres años. Cuenta la anécdota del K8 de AMD (arquitectura Hammer/HyperTransport): cuando propuso poner 4 procesadores en un solo die la reacción de la industria fue “es una locura, nadie quiere multi-core, consume demasiada potencia, los transistores son caros, mejor un solo core grande y rápido” — y contrapone eso con hoy, donde hablan de meter de 1 a 64 cores en un chip de un milímetro cuadrado.
El cierre es la parte más filosófica y quizás la más interesante para “aprender del genio”: habla de por qué la IA recién ahora está despegando, mencionando específicamente autograd, e Inception y ResNet como hitos de arquitectura de redes, y AlexNet como el paper “famoso” que arrancó todo en visión por computadora — pero el punto central es que el volumen de transistores necesario para esto es intenso, y antes simplemente no existía el hardware. Después tira una distinción que repite como si fuera su propia formulación (aunque el crédito es ambiguo — la asocia con Andrej Karpathy sin nombrarlo del todo claro, dice “andre” y “raised 200 million dollars”, con tono de chiste): Software 1.0 es el paradigma clásico de 40-50 años, programas declarativos escritos por humanos; Software 2.0 es entrenar una red con datos, donde no hay ninguna sentencia declarativa y “el código” son los pesos, escrito en un lenguaje “no amigable para humanos”. Hace la broma de que “nadie escribe este código” pero resulta que la misma persona que dice eso (“Andre”) programa 10 horas por día — su punto irónico es que aunque el modelo en sí (los pesos) no lo escribe nadie, todo el andamiaje de entrenamiento, testing, optimización de convergencia sigue siendo código clásico escrito a mano, y de hecho las redes neuronales “reales” (CNNs) son apenas cientos de líneas.
Termina con una confesión honesta y con humor autocrítico: dice que él es un arquitecto de computadoras, no un arquitecto de IA, que lee un par de papers de IA por semana, y que al ver las fórmulas matemáticas de los papers admite abiertamente “no sé qué significa esto, ni esto, ni esto” — pero que en su rol de arquitecto lo único que le importa es que todo eso, al final, se reduce a operaciones que la máquina ejecuta: multiply-add (a = b×c + d), suma, resta, multiplicación, división, y algunas operaciones aceleradas especiales como 1/x, 1/√x, max, clamp. Menciona como problema técnico real el manejo de errores de acumulación en floating point cuando sumás decenas de miles de números (relevante para entender por qué formatos como bfloat16 o el manejo de precisión en AI accelerators es un tema no trivial) — ahí corta la transcripción.
No hay contenido personal controvertido (parejas, vacunas, etc.) en este tramo tampoco — sigue siendo 100% técnico. Lo más cercano a “controvertido” es, de nuevo, la crítica a la cultura corporativa: la anécdota de que toda la industria (implícitamente Intel/AMD de la época) se rió de la idea de multi-core cuando propuso el K8, y el comentario de que la mayoría de los agujeros de seguridad reales no están en el core del procesador sino en la periferia de control (JTAG, power management) — una crítica indirecta a dónde las empresas ponen (o no ponen) el foco de auditoría de seguridad.
Che, esta parte tiene dos cosas distintas: termina la charla de Jim Keller (con Q&A técnico largo sobre el diseño del AI chip) y después arranca directamente la de George Hotz sobre tinygrad — que es un cambio de orador, así que lo separo bien.
Sigue Jim Keller — arquitectura del AI chip y NoC
Retoma la arquitectura genérica de su chip de IA: hay un NoC (network-on-chip) que conecta los procesadores, y le da crédito directo a Bill Dally (hoy chief scientist de NVIDIA) por su trabajo académico sobre redes non-blocking, que según dice usaron como base abierta para su propio NoC. Explica el diseño de memoria local: cada procesador de IA tiene una SRAM local dimensionada para un “sweet spot” de eficiencia energética — ni tan grande que desperdicie potencia estática, ni tan chica que obligue a mover datos constantemente entre chips (mover datos cuesta más energía que computar, básicamente la ley de que el costo energético escala con la distancia/tamaño del array). También habla de balancear el pipeline entre multiplicadores grandes y chicos para poder escalar el cómputo de forma flexible, contrastando con el enfoque de la TPU de Google que tiene básicamente dos multiplicadores gigantes.
Da specs concretas de su hardware: la segunda generación del SoC tiene 1600 puertos de Ethernet gigabit, con la idea de que un procesador puede mandar un paquete de datos de IA directamente encapsulado como paquete de red a otro chip sin necesidad de drivers ni fabric adicional — así escalan a muchos chips sin cuellos de botella. Menciona que van hacia una próxima generación de 6mm con 250 procesadores de IA (subiendo de ~100), y que la primera generación licenció el core RISC-V de SiFive (in-order, dual-issue, con unidades vectoriales). Da el dato del datacenter que construyeron: un colo de 1 megawatt, ~100 servidores, 2000 chips, con next-gen en formato de 4U con 32 chips interconectados por su propio backplane, escalando a una máquina de 1000 procesadores en array de 32x32.
Sobre el rol de IA generando código: cuenta que probaron GitHub Copilot/Codex para escribir testbenches y quedaron sorprendidos de lo bien que funcionó, y especula que el software escrito por humanos es inherentemente una “narrativa serial” (retomando la idea del inicio de su charla) mientras que el código que va a escribir la IA en el futuro va a ser masivamente paralelo por diseño, porque la IA “piensa” en relaciones all-to-all en vez de secuencialmente — predice una mejora de 10x en el diseño de arquitecturas en los próximos 5-10 años generadas por IA. Da un benchmark personal: dice que un procesador comercial típico hoy sostiene 3-5% de utilización efectiva del pico teórico de FLOPs, que su equipo llegó a sostener 12 instrucciones por ciclo, y que su meta es llegar a 100 — muy lejos del “0.1” con el que arrancaron.
En el Q&A técnico final (bien denso, para alguien que quiere aprender del tipo) hay varios puntos fuertes:
Cambia el orador — arranca George Hotz (tinygrad)
Acá el documento salta a otra charla (marcada explícitamente “this is from Jim Keller on your podcast” citado por Hotz, o sea Hotz está recordando/citando algo que Keller dijo en su propio podcast). Hotz cuenta que cuando empezó a pensar en construir un chip propio (el contexto es tinybox/tinygrad, su proyecto), sus primeras ideas sobre cómo mejorar sobre las GPUs estaban “completamente equivocadas”, y que la reformulación que más le gustó fue una que le explicó Keller.
La idea central que atribuye a Keller: hay tres paradigmas de cómputo en el mundo. Los CPUs pueden hacer todo — add, multiply, load, store, y lo único que es exclusivo de CPU es compare-and-branch, y lo hacen rápido gracias a branch prediction y ejecución especulativa con reorder buffers gigantes. Las GPUs no pueden hacer compare-and-branch bien (lo hacen espantosamente lento), pero sí pueden hacer loads y stores arbitrarios (direccionamiento indirecto dependiente de datos, tipo “x = dereference(y)”). Los DSPs son el tercer paradigma: solo hacen add y multiply, con loads y stores exclusivamente estáticos (conocidos en tiempo de compilación, sin indirección dependiente de datos) — y el punto fuerte de Hotz es que el 95% de las redes neuronales de hoy caen exactamente en el paradigma DSP: son sumas y multiplicaciones estáticamente programadas.
De ahí surge la tesis central de tinygrad, según explica Hotz: cada capa del stack de software tradicional tiene Turing-completeness (Python, C++, CUDA kernels, LLVM, PTX, SASS, todo turing-complete sobre un procesador turing-complete), y su objetivo declarado es sacar la turing-completeness de todo el stack, porque una vez que eliminás eso podés razonar formalmente sobre el sistema: el teorema de Rice y el halting problem dejan de aplicar a lo que llama “Admiral machines” (probablemente “a-turing-complete machines”, mal transcripto). Conecta esto directamente con branch prediction en CPUs: dice que los predictores de rama modernos aciertan ~99% y fallan justamente ese 1% porque predecir si un branch se toma o no es equivalente al halting problem — es formalmente indecidible en el caso general — mientras que una red neuronal ejecuta el mismo cómputo idéntico cada vez, solo cambian los datos, así que en teoría se puede predecir el tiempo de ejecución con certeza total.
Un dato técnico distintivo de tinygrad que resalta con orgullo: no tiene ningún operador primitivo, ni siquiera para matrix multiply (a diferencia de literalmente todas las demás librerías de deep learning, que sí tienen primitivas para cosas como convoluciones). Explica con una metáfora geométrica (un cubo, las dos matrices en dos caras) que una multiplicación de matrices se puede descomponer en operaciones de shape (permute, expand) más una multiplicación elemento a elemento N³ más una reducción (suma) N³ que da la matriz resultante N². Con esa filosofía minimalista, tinygrad logra expresar todo con del orden de 20 operaciones primitivas (dice “order of magnitude 25”), contra ~2000 kernels distintos de PyTorch clásico, o 250 primitivas de PrimTorch (introducido en PyTorch 2.0) — o sea un orden de magnitud menos que XLA o PrimTorch. Usa la analogía RISC vs CISC explícitamente: tinygrad es RISC, las otras son CISC.
Cierra con un chiste cultural: cita la línea de la película Hackers (1995) donde Angelina Jolie dice “risk architecture is going to change everything”, y remata con humor que esa predicción de ciencia ficción noventera terminó siendo literalmente cierta con ARM (arquitectura RISC) dominando los teléfonos hoy.
Sobre lo controvertido en este tramo: nada personal (parejas, vacunas, política) todavía. Lo más fuerte “intelectualmente polémico” es la tesis de Hotz de que casi toda la industria de deep learning está construida sobre una capa de abstracción (turing-completeness en cada nivel del stack) que él considera innecesaria y hasta contraproducente para el caso de uso real de las redes neuronales — es una crítica de fondo a cómo CUDA/PyTorch/XLA están diseñados, no un detalle menor, viniendo de alguien compitiendo directamente contra ese stack.