Skip to content

Commit c0ce7f9

Browse files
Revert "argon2: align blocks to 128-byte boundaries for modern x86-64 and aarch64"
This reverts commit 1342037. For reasons not yet understood, aligning blocks to 128-byte boundaries results in worse performance than using 64-byte alignment. Looking into this with perf suggests that it is *not* a cache problem, but rather that the generated code is different and results in substantially more instructions being executed when the blocks are 128-byte aligned. For now, revert the alignment back to 64 bytes. While we're at it, also remove the comment that suggests alignment is only needed to prevent false sharing: it's possible that other places in the crate, which I haven't checked, required (for correctness or best performance) the 64-byte alignment we're reverting back to. It's worth noting that false sharing isn't generally a major issue in Argon2: due to how memory is accessed, only the first and last few words of a segment can (and most of the time probably still won't) experience some false sharing with reads from other lanes. Finally, changing the alignment with 1342037 would have a major SemVer change: https://doc.rust-lang.org/cargo/reference/semver.html#repr-align-n-change
1 parent 5eefce1 commit c0ce7f9

File tree

1 file changed

+1
-5
lines changed

1 file changed

+1
-5
lines changed

argon2/src/block.rs

+1-5
Original file line numberDiff line numberDiff line change
@@ -46,12 +46,8 @@ macro_rules! permute {
4646
}
4747

4848
/// Structure for the (1 KiB) memory block implemented as 128 64-bit words.
49-
//
50-
// Blocks are 128-byte aligned to prevent false sharing. The specific alignment value is based on
51-
// the notes in `crossbeam-utils::CachePadded` for modern architectures, which either use 128-byte
52-
// cache lines (aarch64) or pull 64-byte cache lines in pairs (x86-64).
5349
#[derive(Copy, Clone, Debug)]
54-
#[repr(align(128))]
50+
#[repr(align(64))]
5551
pub struct Block([u64; Self::SIZE / 8]);
5652

5753
impl Block {

0 commit comments

Comments
 (0)