perf: const_eq could be ~200 cycles faster on x86_64 with counter based implementation, specifically for U256

[malik672]

Description

While investigating the assembly output of const_eq, I noticed that a counter-based implementation generates significantly better code on x86_64(for U256) compared to the current boolean accumulation approach.

Current Implementation

pub const fn const_eq(&self, other: &Self) -> bool {
    let a = self.as_limbs();
    let b = other.as_limbs();
    let mut i = 0;
    let mut r = true;
    while i < LIMBS {
        r &= a[i] == b[i];
        i += 1;
    }
    r
}

Alternative Implementation

  pub const fn const_eq(&self, other: &Self) -> bool {
      let a = self.as_limbs();
      let b = other.as_limbs();
      let mut equal_count = 0usize;
      let mut i = 0;
      while i < LIMBS {
          equal_count += (a[i] == b[i]) as usize;
          i += 1;
      }
      equal_count == LIMBS
  }

Performance Impact

• x86_64: ~200 cycle improvement (https://godbolt.org/z/xxnzYjhdv)
• ARM64: No measurable difference

@prestwich I'm not reallys sure 200 cycles will translate to any diff but since it's vectorization maybe

[malik672]

I would benchmark this but I can't since i use ARM

[prestwich]

if you submit a PR containing a bench, we can add it to codspeed in advance of any refactoring work

[prestwich]

as a general rule, const_ perf is not super high prio as we intend these functions to be invoked only at compile time, rather than in execution hot paths

[malik672]

as a general rule, const_ perf is not super high prio as we intend these functions to be invoked only at compile time, rather than in execution hot paths

True

as a general rule, const_ perf is not super high prio as we intend these functions to be invoked only at compile time, rather than in execution hot paths

Depends, are shift operations runtime hot paths?
Only touched the const_eq because I was check out shift operations

[prestwich]

Depends, are shift operations runtime hot paths?
Only touched the const_eq because I was check out shift operations

so far, the approach has been to differentiate fn const_* from fn * whenever using making the function const would cause a perf difference. do we know the perf on const_eq compared to the non-const derived eq ?

[malik672]

Depends, are shift operations runtime hot paths?
Only touched the const_eq because I was check out shift operations

so far, the approach has been to differentiate fn const_* from fn * whenever using making the function const would cause a perf difference. do we know the perf on const_eq compared to the non-const derived eq ?

Will measure it