From 6b469a81d2df36d069b67f6528234dc373f16816 Mon Sep 17 00:00:00 2001 From: Sergio Date: Mon, 7 Sep 2026 21:52:39 +0000 Subject: [PATCH] =?UTF-8?q?SDD=2026:=20el=20corpus=20ampliado=20rinde=20?= =?UTF-8?q?=E2=80=94=20de=20-9,6%=20a=20-11,4%=20en=20maquetaci=C3=B3n?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit sin PGO v1 (36 pág) v2 (46 pág) DOM/maquetación 23.285 ms 21.050 (-9,6%) 20.640 (-11,4%) SunSpider 3d-raytrace 16.003 ms 15.846 (-1,0%) 15.857 (-0,9%) La mejora en maquetación NO se afirma por las medianas sino por la separación: SEIS de las siete muestras de v1 son más lentas que TODAS las de v2; sólo una cae dentro del rango de v2. En SunSpider v1 y v2 son INDISTINGUIBLES —los valores se entrelazan por completo—, que es exactamente lo esperable: ese camino lo ejecuta el JIT y el PGO no lo toca. Un corpus mejor no puede mejorar lo que el PGO no alcanza. El -0,9% frente al -1,0% no dice que v2 sea peor ahí: dice que no se distingue. Una de las siete corridas de v2 dio 120.029 ms contra ~20.600 de las otras seis. La mediana lo ignora por diseño; una media lo habría convertido en «v2 es catastróficamente peor». Fue la razón de elegir mediana antes de ver un número. Y lo que el banco no puede afirmar, escrito: las 10 páginas nuevas ejercitan los mismos subsistemas que la página de medición, así que el parentesco con lo que ahora se entrena es mayor que antes. El -11,4% es real para ESTA carga; generalizarlo a «cualquier página» sería el mismo error que cometía el corpus de Mozilla, en la otra dirección. --- docs/26-atuq-envoltorio-gecko.md | 28 +++++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/docs/26-atuq-envoltorio-gecko.md b/docs/26-atuq-envoltorio-gecko.md index 8138c0fb..965af1c7 100644 --- a/docs/26-atuq-envoltorio-gecko.md +++ b/docs/26-atuq-envoltorio-gecko.md @@ -251,9 +251,31 @@ lo que un usuario percibe: la medición cubre el ciclo COMPLETO del proceso (arr capturar → salir), no el rendimiento en régimen de una página ya cargada. De ahí que hasta la página de SunSpider tarde 16 s: casi todo es arranque. -**Corolario para el corpus de entrenamiento:** está sesgado hacia JS (SunSpider domina en número de -páginas) justo donde el PGO menos rinde. Un corpus con más maquetación y menos aritmética -probablemente daría más ganancia. Es una unidad de trabajo propia y no se hace de paso. +**Corolario para el corpus de entrenamiento — APLICADO Y MEDIDO (2026-09-08).** El corpus estaba +sesgado hacia JS justo donde el PGO menos rinde, así que se le sumaron 10 páginas de maquetación +propias (`scripts/pgo-corpus/`): flexbox, grid, tablas con los dos algoritmos de layout, texto en +columnas, selectores contra 600 reglas, pintado, transforms, SVG, scroll pegajoso y layout +thrashing. El perfil pasó de 5.885.254.799 ejecuciones registradas a **38.498.366.335 (6,5×)**. + +| | sin PGO | PGO v1 (36 pág.) | PGO v2 (46 pág.) | +|---|---|---|---| +| DOM/maquetación, fuera del corpus | 23.285 ms | 21.050 ms (−9,6 %) | **20.640 ms (−11,4 %)** | +| SunSpider `3d-raytrace` | 16.003 ms | 15.846 ms (−1,0 %) | 15.857 ms (−0,9 %) | + +**La mejora en maquetación es real y no de medianas:** SEIS de las siete muestras de v1 son más +lentas que TODAS las de v2; sólo una cae dentro del rango de v2. En SunSpider, en cambio, v1 y v2 +son **indistinguibles** —los valores se entrelazan por completo— que es justo lo esperable: ese +camino lo ejecuta el JIT y el PGO no lo toca. Un corpus mejor no puede mejorar lo que el PGO no +alcanza. + +⚠ Una de las siete corridas de v2 dio 120.029 ms contra ~20.600 de las otras seis: un atípico +transitorio. **La mediana lo ignora por diseño**; una media lo habría convertido en «v2 es +catastróficamente peor». Fue la razón de elegir mediana antes de ver un solo número. + +⚠ Y lo que este banco NO puede afirmar: las 10 páginas nuevas ejercitan los mismos subsistemas que +la página de medición, así que el parentesco con lo que ahora se entrena es mayor que antes. El +−11,4 % es real para ESTA carga; generalizarlo a «cualquier página» sería justo el error que el +propio corpus de Mozilla cometía al revés. **Y la pregunta que un insumo no determinista obliga a hacer, respondida: `firefox` SIGUE REPRODUCIENDO bit a bit** (`verificar-repro.sh`: REPRODUCEN 1, DERIVA 0, NO-DETERMINISMO 0). Era el