Bcrypt large speed regression

[Daimanta]

Zig Version

0.10.0

Steps to Reproduce and Observed Behavior

The speed of Bcrypt with equal/similar parameters as Zig 0.9.x has regressed by about a factor 10 in 0.10.0. This severely reduces the usability of the implementation as we have this now.

Code as tested:

const std2 = @import("std");
const bcrypt = std2.crypto.pwhash.bcrypt;
const time = std2.time;
const begin = time.milliTimestamp();
var params: bcrypt.Params = .{ .rounds_log = 10 };
var hash_options: bcrypt.HashOptions = .{ .allocator = std2.heap.page_allocator, .params = params, .encoding = std2.crypto.pwhash.Encoding.crypt };
var buffer: [bcrypt.hash_length]u8 = undefined;
_ = try bcrypt.strHash("password", hash_options, buffer[0..]);
const end = time.milliTimestamp();
const diff = end - begin;
std2.debug.print("{d}\n", .{diff});

This code on my machine has around the following results:
Zig 0.9: 392ms
Zig 0.10: 5128ms

Expected Behavior

The speed of the algorithm should be similar the speed in Zig 0.9.

[jedisct1]

Yes, this is a regression in stage2 that probably affects more than bcrypt.

Compiling with -fstage1 gets the previous speed back, but this is obviously just a bad workaround.

I'll see if I can pinpoint where the regression is.

[jedisct1]

On Apple M1:

Stage1: bcrypt:      0.017 s/ops
Stage2: bcrypt:      1.375 s/ops

That's a 80x factor.

[nektro]

state: State vs state: *const State and #12215 could be culprits

[jedisct1]

Besides the slowdown:

❯ du -sh *.s
280K	main-stage1.s
4.1M	main-stage2.s

[jedisct1]

state: State vs state: *const State

That indeed seems to make a massive difference!

[jedisct1]

Well done, @nektro !

state: *const State indeed brings us back to the stage1 speed.

[IntegratedQuantum]

It might be worth noting that as of yesterday related performance problems like #12638 were fixed in #13074
Have you checked with the latest master version if the performance problems still happen?

[jedisct1]

Master branch helps, but #13518 still makes a difference:

Apple M1:

master: 0.362 s/ops
master+13518: 0.017 s/ops
stage1: 0.017 s/ops

[andrewrk]

I'm re-opening this issue; it can be closed when 7eed028 is reverted due to fixing the compiler codegen.

[Daimanta]

I'm still seeing the same speed issues, although the performance has indeed improved. Running the example code I get around 1100ms for Zig 0.10.1. This is better than 0.10.0 but still about 3 times slower than 0.9.1. I know there is another issue with data passing, but I'd like to keep this issue open as this issue is still heavily impacting the usability of the algorithm.

[Daimanta]

Running zig-0.11.0-dev.4003, I have reran the experiment. The speed I'm getting for the above code snippet is 320ms. I would consider this an acceptable speed as it is faster than the 0.9 implementation. I would consider closing this ticket as fixed.

[jedisct1]

@Daimanta The core issue doesn't seem to have been resolved.

Reverting #13518 still causes a significant speed regression.

On a M1 Macbook:

Before: 0.014 s/ops
After : 0.364 s/ops

[jedisct1]

See 90a877f for related issues.

[andrewrk]

Possible reduction of this issue: #17580