Should the HTML build run on a GPU runner (RunsOn) for accurate horse-race timings?
@Smit-create ci sta già lavorando.
Dal 4/6/2026.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
@Smit-create — a question for you on infra.
Context
The final lecture, schelling_jax_parallel.md, ends with a timed "horse race" between NumPy, JAX-sequential, and JAX-parallel implementations. Its whole conclusion is that the parallel JAX algorithm wins on a GPU ("shines on GPUs", "algorithm structure matters").
The participant experience is fine: the Colab notebooks in notebooks/ are committed unexecuted (no baked-in outputs), so participants generate their own GPU timings live on Colab. ✅
The gap is only in the published website HTML:
lectures/_config.ymlusesexecute_notebooks: "cache", so code runs at build time and the printedConverged in … secondsnumbers get baked into the rendered site.- Both
ci.ymlandpublish.ymluseruns-on: ubuntu-latest— GitHub-hosted CPU, no GPU.
On CPU the parallel algorithm is expected to be the slowest (it deliberately does uniform/redundant work per agent for SIMT efficiency, and needs more iterations) — so the static site can show timing numbers that contradict the lecture's conclusion.
The question
We have a RunsOn image already defined in .github/runs-on.yml:
images:
quantecon_ubuntu2404:
platform: "linux"
arch: "x64"
ami: "ami-0edec81935264b6d3"
region: "us-west-2"
…but the workflows don't reference it — they still use ubuntu-latest.
Smit: do you want this repo's build to run on a GPU instance via RunsOn so the published HTML horse-race timings are accurate? If so:
- Is the existing
quantecon_ubuntu2404image GPU-capable, or do we need a GPU instance type + a CUDA/GPU-enabled AMI? - Which workflow(s) should move to the GPU runner — just
publish.yml(the site that gets the baked timings), orci.ymltoo? - Are the RunsOn credentials/app already enabled on
QuantEcon/scipy_tutorial_2026?
Alternatives if GPU CI isn't worth it
- Add a one-line admonition on the lecture page noting the displayed timings are from a CPU build and that Colab GPU gives representative numbers; or
- Leave as-is, since the live workshop runs on Colab GPU and the static numbers are a minor footnote.
Related: #4 (CI currently red on the Netlify preview step — separate infra issue).
- Lingua principale
- Jupyter Notebook
- Stelle
- 3
- Fork
- 0
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di QuantEcon/scipy_tutorial_2026
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
QuantEcon/scipy_tutorial_2026#6 · 1 commento ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 52/100
QuantEcon/scipy_tutorial_2026#4 · 1 commento ·