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 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?
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 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?