From acccbc0a2cde85f7124a9cd27d64d6e6fdf04afa Mon Sep 17 00:00:00 2001 From: Sergio Date: Mon, 7 Sep 2026 16:20:20 +0000 Subject: [PATCH] =?UTF-8?q?SDD=2026:=20la=20ganancia=20del=20PGO,=20medida?= =?UTF-8?q?=20=E2=80=94=20y=20sale=20al=20rev=C3=A9s=20de=20lo=20esperable?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit DOM+layout+strings, FUERA del corpus: 23.540 -> 21.327 ms -9,4% SunSpider 3d-raytrace, DENTRO: 16.034 -> 15.878 ms -1,0% Mismo rootfs, mismo script, corridas intercaladas A/B/A/B, mediana de 7, calentamiento descartado; lo único que cambia entre variantes es un --ro-bind de /usr/lib/firefox. Los rangos no se solapan en ninguna de las dos, así que ambas diferencias son reales y no ruido. Yo esperaba lo contrario: que medir sobre el conjunto de ENTRENAMIENTO inflara la ganancia. Da el número MÁS BAJO, y la razón es mejor que la predicción: 3d-raytrace es aritmética pura en un bucle caliente, y ese bucle no lo ejecuta el C++ de SpiderMonkey sino código máquina que el JIT genera en runtime. El PGO optimiza el intérprete, el GC y el propio JIT — no lo que el JIT emite. Un benchmark JIT-bound es casi ciego al PGO por construcción. Donde se ve es en DOM/layout/arranque, que es C++ de punta a punta, y que además es lo que el usuario percibe: la medición cubre el ciclo completo del proceso (arrancar, renderizar, capturar, salir), no el régimen de una página cargada. Corolario anotado: el corpus de entrenamiento está sesgado hacia JS justo donde el PGO menos rinde. Un corpus con más maquetación probablemente daría más. Es su propia unidad de trabajo. --- docs/26-atuq-envoltorio-gecko.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/docs/26-atuq-envoltorio-gecko.md b/docs/26-atuq-envoltorio-gecko.md index 3400f484..7f373a21 100644 --- a/docs/26-atuq-envoltorio-gecko.md +++ b/docs/26-atuq-envoltorio-gecko.md @@ -227,6 +227,34 @@ llevan `-fprofile-use`**, el configure encontró `llvm-profdata`, y no hay ni un no cuadre. `libxul.so` pasa de 226.078.752 a 227.802.816 bytes, consistente con inlining de caminos calientes. Es evidencia de build, no de artefacto, y conviene decirlo así. +**LA GANANCIA, MEDIDA (2026-09-07).** Mismo rootfs, mismo script, corridas INTERCALADAS A/B/A/B +para que la deriva de carga afecte a las dos, mediana de 7, calentamiento descartado. Lo único que +cambia entre variantes es un `--ro-bind` de `/usr/lib/firefox`. + +| página | sin PGO | con PGO | | +|---|---|---|---| +| DOM+layout+strings, **fuera** del corpus de entrenamiento | 23.540 ms | 21.327 ms | **−9,4 %** | +| SunSpider `3d-raytrace`, **dentro** del corpus | 16.034 ms | 15.878 ms | −1,0 % | + +Los rangos no se solapan en ninguna de las dos (23.185–23.654 vs 21.030–21.650), así que las dos +diferencias son reales y no ruido. + +⚠ **Y el resultado sale al revés de lo esperable, que es lo interesante.** La intuición dice que +medir sobre el conjunto de ENTRENAMIENTO infla la ganancia; acá el corpus da el número MÁS BAJO. La +razón es que `3d-raytrace` es aritmética pura en un bucle caliente, y ese bucle **no lo ejecuta el +C++ de SpiderMonkey: lo ejecuta código máquina que el JIT genera en tiempo de ejecución**. El PGO +optimiza el intérprete, el GC y el propio compilador JIT — no el código que el JIT emite. Un +benchmark JIT-bound es casi ciego al PGO por construcción. + +Donde sí se ve es en el camino DOM/layout/arranque, que es C++ de principio a fin. Y eso es también +lo que un usuario percibe: la medición cubre el ciclo COMPLETO del proceso (arrancar → renderizar → +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. + **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 riesgo real de esta unidad, no el rendimiento: si el `-fprofile-use` hubiera metido cualquier