Allocate intermediate values on the heap in [std]
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 38/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- rust
- Domain
- operating-systems, performance
Research direction
Start by reviewing dependency #49 and the std/no_std setup for the mlsda and mlkem algorithm crates. Use valgrind --tool=massif to compare stack and heap usage with a release-branch baseline. Done means large intermediate values use the heap when std is available, stack usage is reduced, and stack-versus-heap control for key structs is documented.
Written by the indexing model from the issue text.
Description
Depends on #49
Having made all our algorithm crates work in a stack-only [no_std] build, let's now go back and make use of our feature = 'std' so that algorithms like mlsda and mlkem allocate large intermediate values such as vectors and matrices on the heap when available.
The reason for this is that most operating systems enforce strict stack-size limits -- ex.: an entire process will get killed if it uses more than 8 mb of stack. If you're not careful, you can blow this just by creating a bunch of ML-DSA-87 keys. So if we have access to a memory allocator, it's probably polite to use it.
There is a research task here in that I'm not actually sure how to force the usage of heap vs stack when declaring variables. Is that what Box<> is for? Is it as simple as putting a cargo feature guard on the crate-level #![no_std] line, and the compiler will do the rest for us?
Also, some of our simple structs (ex.: public and private key types) will need some documentation for how the caller can control whether they get allocated on the stack or on the heap.
Acceptance criteria: test with
valgrind --tool=massif
to make sure that we're seeing the big allocations move to the heap, and the total stack usage go down (might be worth taking a before-snapshot on the release branch to compare araignst)
- Dominant language
- Rust
- Stars
- 25
- Forks
- 18
- Avg merge
- 16h 38m
- Merged PRs (30d)
- 3
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from bcgit/bc-rust
-
good first issue refactor
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
Difficulty 4/5 3-5 days Newbie friendliness 58/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100