github-starred/cs249r_book
2
0
Fork 0
mirror of https://github.com/harvard-edge/cs249r_book.git synced 2026-07-15 21:28:33 -05:00
Code Issues 276 Packages Projects Releases 26 Wiki Activity

[PR #1955] [MERGED] fix(tinytorch): capstone latency divisions crash on coarse timer resolution #34679

New Issue
Closed
opened 2026-07-14 19:28:50 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-07-14 19:28:50 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/harvard-edge/cs249r_book/pull/1955
Author: @Shashank-Tripathi-07
Created: 7/7/2026
Status: ✅ Merged
Merged: 7/10/2026
Merged by: @profvjreddi

Base: dev ← Head: fix/capstone-latency-zero-division

📝 Commits (1)

  • 49033c7 fix(tinytorch): capstone latency divisions crash on coarse timer resolution

📊 Changes

1 file changed (+8 additions, -2 deletions)

View changed files

📝 tinytorch/src/20_capstone/20_capstone.py (+8 -2)

📄 Description

Summary

  • benchmark_model()'s throughput_samples_per_sec (float(1000 / avg_latency)) and generate_submission()'s speedup (float(baseline_latency / optimized_latency)) both divide by a latency measured with time.time() around a single tiny forward pass, with no zero-guard.
  • time.time() has coarse resolution on Windows (commonly ~15.6ms). For a small model, a fast forward pass can legitimately measure 0.0 elapsed time across all runs, making avg_latency (and therefore optimized_latency downstream in a submission comparison) exactly 0.0 and raising ZeroDivisionError.

Fix

An existing test asserts throughput_samples_per_sec > 0, and another asserts speedup > 0, so the fix floors each denominator at a small epsilon (1e-6) rather than returning 0.0 or None -- both of which would fail those assertions and would also misrepresent an immeasurably-fast result as zero throughput.

Test plan

  • Reproduced ZeroDivisionError for both avg_latency=0.0 and optimized_latency=0.0 with the old expressions.
  • Confirmed the floored versions return large-but-finite positive numbers instead (no crash).
  • Confirmed normal (non-zero) latency values are unaffected (e.g. avg_latency=2.0ms -> 500.0 samples/sec, unchanged from before).
  • python -m py_compile passes on the edited file.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/harvard-edge/cs249r_book/pull/1955 **Author:** [@Shashank-Tripathi-07](https://github.com/Shashank-Tripathi-07) **Created:** 7/7/2026 **Status:** ✅ Merged **Merged:** 7/10/2026 **Merged by:** [@profvjreddi](https://github.com/profvjreddi) **Base:** `dev` ← **Head:** `fix/capstone-latency-zero-division` --- ### 📝 Commits (1) - [`49033c7`](https://github.com/harvard-edge/cs249r_book/commit/49033c73f43fd4a8be0bd9d88fb84e6f2f277416) fix(tinytorch): capstone latency divisions crash on coarse timer resolution ### 📊 Changes **1 file changed** (+8 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `tinytorch/src/20_capstone/20_capstone.py` (+8 -2) </details> ### 📄 Description ## Summary - `benchmark_model()`'s `throughput_samples_per_sec` (`float(1000 / avg_latency)`) and `generate_submission()`'s `speedup` (`float(baseline_latency / optimized_latency)`) both divide by a latency measured with `time.time()` around a single tiny forward pass, with no zero-guard. - `time.time()` has coarse resolution on Windows (commonly ~15.6ms). For a small model, a fast forward pass can legitimately measure `0.0` elapsed time across all runs, making `avg_latency` (and therefore `optimized_latency` downstream in a submission comparison) exactly `0.0` and raising `ZeroDivisionError`. ## Fix An existing test asserts `throughput_samples_per_sec > 0`, and another asserts `speedup > 0`, so the fix floors each denominator at a small epsilon (`1e-6`) rather than returning `0.0` or `None` -- both of which would fail those assertions and would also misrepresent an immeasurably-fast result as zero throughput. ## Test plan - [x] Reproduced `ZeroDivisionError` for both `avg_latency=0.0` and `optimized_latency=0.0` with the old expressions. - [x] Confirmed the floored versions return large-but-finite positive numbers instead (no crash). - [x] Confirmed normal (non-zero) latency values are unaffected (e.g. `avg_latency=2.0ms -> 500.0` samples/sec, unchanged from before). - [x] `python -m py_compile` passes on the edited file. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-07-14 19:28:50 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area: book
area: collabs
area: kits
area: labs
area: socratiq
area: staffml
area: tinytorch
area: tools
area: website
bug
dependencies
format: epub
format: pdf
javascript
link-health
link-rot
priority-high
pull-request
Mirrored from GitHub Pull Request
 staffml
type: bug
type: citation
type: code
type: errata
type: improvement
type: new
type: question
vault-sli
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/cs249r_book#34679
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?