Skip to content

Tune flow of inline methods in symbol_with_update #2671

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

Merged
merged 1 commit into from
Feb 15, 2021

Conversation

barrbrain
Copy link
Collaborator

  • Mostly avoid calling Vec::reserve() in CDFContextLogOps::push().
  • Manually elide bounds checks in WriterBase::symbol() as they are not easily inferred by the compiler although statically known.
  • Rewrite ec::rust::update_cdf() to be panic-free and hint to the compiler not to unroll beyond the maximum CDF length.

Copy link
Collaborator

@lu-zero lu-zero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine, if you could address the 2 nits on landing would be nice.

@@ -524,9 +524,12 @@ where
#[inline(always)]
fn symbol(&mut self, s: u32, cdf: &[u16]) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a TODO: rewrite once const generics are stable

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't the scope of rewriting using const generics much broader than this function?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, but this is one that would be good to not forget :)

src/ec.rs Outdated
// Single loop (faster)
for (i, v) in cdf[..nsymbs - 1].iter_mut().enumerate() {
for (i, v) in cdf[..nsymbs - 1].iter_mut().enumerate().take(15) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

15 shouldn't be expressed using Self::CDF_LEN_MAX ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Self::CDF_LEN_MAX is defined for CDFContextLogOps rather than WriterBase. We could reference context::CDF_LEN_MAX after making it accessible.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably it would be good or having ec::CDF_LEN_MAX defined.

* Mostly avoid calling Vec::reserve() in CDFContextLogOps::push().
* Manually elide bounds checks in WriterBase::symbol() as they are
  not easily inferred by the compiler although statically known.
* Rewrite ec::rust::update_cdf() to be panic-free and hint to the
  compiler not to unroll beyond the maximum CDF length.
@coveralls
Copy link
Collaborator

Coverage Status

Coverage increased (+1.5%) to 83.026% when pulling e9be6c9 on barrbrain:ec-no-panic into 1869a8b on xiph:master.

@barrbrain barrbrain merged commit e9be6c9 into xiph:master Feb 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants