-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add #![no_std] compatibility #26
Conversation
Thanks for the PR! LGTM. In the interest of not inadvertently breaking |
Sure, I'll tack it on along with fixes for the lints |
I also took the chance to enable compat of the "serde", "glam" and "arrayvec" features with #![no_std]. The new test therefore enables |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks very much! 🚀
Build is failing because cargo fmt's output changed between nightly-2023-04-25 and your rust version. |
Ok, I've fixed the issues I noticed. |
thanks! |
Adds
#![no_std]
(withalloc
) compatibility by introducing a"std"
cargo feature.I'm interested in evaluating bitcode for embedded applications. I found adding support relatively painless, most of the changes are swapping
use std::*
foruse::core::*
, and adding explicit use ofalloc
.Notable changes:
HashMap
andHashSet
implementations forDecode
andEncode
are disabled forno_std
thread_local
here, utilising the const syntax which should improve efficiency by avoiding runtime initialisation checks.thread_local!
isstd
-only, I added a separateimpl_u8!
which falls-back to allocating the "scratch space" on eachpack8
/unpack8
call. See below images for benchmarks on the impact of this change (target_arch = "x86_64"
).cargo +nightly bench bench_pack
:cargo +nightly bench bench_unpack_u
:At a glance the performance impact is minimal, resulting in a < 1% average performance deficit on both pack and unpack without
std
.It remains to be seen if bitcode performs well on no_std target architectures. I'll likely be testing this in the near future.