Record the 1671st column, the first since the 1620th - #854
Merged
Conversation
The half of #167 that the benchmark itself could not supply: a column. #850 added EvalTrig and EvalTrigPrecise and stopped the allocation figure being discarded, and the Kernel Benchmark has now run on master with both, so the numbers are from a GitHub runner rather than from a contributor's machine. Trigonometry at five hundred digits is 43.3 ms against 1.3 ms at the default hundred -- thirty-two times, which is what the issue asked to be able to see. Allocation gets a table of its own rather than doubling the width of the main one. EvalEasy allocating nothing is worth reading twice: it is the proof of the caching note above it rather than a further argument for it, since evaluating that expression cannot allocate zero bytes and a dictionary lookup can. Closes #167. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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 #167 — the half the benchmark itself could not supply.
#850 added
EvalTrigandEvalTrigPreciseand stopped the allocation figure being discarded. The Kernel Benchmark has now run on master with both, so these are a GitHub runner's numbers rather than my laptop's.What the new rows say
EvalTrig(100 digits, the default)EvalTrigPrecise(500 digits)Thirty-two times the cost for five times the digits, which is what @Happypig375's "add as many benchmarks as needed" was for — the issue's premise now has a row that will show it moving.
Allocation gets its own table
Rather than doubling the width of the main one, which is already fifteen columns. One column for now, because this is the first version measured for it.
EvalEasyallocating nothing is the proof of the caching note, not a further argument for it. Evaluating1 + 2 + log(2, 3) + sqrt(4) - 4 ^ 7 + e * picannot allocate zero bytes. A dictionary lookup can. The timing said 2 ns and I argued from it; the allocation figure settles it.RunEasy,RunMediumandRunHardalso allocate nothing, for the honest reason — a compiled delegate overComplexhas nothing to put on the heap. Worth stating so the two zeroes are not read as the same thing.Documentation only.
🤖 Generated with Claude Code