A surprising enum size optimization in the Rust compiler

(jpfennell.com)

Show context

packetlost ◴[10 Apr 25 16:05 UTC] No.43645287[source]▶

I don't think it's actually "flattening" the enums discriminant spaces (though maybe it is). My guess is this is just 32-bit alignment requirement (ie. bytes 1:4 are padding) + sub-byte discriminant sizes. The surprising thing here is that the ordering of Outer's variants doesn't match the ordering as defined, instead having variant D's discriminant be 0 (0 << size_of::<Inner's discriminant>). size_of::<Inner> is actually 33 bits and size_of::<Outer> is 34 bits and then you just apply alignment requirements to each field. Actual size_of calls will account for alignment and padding, but the compiler knows the truth.

What's cool about this in general is nested match statements can be flattened into a jumplist (idk if rustc does this, but it's possible in theory).

replies(2): >>43646587 #>>43649004 #

1. hinkley ◴[10 Apr 25 18:09 UTC] No.43646587[source]▶

>>43645287 #

In a lot of languages space optimizing Optional Types without using a reserved enum value or pointer tags would lead to memory model problems with atomically writing two values at once which might be more easily solved in a borrow semantics world. I hope there is someone out there mining research papers for the implementation strategies that were abandoned as unworkable due to bookkeeping issues, which Rust has already paid.

But in the case of Options they tend to be both write-once and short-lived, so that removes a lot of necessity. Options are going to stay mostly on the stack and in async callbacks, unless they go into caches.

But for other data structures where multiples fields need a tag, I suspect Rust could use some bitfields for representing them. You’d need a fairly big win to make it worth implementing however.

replies(2): >>43646937 #>>43647055 #

2. packetlost ◴[10 Apr 25 18:45 UTC] No.43646937[source]▶

>>43646587 (TP) #

I'm honestly not exactly sure what you're talking about, but the fundamental limit for atomic writes is usually the register-size for a CPU which is usually 64 or 32 bits. Considering enum variants are often larger than a single register in size, I don't see how atomic writes would ever be sane expectation.

replies(2): >>43647197 #>>43649639 #

3. Georgelemental ◴[10 Apr 25 19:00 UTC] No.43647055[source]▶

>>43646587 (TP) #

> In a lot of languages space optimizing Optional Types without using a reserved enum value or pointer tags would lead to memory model problems with atomically writing two values at once which might be more easily solved in a borrow semantics world.

Yes, Rust suppresses the niche optimization for values wrapped in an `UnsafeCell` (which is how you signal to the compiler that “atomically writing two values at once” might happen). https://github.com/rust-lang/rust/pull/68491

4. hinkley ◴[10 Apr 25 19:19 UTC] No.43647197[source]▶

>>43646937 #

Updating an aligned pointer is atomic. If you haven’t tagged it by moving bits to a neighboring word.

replies(1): >>43647322 #

5. packetlost ◴[10 Apr 25 19:35 UTC] No.43647322{3}[source]▶

>>43647197 #

I see. Yeah, you would either have to add the tagging to the upper bits of the pointer itself or concede that updates to a tagged type is not atomic. I feel like the latter is fine in most every scenario I've encountered in Rust (thanks to borrow checker rules) but in other languages the same cannot be said.

6. dataflow ◴[11 Apr 25 01:39 UTC] No.43649639[source]▶

>>43646937 #

> the fundamental limit for atomic writes is usually the register-size for a CPU which is usually 64 or 32 bits

CPUs nowadays support double the largest general-purpose register width. Unofficially, some CPUs can also do twice that: https://rigtorp.se/isatomic/

↑