Thomas Neumann desmonta el truco de GenDB-V: 22× más rápido solo porque conoce el generador de datos
Next-Level Benchmarking Overfitting – Thomas Neumann
Neumann analiza las espectaculares aceleraciones de GenDB-V sobre Umbra y DuckDB y concluye que no son reales: los agentes de IA precalculan estructuras por consulta y, en el modo «plain-array», codifican a mano dónde coloca dbgen cada fila, de modo que el join de Q18 sale casi gratis. La verificación formal solo comprueba la corrección, no la validez del rendimiento. Su conclusión: dejar que los agentes optimicen contra un benchmark concreto lo vuelve inútil.
Dejar que los agentes de IA optimicen para un benchmark de base de datos concreto hace que el benchmark sea inútil. Harán todo lo posible por encontrar trucos absurdos para acelerar ese benchmark en particular, pero nada de eso funcionaría en un sistema real.
- lmeyerov
Llevamos tiempo construyendo GFQL para cypher vectorizado en CPU/GPU de código abierto sobre dataframes (piensa en duckdb para grafos, sin necesidad de DB) usando asistencia agéntica... y nuestra idea es que esto es un peldaño hacia algo aún más agresivo.
Hoy en día, abrazamos la optimización de especializaciones de hotpath para algunos patrones que antes habrían sido demasiado caros de mantener. Los LLMs mantienen ese coste soportable, y poder hacer eso para usuarios importantes (como los usuarios de nuestro producto de analista Graphistry) es un superpoder. Nuestras puntuaciones en los benchmarks de la comunidad de grafos están superando a los grandes - y, lo que es más importante, en todo lo que nos importa.
Donde realmente queremos que eso llegue es a la especialización en runtime / loadtime. Nuestros clientes querrían sin duda que sus consultas principales se autotunen. La investigación en DB ya se está inclinando fuertemente hacia aquí, de forma análoga a la investigación en compiladores de hace una década. Soy bastante optimista sobre lo que ahora es posible.
- augment_me
Ha habido un problema similar en la comunidad de desarrollo de kernels de GPU.
Se resolvió entendiendo que el valor que aportan los benchmarks depende de tu caso de uso. Parece que el autor del artículo está increpando al benchmark desde su propia idea de lo que debería ser una búsqueda en una DB (fiable, general), y no desde lo que el benchmark está midiendo.
Si solo quieres el kernel más rápido para un puñado de formas, deja que la gente escriba código frágil pero rápido.
Si te interesan soluciones generales y amplias, haz un benchmark de 50 entradas diferentes, limita el tamaño del código para impedir ramas en ensamblador para cada posible entrada.
Incluye requisitos como equivalencia bit a bit u otros límites de la tarea final.
Ten datasets públicos y privados.
Creo que es más bien una prueba de que deberíamos dedicar más tiempo a pensar qué queremos de estas cosas y por qué, y a diseñar benchmarks que reflejen eso en lugar de seguir con la vieja forma de hacer las cosas.
- qsort
El autor tiene razón al señalar que esto es una continuación y amplificación de una tendencia existente.
Estoy en el mundo de los datos librando la buena batalla, difundiendo el evangelio de Simplemente Usar Postgres, y veo cada vez más benchmarks que parecen sumamente dudosos. El rendimiento de las consultas es como elegir una estructura de datos en la programación ordinaria: depende casi por completo del patrón de acceso que esperes en runtime; no tiene ningún sentido buscar la lista enlazada más rápida del mundo si lo que necesitabas era una tabla hash. Compáralo con la situación en el panorama moderno de la ingeniería de datos. ¿Estás seguro de que la solución medida por el benchmark es realmente una solución a tu problema, y mucho menos una mejora significativa frente a Simplemente Usar Postgres? ¿Lo has medido o te basas en marketing y vibraciones?
De nuevo, estoy seguro de que soluciones como esta tienen su lugar, pero al menos ahora mismo no es el mismo lugar que los motores tradicionales.