Performance issues on MacOS (Intel)

[oplik0]

Hi there,

I switched to use 4.3.x recently and was surprised of how slow it was compared to 4.2.1, using the exact example in README.

4.2.1

import { hash, verify } from "https://deno.land/x/scrypt@v4.2.1/mod.ts";

console.time("hash");
const hashResult = hash("password");
console.timeEnd("hash");

console.time("verify");
const verifyResult = verify("password", hashResult);
console.timeEnd("verify");

$ deno run -A scrypt.js
hash: 221ms
verify: 137ms

4.3.4

import { hash, verify } from "https://deno.land/x/scrypt@v4.3.4/mod.ts";

console.time("hash");
const hashResult = hash("password");
console.timeEnd("hash");

console.time("verify");
const verifyResult = verify("password", hashResult);
console.timeEnd("verify");

$ deno run -A scrypt.js
hash: 1684ms
verify: 1199ms

I'm on recent Mac OSX.

Originally posted by @sntran in #12 (comment)

[oplik0]

In general this is the result of adjustment of default parameters to align with current OWASP guidelines I mentioned in this thread:

The only "bigger" thing I'll probably do soon is adjust default parameters to current OWASP recommendations (since the current default N value is a bit lower than recommended).

Please try the examples with the same logN, e.g. the previous default:

import { hash, verify } from "https://deno.land/x/scrypt@v4.3.4/mod.ts";

console.time("hash");
const hashResult = hash("password", { logN: 14 });
console.timeEnd("hash");

console.time("verify");
const verifyResult = verify("password", hashResult);
console.timeEnd("verify");

(or you can try both with current default of 17)
Sample results comparing the 4.2.1 and 4.3.4 with this code:
4.2.1:

$ deno run .\example.ts
hash: 104ms
verify: 72ms

4.3.4:

$ deno run .\example.ts
hash: 106ms
verify: 78ms

On Windows (amd64) the current version seems to be slightly slower. Interestingly, on an ARM Linux server this trend reverses:

4.2.1:

$ deno run example.ts 
hash: 182ms
verify: 118ms

4.3.4:

$ deno run example.ts 
hash: 176ms
verify: 114m

But the differences are <15% and even on amd64 can flip depending on parameters...

However, the bump in parameters shouldn't result in such a big slowdown. This seems to be something MacOS-specific. The runtime with logN=17 on my amd64 device is closer to half of yours:

$ deno run .\example.ts
hash: 841ms
verify: 595ms

I think part of it is just ARM (I'm assuming you're on M1/2/3 device), since my ARM results are also slower:

$ deno run example.ts 
hash: 1295ms
verify: 917ms

But this is an Ampere Altra server using just one core, this should be handily beat by any Apple Silicon. Even M1 is supposed to be >2x faster single-core!

I'll try more testing on ARM and with GitHub Actions M1 runners soon (since I don't have any Apple devices), maybe there is some way to at least bring perf to amd64 levels...

[sntran]

Thanks for the quick response!

I have tried 4.3.4 with logN: 14 and yes, the result is much better:

$ deno run -A scrypt.js
hash: 219ms
verify: 149ms

As for logN: 17, it could be that my MBP is still an Intel one and not even one of those M1/2/3 devices.

[oplik0]

@sntran can you try with 4.4.2? I enabled simd which seems to have bumped the performance by 2x for basically free (technically compatibility, but Deno 1.8, last version without simd, didn't work with this project already anyway. Last node version w/o wasm simd is also after EOL).

Results for my laptop:
logN=14

$ deno run example.ts 
hash: 56ms
verify: 36ms

logN=17

deno run example.ts
hash: 384ms
verify: 284ms

And the arm server from before:
logN=14:

$ deno run example.ts
hash: 78ms
verify: 45ms

logN=17:

$ deno run example.ts
hash: 519ms
verify: 359ms

[sntran]

That's awesome.

logN=17 (default)

$deno run scrypt.js
hash: 688ms
verify: 531ms

logN=14

$ deno run scrypt.js
hash: 97ms
verify: 62ms

Faster by half indeed. And I suppose Intel Mac is half slower than M1/2/3.

But overall, that's a great improvement! Thank you!

[oplik0]

I think it got to the point I'd consider the perf to be fine - without something like RustCrypto/password-hashes#79 (which would only apply for p>1 anyway) I don't think I can make significant improvements here anymore, so I'm gonna close this issue now :)

[sntran]

That improvement was more than I asked for. Thank you!