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
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)
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 ourfeature = '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
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)