Hilos · 3 noticias en 6 días
AVX-512 llega a LLVMpipe por un merge request que un modelo terminó, y el mantenedor no tiene hardware para probarlo (16/10)
- Noticias
- 3
- Briefings
- 3
- Empieza
- Última
-
Linus Torvalds publicó una rama del kernel reescrita con Claude Code que casi triplica el throughput de lecturas chicas (12/10)
Sigue de Claude Code del lado del atacante en el caso CyberXero, ahora del lado del mantenedor más exigente que hay. La rama es noref-filemap-read-with-llm, ocho parches sobre 7.3-rc6, y ataca un cuello de botella del page cache que Matthew Wilcox había planteado en 2024: en vez de tomar una referencia sobre cada folio en cada lectura, difiere la liberación de los folios removidos hasta después de un período de gracia de RCU, con lo cual los lectores copian directo de la página al buffer del usuario. Los números, medidos en una sola laptop Core i7-8565U de 4 núcleos con mitigaciones desactivadas, son los que dan la nota: con 8 threads sobre un archivo, los ciclos por lectura bajan de unos 2.950 a unos 725 y el throughput sube de 9,9-10,4 millones a 30-33 millones de lecturas por segundo, y los load HITMs medidos con perf c2c caen de 30.538 a 101. La sección "Tools" de la carta de presentación dice que Claude Code, bajo su dirección, produjo el código, los programas de test, la revisión detrás de su lista de problemas abiertos y el primer borrador de la carta; los benchmarks los corrió él. Hay que mirar también lo que no cierra: una lectura de 16 bytes en un thread hacia una página de usuario no mapeada empeora de unos 4.150 a 6.550 ciclos, en un stress test en una VM de 2 GiB la versión de seis parches disparó el OOM killer —los dos parches finales agregan una válvula que fuerza liberaciones expeditas cuando una CPU acumula más de 1.024 páginas en cola—, y nada de esto está mergeado ni probado en máquinas multi-socket. HWBusters · kernel.org
-
AVX-512 llega a LLVMpipe por un merge request que un modelo terminó, y el mantenedor no tiene hardware para probarlo (16/10)
Sigue de la rama del page cache que Torvalds escribió con Claude Code, del briefing del 13, pero con el matiz que ahí no estaba: acá el código no se midió. El merge request draft !45279 en el GitLab de freedesktop agrega soporte de vectores de 512 bits para fragment shaders en LLVMpipe, el driver de software Gallium3D/OpenGL por CPU, lo que en teoría lo aceleraría en CPUs con AVX-512. David Airlie, ingeniero de Red Hat, había explorado AVX-512 para LLVMpipe hace años y nunca lo terminó; según él, los modelos GPT Terra y Astra cerraron los huecos finales en los últimos días y encontraron bugs en el camino. No hay un solo benchmark publicado, y la razón es concreta: Airlie no tiene hardware con AVX-512, así que no pudo probar la implementación. Está en draft, no mergeado, y el beneficio depende enteramente de que el código generado esté en orden. Phoronix
-
MeshXFS: un XFS clusterizado que escribió casi entero Claude Opus como agente autónomo, y el autor dice que no revisó el código (17/10)
Sigue de la rama de AVX-512 para LLVMpipe que terminó un modelo, del briefing de ayer, pero acá la escala es otra: no un hueco final sino un driver de filesystem de kernel completo. MeshXFS es un filesystem clusterizado POSIX con licencia GPL-2.0, construido sobre el código upstream de XFS, que permite que varias máquinas monten el mismo filesystem en lectura-escritura al mismo tiempo, con locking distribuido, coherencia de caché entre nodos, fencing y recuperación de journal liderada por el sobreviviente. Steve Shoecraft, que arrancó el proyecto, lo plantea como un experimento sobre si la IA puede escribir un driver de filesystem no trivial: dice que Claude Opus, corriendo como agente autónomo en Claude Code, escribió la mayor parte de la capa de clustering, el envoltorio en disco, las herramientas de userspace y los harnesses de prueba, consultando a Claude Fable, GPT y Gemini en los problemas difíciles, y que él fijó los objetivos pero no escribió, editó ni revisó el código. El árbol de XFS pasó de unas 226.000 a 314.000 líneas, y cada release pasa por una suite de unas 30 filas sobre clusters multinodo reales. No hay un solo benchmark publicado: el objetivo declarado es quedar dentro del doble del tiempo de XFS nativo sobre el mismo almacenamiento, y como nadie revisó el código, toda la confianza descansa en esa suite de tests. Phoronix · GitHub
El hilo se arma solo en cada build: junta noticias de días distintos que nombran a la misma entidad y repiten vocabulario que casi no aparece en el resto del archivo. Nadie lo edita a mano, así que puede dejar afuera una noticia o sumar una de al lado.