[numba.md] numba_ex3: run the solution at the n the exercise asks for - #601
Merged
Conversation
The statement says to use a substantial sample size such as n = 100_000_000, but the solution reused the shared 10^6 arrays --- at that size both timed cells display as 0.00 seconds, demonstrating nothing. The solution now draws its own 10^8 points (with a memory note), times the parallel version, and compares against speed_ex1's serial jitted function on the same arrays so the multithreading gain is visible on the page. The shared 10^6 arrays are unchanged: speed_ex1's pure-Python comparison would take minutes at 10^8. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the numba_ex3 solution in the Numba lecture so it actually runs the Monte Carlo simulation at the substantial sample size (n = 100_000_000) requested by the exercise, making the intended serial-vs-parallel speed comparison visible in rendered outputs.
Changes:
- Draws fresh large arrays (
u_big,v_big) atn = 100_000_000fornumba_ex3, with a memory-usage note. - Adds a timed run of the serial jitted
calculate_pion the same large inputs to show the parallelization speedup directly. - Updates surrounding prose to explain why small
ncan hide (or reverse) parallel gains.
Contributor
Author
|
The `u_big`/`v_big` pair added for numba_ex3 stayed alive for the rest of the notebook. Because `numba_ex_draw_speed` rebinds `u_draws`/`v_draws` to a second pair of 1e8-element arrays, peak memory reached ~3.2 GB rather than ~1.6 GB. That is comfortable on the g4dn.2xlarge CI runner but not on the smaller machines the accompanying memory note is written for. Delete the arrays after their last use, and fix "Lets" -> "Let's" plus the trailing whitespace introduced alongside it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The Netlify preview of 6246b07 reports 0.1448s serial against 0.0353s parallel at n=100_000_000, a 4.1x gain, but the solution claimed "around 3x on our workstation". Drop the multiple rather than restate it: these lectures re-execute every build on a shared runner, so a pinned figure drifts, and line 765 was the only hardcoded speedup in the file — the rest describes gains qualitatively and lets the printed timings carry the fact. The exercise preamble still warned "you should not expect huge gains here", which was written for the old small-n setup and now contradicts the near-linear scaling the solution demonstrates. Reframe it around giving each thread enough work, which is why the exercise asks for a large n. Prose only, so the execution cache for the code cells is unaffected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
Author
|
@jstac here is a suggested edit to close #579. Preview: https://6a7bd8835efc3a7f30eebe8b--epic-agnesi-957267.netlify.app/numba#exercises |
Contributor
|
Thanks @mmcky ! please merge when ready. |
jstac
approved these changes
Aug 12, 2026
Contributor
Author
✅ Translation sync completed (fr)Target repo: QuantEcon/lecture-python-programming.fr
|
Contributor
Author
✅ Translation sync completed (zh-cn)Target repo: QuantEcon/lecture-python-programming.zh-cn
|
This was referenced Aug 12, 2026
Contributor
Author
✅ Translation sync completed (fa)Target repo: QuantEcon/lecture-python-programming.fa
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #579.
The exercise statement says to use a substantial sample size "such as
n = 100_000_000", but the solution reused the sharedn = 1_000_000arrays. Benchmarked in thequanteconenv (numba 0.62.1): at 10⁶ the jitted kernel runs in ~0.4 ms, so both timed cells in the published solution display 0.00 seconds — the parallelization the exercise teaches is invisible. Resolution chosen by @mmcky over the two options in the issue: make the solution actually do what the statement asks.Changes
u_big/v_bigatn = 100_000_000(with a note that the arrays occupy ~1.6 GB), leaving the shared 10⁶ arrays untouched —speed_ex1's pure-Python comparison would take minutes at 10⁸, so bumping the shared setup was not an option.calculate_pi(the serial jitted function fromspeed_ex1) on the same points, so the serial-vs-parallel comparison the prose describes is actually visible in the built lecture instead of asking the reader to flipparallel=Truethemselves.Validation
Ran the exact new cell sequence (shared setup →
speed_ex1compile → new solution) locally: parallel-with-compile 0.33 s, parallel 14 ms, serial 51 ms — a 3.6× visible speedup, π ≈ 3.14156 from all calls. Memory peaks at ~1.6 GB, comfortably inside every CI runner including the 7 GB macOS host; measured CI cost is a few seconds of extra execution.🤖 Generated with Claude Code