lecture-python.myst: CPU build time sits at the lecture-validation ceiling

Chiusa
  • Qualcosa non va?
#196 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
github-actions, numpy, python
Ambito
ci-cd, performance

Direzione di ricerca

Start with test-containers-lectures.yml and reproduce the CPU build for lecture-python.myst, focusing on the imp_sample, phillips_drifts_volatilities, and sargent_surico timings. Compare runner CPU information and the numba and JAX paths described in the issue; done means determining the CPU/GPU impact and agreeing on a faster implementation or an appropriate validation limit.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

discuss

To discuss: lecture-python.myst's CPU execution time, which is the second of the two causes behind the red lecture validation in #159 (diagnosis). The first cause, bayes_nonconj under numpyro 0.22.0, has its own lecture fix.

What we know

  • The limit bites often. In test-containers-lectures.yml, the lecture's HTML build takes 72–118 min on CPU, against a job limit of 120. Legs were cancelled at 120 min on 08-03, 08-10, 08-17, 08-24, 08-31, 09-07, 09-18 and 09-21. The 09-14 green run had 12–15 min to spare.
  • Three lectures dominate:
    • imp_sample takes 1,900–2,993 s, which is 35–46% of the HTML build. Its numba prange estimator was rewritten to JAX vmap with jax.random.beta in caf3ddc (2026-08-02). Locally, the old numba version runs the whole notebook in about 182 s. The JAX version was still inside one cell after 24 min.
    • phillips_drifts_volatilities takes 402–1,125 s.
    • sargent_surico, added 2026-08-01, takes 265–615 s.
  • Speed depends on the runner. Identical inputs took 71.9 min on one runner and 116.5 min on another. The runner CPU model is not yet logged.
  • Stopgap in this repo: the validation job gives lecture-python.myst a 180-min limit and records each runner's CPU (PR to follow, referencing this issue). This keeps the signal usable. It does not make the build any faster.

Questions

  1. Should imp_sample be fast on CPU again? Options: bring back the numba estimator, keep JAX but use smaller sample sizes when no GPU is present, or accept the cost.
  2. Is the lecture's own GPU build affected? The validation job runs on CPU only, so it may not show what readers' builds see.
  3. Once the lecture is faster, should the validation job's 180-min limit go back down to 120?

Related: #141 (the ceiling, first reported), #159 (the alert).

Lingua principale
Shell
Stelle
0
Fork
1
Merge medio
20h 3m
PR unite (30g)
48

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di QuantEcon/actions

Tutte le issue di QuantEcon/actions

Issue simili

Altre issue su Shell/Bash

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.