Lift alloc requirement for bits feature#614
Conversation
94c1da8 to
7b65a18
Compare
7b65a18 to
e89f3c5
Compare
|
I hit a bug in the leftover bit-order swap path for the writer. I've fixed it in a fairly terrible way (exploded the code-paths so they weren't dependent, then fixed them independently). I think it should probably be tidied up for maintenance purposes, but I've pushed what I've got so the underlying bug is fixed. I've marked the PR as I don't believe I've done anything to trigger the MSRV failure, which seems to relate to indexmap. It looks like it had a release a couple of days ago, but yet to look into the problem in detail. |
|
Indeed |
|
I'm fine with updating the MSRV. |
e89f3c5 to
e354aa1
Compare
|
I've added a patch bumping the MSRV to 1.82. I'm looking for feedback on the Writer changes particularly, but also Reader. Once we've got consensus there and done any desired reworks I'll drop the |
|
Just to have the idea floating around, would it make sense for targets with allocators to use a heap-allocated BitVec for potentially "huge" types, and default to the stack-based BoundedBitVec for most types sized under whatever "huge" threshold? Or if there's no real benefit, that's fine. |
Not that there's no real benefit, but maybe just some missing context: The specific case of the linked code implements the traits for Rust's primitive types. You can see the tree of macros invoking the implementations here: https://github.com/amboar/deku/blob/bit-precise-no-alloc/src/impls/primitive.rs#L1209-L1260 As such there are no types that I'd consider "huge" there, in the sense of being inappropriate for the stack. That said, the strategy of offering different implementations based on |
e354aa1 to
036c221
Compare
|
@wcampbell0x2a I've addressed your comments so far, and have fixed the missing API docs as well. |
Ah, thank you for the correction. For the record, I was thinking about a potential case where a user's struct's size with all the members added up equaled an insane size, but that wouldn't be caught at this stage like you said. I had originally misinterpreted the type going into the |
Don't prevent the bits feature from being enabled in no-alloc environments. Signed-off-by: Andrew Jeffery <[email protected]>
Allow selection of bits feature in no-alloc environments. Signed-off-by: Andrew Jeffery <[email protected]>
Signed-off-by: Andrew Jeffery <[email protected]>
Signed-off-by: Andrew Jeffery <[email protected]>
Signed-off-by: Andrew Jeffery <[email protected]>
036c221 to
54ab016
Compare
|
Found a bug where we were failing to not require alloc for read padding while testing nvme-mi-dev against usbnvme. I've fixed it and pushed the result. |
|
@sharksforarms any thoughts on this? |
| // WA: required to apply endianness for cases where the field is not aligned with the byte boundary | ||
| // (see https://github.com/sharksforarms/deku/issues/603) | ||
| front_bits = &front_bits_le; | ||
| // TODO: Profile and optimise |
There was a problem hiding this comment.
what were the considerations you were thinking about at the time of writing this TODO?
There was a problem hiding this comment.
When iterating dst below we read into a slice backed by a buffer of a single byte.
I left the comment not so much as something to fix immediately before the PR is merged, but to acknowledge the existing performance concern if someone did profile and find the current implementation problematic. The current implementation is what it is because it's easy to reason about, inside a bunch of code that's (IMO) tricky to comprehend.
The follow-up would be to figure out chunking strategies that can reduce issued reads to 1/N.
sharksforarms
left a comment
There was a problem hiding this comment.
Thank you - this looks great. I like the liberal use of debug_assert! and the extraction of the funky bit-manipulation logic into functions.
This has been of interest to me for a while. In parallel others had similar thoughts, e.g. in #607. I've opened the PR on the back of discussion there.