Hashing across architectures

Justin G — Mon, 17 Aug 2026 22:56:04 +0000

In a previous post, I mentioned how just because you develop on a brand new or nearly new laptop doesn't mean that's where your code is going to run, especially if it's deployed to the cloud.

Compute has come a long way from the single core days. Pretty sure I have more cpu cores sitting on my desk between my laptop and desktop than all previous computers I've owned since college combined.

But not everyone has access to multiple machines to test on, or even different architectures. I won't go into detail on the rabbit hole I went down recently, but it involved looking into how different languages across different architectures performed hashing a password amongst other things.

TL;DR

Salt Length: 16 bytes
Secret Length: 64 bytes
PBKDF2 with SHA256 algorithm
500,000 iterations

Rust demo apps built in release mode.
Odin demo apps built with -o:speed
Zig demo apps built with -D ReleaseSafe

Macbook Pro M4 Pro, MacOS 15.7.5
Rust 1.97.1 (aws-lc-rs crate): 66ms
Rust 1.97.1 (ring crate): 103ms
Odin (dev-2026-08): 98ms
Zig (0.16): 103ms

AMD Ryzen 9 9950X, CachyOS, Linux Kernel 7.1.8
Rust 1.97.1 (aws-lc-rs crate): 93ms
Rust 1.97.1 (ring crate): 140ms
Odin (dev-2026-08): 123ms
Zig (0.16): 171ms

(Eyeball averages across a number of runs. This isn't meant to be scientific.)

Additional Words

What we can see from above is that performance for hashing a password varies between language choice and architecture, with a clear advantage for the Mac M series chips, which a lot of companies develop on but then run their applications on x86-64 machines.

Even with a language like Rust, choosing one crate, aws-lc-rs, over another, ring, can lead to significant performance improvements, or even allowing to choose more iterations for stronger password hashing.

Now I understand not everyone has access to multiple personal machines, or maybe even the latest hardware. (I worked for years on a M1, and while I don't have the exact numbers available, pretty sure it still beats my AMD Ryzen 9 9950x for the task above.) It just means that you can't assume that the feature you developed will perform the same on different hardware, especially if the hardware is a few years old or older. It's always best to test against the hardware your production code will run on especially if it's an expensive task that could potentially block on your server.

Example code below

Rust (aws-lc-rs)

use aws_lc_rs::pbkdf2;
use aws_lc_rs::rand::{Random, SystemRandom, generate};
use std::num::NonZero;

fn main() {
    let r = SystemRandom::new();
    let salt: Random<[u8; 16]> = generate(&r).unwrap();

    let iterations: NonZero<u32> = NonZero::new(500_000).unwrap();

    let password = "SuperSecretPassword";
    let mut secret = vec![0u8; 64];

    let salt = salt.expose();
    let time = std::time::Instant::now();

    pbkdf2::derive(
        pbkdf2::PBKDF2_HMAC_SHA256,
        iterations,
        &salt,
        password.as_bytes(),
        &mut secret,
    );

    println!("Elapsed: {:?}", time.elapsed());
}

Rust (ring)

use ring::pbkdf2;
use ring::rand::{Random, SystemRandom, generate};
use std::num::NonZero;

fn main() {
    let r = SystemRandom::new();
    let salt: Random<[u8; 16]> = generate(&r).unwrap();

    let iterations: NonZero<u32> = NonZero::new(500_000).unwrap();

    let password = "SuperSecretPassword";
    let mut secret = vec![0u8; 64];

    let salt = salt.expose();
    let time = std::time::Instant::now();

    pbkdf2::derive(
        pbkdf2::PBKDF2_HMAC_SHA256,
        iterations,
        &salt,
        password.as_bytes(),
        &mut secret,
    );

    println!("Elapsed: {:?}", time.elapsed());
}

Odin

package main

import "core:crypto"
import "core:crypto/pbkdf2"
import "core:fmt"
import "core:time"

main :: proc() {
    salt: [16]u8
    dk: [64]u8
    password := "SuperSecretPassword"

    crypto.rand_bytes(salt[:])

    start := time.now()
    pbkdf2.derive(.SHA256, transmute([]byte)(password), salt[:], 500_000, dk[:])
    elapsed := time.since(start)

    ms := time.duration_milliseconds(elapsed)

    fmt.printfln("Time elapsed is: {}ms", ms)
}

Zig

const std = @import("std");
const Io = std.Io;
const print = std.debug.print;
const time = std.time;

pub fn main(init: std.process.Init) !void {
    const io = init.io;

    var dk: [64]u8 = undefined;
    var salt: [16]u8 = undefined;

    try Io.randomSecure(io, &salt);

    const start = Io.Clock.awake.now(io);
    try std.crypto.pwhash.pbkdf2(&dk, "SuperSecretPassword", &salt, 500_000, std.crypto.auth.hmac.sha2.HmacSha256);

    const elapsed2: f64 = @floatFromInt(start.untilNow(io, .awake).nanoseconds);
    print("Time elapsed is: {d:.3}ms\n", .{
        elapsed2 / time.ns_per_ms,
    });
}

"It works on my machine"

Justin G — Mon, 17 Aug 2026 22:51:47 +0000

We've all heard this saying before.

We've all seen the memes.

Maybe we've actually said this before in our day to day work when someone says something isn't working on their machine.

There are a lot of variables that could potentially go unaccounted for when a developing a feature. Different OSes. Different versions of the same OS. Different browsers. Different CPU architectures.

It could even boil down to developing a layout for a webpage that looks great on a 27" or 32" monitor, but doesn't scale properly on a smaller laptop screen or when someone splits their 27" monitor to display multiple web pages at once (I mean who even works that way...). That cool little sidebar you developed doesn't always work on every screen size (seriously, stop with the sidebars on web pages that can't be scaled or hidden).

Backend services aren't without their own potential gotchas either. Apple has done a great job providing laptop hardware on their own processors. These M series chips are quite performant. However, the code you develop isn't being run on M series chips in the cloud. Your code will most likely run on some x86-64 based servers. Are those servers as performant as the developer laptops the company is buying everyone? Most likely not, or at least not without paying a premium to your cloud service provider.

One of my tales of "It works on my machine" comes from a time where I was looking through a code base that dealt with hashing user passwords, and I noticed the code was using a deprecated hashing algorithm. Did some research on what algorithm to update to along with reasonable amount of how long hashing a password should take. Made the updates. Tested it on my developer laptop, and everything was looking good to move to the test environment running in the cloud. Pushed the code up, verified it was running, changed my user account password to ensure the new password was stored with the updated hashing, and logged in.

Well..that wasn't nearly as performant as on my development laptop. Turned on telemetry, did another login, and sure enough, it was 10x slower in the test environment as compared to my laptop. Doing some digging, I soon learned the current testing environment was running on servers that were over a decade old, you know, for cost reasons. Even checking the servers that backed the production instance, the update I was developing would be 2x slower compared to my laptop.

So while it may work on your machine, your machine is not where that code will end up running for years on end.

DEV Community: Justin G

Hashing across architectures

TL;DR

Additional Words

Example code below

"It works on my machine"