El software ya no tiene excusa para ser lento

He estado trabajando en un proyecto de regex similar, diseñado de forma agéntica, llamado SafeRE:

https://github.com/eaftan/safere

https://eaftan.github.io/safere-intro/

El mío es para Java y está pensado para ser de grado de producción. El primer objetivo es garantizar un comportamiento de tiempo lineal para prevenir ataques ReDoS. Mi colaborador y yo hemos estado optimizándolo recientemente para intentar superar el rendimiento del RE2 nativo.

Resulta que las optimizaciones son increíblemente adecuadas para un bucle agéntico. Tienes criterios de aceptación concretos (debe mostrar una mejora significativa en un caso de referencia, debe pasar las pruebas). El agente es realmente, realmente bueno usando herramientas como un perfilador y un desensamblador, mejor que yo (y yo llevo 20 años haciendo esto). También cubre cosas que me llevarían tiempo aprender, como cómo funciona la API Vector (SIMD) en incubación en Java. Entiendo el concepto, pero me llevaría tiempo entender la implementación de Java. El agente puede simplemente leer la documentación y ponerse a trabajar.

La clave es crear un buen conjunto de pruebas de referencia y asegurarse de que el agente no envíe optimizaciones demasiado estrechas o demasiado centradas en los casos de referencia. También necesitas un conjunto de pruebas muy sólido para asegurarte de que no estás regresando en corrección. SafeRE tiene miles de millones de pruebas; un subconjunto de varios millones se ejecuta en CI, y las demás se ejecutan bajo demanda.

Aquí está esto resumido:

> Un proceso de búsqueda estocástica con un objetivo de optimización ejecutable sobre el espacio de programas S solo puede mantener o mejorar el objetivo

Esto es superoptimización. Lo sabemos desde los años 80 (Massalin, STOKE es más reciente: https://github.com/StanfordPL/stoke). La única novedad es que el proponente ahora es mucho mejor con los LM.

Además, hay un gran número de razones por las que el software escrito por agentes es lento:

- Los LM todavía no hacen bien el diseño orientado a datos o hardware de forma nativa y, por lo tanto, si te dedicas a cualquier trabajo serio y novedoso, más allá de portar un programa extremadamente bien entendido con cargas de trabajo extremadamente bien entendidas, vas a pasar horas rastreando malas decisiones de asignación (cf. por qué TigerBeetle no usa agentes), que a menudo son la raíz del mal (antes de que recurras a algo más).

- Los ajustes que necesitarías para obtener un rendimiento serio son casi inalcanzables en los lenguajes en los que los LM son buenos (incluso Rust requiere una disciplina que el lenguaje por defecto no impone). Cuando desciendes a los niveles inferiores, estás intercambiando contexto de consumo por acceso a estas palancas. Las palancas también son "blandas": te encuentras escribiendo un montón de habilidades y herramientas para intentar imponer la disciplina.

La realidad es que para obtener código eficiente (rápidamente) de un agente, necesitas saber cómo escribir código eficiente (y necesitas saber cómo sacar a la luz la información que usarías para crear un verificador para tal cosa a los […]

"Los LLM están causando código lento e hinchado; se van a comer sus palabras una vez que reescriban todo en ensamblador superoptimizado."

Esta persona no entiende cómo hacer código eficiente. Puedo escribir código en casi cualquier lenguaje (con un par de excepciones) que supere al "ensamblador superoptimizado". Escribir código eficiente no se trata del lenguaje, y a menudo tampoco se trata de los mejores algoritmos (pero a veces sí). Se trata de optimizar el uso de memoria y caché. Y eso es ortogonal a lo que el autor está escribiendo. Además, los LLM son terribles para optimizar la utilización de memoria. Hay muy poco código de entrenamiento que lo haga bien y demasiado que no.

Como prueba, puedo sentir literalmente que la web se vuelve más lenta y apuesto a que muchos otros también lo sienten.

ChatGPT MacOSX es el único software que se bloquea regularmente en mi máquina cuando su consumo de memoria, sin razón aparente, se dispara hacia los 50 GB.

Y ese software está construido por algunos de los ingenieros de software mejor pagados del planeta con acceso completo a todo el cómputo de LLM del mundo.

He estado usando computadoras durante 4 décadas. No se han vuelto más rápidas. El sistema informático de la planta nuclear que construimos en 1989 tenía que presentar pantallas seleccionadas en 1 segundo. No creo que ninguna aplicación que uso hoy pueda hacer eso.

Para mí, la comparación siempre ha sido 3DsMax vs Blender. El mismo tipo de software, el mismo tipo de características, pero Blender es mucho más rápido.

Las decisiones arquitectónicas siempre han sido importantes.

Ahora entiendo que la mayoría del software es lento debido a razones de co-arrendamiento que requieren controlar recursos o simplemente porque están seguramente aislados de la competencia. Por ejemplo, GitHub es lo primero: puedes tener un host de git y un sistema de CI/CD de mucha mayor calidad tú mismo, ya que probablemente no estás usando sus funciones sociales. Creo que cosas como el gesto de cinco dedos hacia adentro de Apple son lo segundo. Antes podías hacerlo y empezar a escribir, pero hoy en día necesita renderizar la animación, etc., antes de que se registren las pulsaciones de teclas. Este software es lento porque no puedes reemplazarlo en MacOS.

Pero todas estas cosas cambiarán con el tiempo. El infierno es el software de otras personas.