From a5bcf4fd3ecf759259903fe3a5b93a8f9228f682 Mon Sep 17 00:00:00 2001 From: Sergio Date: Mon, 7 Sep 2026 20:43:49 +0000 Subject: [PATCH] =?UTF-8?q?perfil=20PGO=20v2:=2046=20p=C3=A1ginas=20y=206,?= =?UTF-8?q?5=C3=97=20m=C3=A1s=20ejecuciones=20registradas?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit El corpus se amplió por una MEDICIÓN, no por corazonada. Con las 36 de Mozilla la ganancia era -9,4% en DOM/maquetación y -1,0% en 3d-raytrace, y la razón es que un benchmark JIT-bound es casi ciego al PGO: el bucle caliente lo ejecuta código que el JIT emite en runtime, y el PGO optimiza el intérprete, el GC y el propio JIT, no lo que el JIT produce. El corpus de Mozilla está dominado en número de páginas por SunSpider, o sea que entrenaba justo donde menos rinde. Con las 10 de scripts/pgo-corpus/ sumadas, el efecto se ve EN EL PROPIO PERFIL: ejecuciones registradas 5.885.254.799 -> 38.498.366.335 (6,5x) máximo por función 416.219.136 -> 1.552.416.768 (3,7x) Funciones y bloques totales no cambian (501.521 / 3.734.991) porque son la estructura estática del binario instrumentado, no lo que se ejecutó. Blob nuevo publicado y verificado bajándolo del mirror por el mismo camino que usa hammer: 17.525.708 bytes, sha256 95472411. --- recipes/firefox-pgo-profile.toml | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/recipes/firefox-pgo-profile.toml b/recipes/firefox-pgo-profile.toml index 28218e9b..2459cdbd 100644 --- a/recipes/firefox-pgo-profile.toml +++ b/recipes/firefox-pgo-profile.toml @@ -1,9 +1,19 @@ # firefox-pgo-profile — el perfil de ejecución que optimiza a firefox. UNA MEDICIÓN CONGELADA. # # ══ QUÉ ES ═════════════════════════════════════════════════════════════════════════════════════ -# `merged.profdata`: 501.521 funciones, 3.734.991 bloques y 5.885.254.799 ejecuciones registradas, -# recogidas corriendo el `firefox-instrumentado` sobre el corpus de entrenamiento de Mozilla -# (`build/pgo`: las 4 páginas de maquetación de blueprint y los benchmarks JS de js-input/sunspider). +# `merged.profdata`: 501.521 funciones, 3.734.991 bloques y **38.498.366.335 ejecuciones** +# registradas sobre un corpus de **46 páginas**: las 36 de Mozilla (`build/pgo`) MÁS las 10 de +# maquetación propias de `scripts/pgo-corpus/`. +# +# ⚠ EL CORPUS SE AMPLIÓ POR UNA MEDICIÓN, NO POR CORAZONADA. Con sólo las 36 de Mozilla la ganancia +# medida fue **−9,4 %** en una página de DOM/maquetación y **−1,0 %** en `3d-raytrace`. La razón es +# que un benchmark JIT-bound es casi CIEGO al PGO —el bucle caliente lo ejecuta código que el JIT +# emite en runtime, y el PGO optimiza el intérprete, el GC y el propio JIT, no lo que el JIT +# produce—, y el corpus de Mozilla está dominado en número de páginas por SunSpider. O sea que +# entrenaba mucho justo donde el PGO menos rinde. Las 10 nuevas van al camino que sí es C++ de punta +# a punta: flexbox, grid, tablas, texto en columnas, selectores, pintado, transforms, SVG, scroll +# pegajoso y layout thrashing. Efecto medido en el propio perfil: las ejecuciones registradas pasan +# de 5.885.254.799 a 38.498.366.335 (**6,5×**). # `firefox` lo consume con `--enable-profile-use=cross`. # # ══ POR QUÉ ES UNA FUENTE PINEADA Y NO UNA RECETA QUE LO GENERA ════════════════════════════════ @@ -32,12 +42,12 @@ # aplican por nombre de función— pero vale menos: las funciones que ya no existen se ignoran y las # nuevas quedan sin datos. Regenerarlo es su propia unidad de trabajo, no un efecto secundario. name = "firefox-pgo-profile" -version = "2026.09.07" +version = "2026.09.08" license = "MPL-2.0" [source] -tarball = "https://no-hay-upstream.invalid/hammer/firefox-pgo-2026-09-07.tar.xz" -sha256 = "92edb9c56c87c0b489e61ed722d97b7fe5d6dc37ce48ffa3f3cf7523cc4d2dbf" +tarball = "https://no-hay-upstream.invalid/hammer/firefox-pgo-2026-09-08.tar.xz" +sha256 = "95472411ba252e14c4d57de7193d53e4ba35fbccf4819ba95ceff1ca843e4a7a" # ⚠ `0` Y NO EL DEFAULT. hammer recorta UN componente al extraer, porque los releases GNU vienen # con un `proyecto-version/` de más. Este tarball es nuestro y lleva el fichero en la raíz, así que # con el default se recortaba lo único que hay y el install moría en `cp: cannot stat