Optimize Crypto::Bcrypt performance

[ysbaddaden]

The current Crypto::BCrypt implementation is roughly ~68% slower than the Ruby extension.

Changing the HEAP allocated Array for the stack allocated StaticArray and flattening P immediately reduces the difference to ~32% slower. Using raw pointers closes the gap further by going down to ~19% slower. Raw pointers are unsafe, but the algorithm has control over the pointer's range, and it never goes out of bounds. It's still not on par with the Ruby implementation (that uses C) but it's getting closer.

Running this benchmark, generating 10 hashes at cost 12 got a 71% 41% performance increase, down from 4.15s to 2.94s (vs 2.46s for Ruby).

refs #1309

[lribeiro]

Why not UInt32.static_array(...) instead?
Won't it spare us all the _u32?

[ysbaddaden]

Thanks. I wasn't aware of this initializer. I wish Int[1, 2, 3] would return a StaticArray instead of an Array...

[kostya]

replace f with, gives also 5% performance:

  @[AlwaysInline]
  private def f(x)
    d = x.to_u8
    c = (x >> 8).to_u8
    b = (x >> 16).to_u8
    a = (x >> 24).to_u8
    ((@s.to_unsafe[a] + @s.to_unsafe[256 + b]) ^ @s.to_unsafe[512 + c]) + @s.to_unsafe[768 + d]
  end

[ysbaddaden]

@kostya I didn't notice an improvement (above benchmark, LLVM 3.9.1).

I got a 6% improvement, by memoizing pointers to @s sections, instead of repeating additions in f which is costly, and keeping & 0xFF_u32 which appears to be faster than casting with to_u8 (at least on Linux x86_64).

It's now down to 2.81s vs 2.46s (ruby).

[mverzilli]

Excellent as usual, Julien! 🙇

Thank you so much, this is an amazing contribution 💯