HN Explorer

8 comments

[ 2.0 ms ] story [ 26.1 ms ] thread
vardump
I'm surprised a Rust alignment bug is fixed this late. Performance degradation issues due to bad alignment is usually pretty obvious and somewhat easy to notice. I'm assuming vectorized (SSE) code is often generated for 128-bit loads and stores.

Obviously something must have obscured it until now. Anyone knows why?

Edit: So it was an LLVM issue. Even weirder. https://reviews.llvm.org/D86310

Edit2: Ok, it's obvious: if you "fix" something like this you can break a lot of code that relies on specific struct alignment. Ouch.

Jalad
I'm guessing that it's because u128 / i128 are used less frequently than primitives with smaller bit counts. Could be something else though
viraptor
That and also if you already have other large values, half the time you'd hit the right alignment by accident. Sometimes consistently every time in your app if you're lucky.
willglynn
The best treatment is at:

https://blog.rust-lang.org/2024/03/30/i128-layout-update.htm...

Note also that this involves LLVM, so clang < 18 had the same u128 behavior as Rust < 1.77/1.78.

lpribis
No, clang never had this issue since they bodged it in the front-end. From the post you linked:

> Clang uses the correct alignment only because of a workaround, where the alignment is manually set to 16 bytes before handing the type to LLVM.

Maybe it took long to notice because it was assumed to be working in LLVM since clang worked?

wiktor-k
Is it just me or should the following fragment use EnforcedAlignment in main?

    #[derive(TypeLayout, Copy, Clone)]
    #[repr(C)]
    struct EnforcedAlignment {
        _offset: [u8; GAP - 8],
        data: AlignedU128,
    }

    pub fn main() {
        println!("{}",  StockAlignment::type_layout());
    }
Excellent blogpost showing their product, by the way!
adriencaccia
Hey, co-author of the article here! You are completely right, this is a typo, I will fix it asap! Thanks for the kind words