The existence of ref patterns somewhat limits what one can do here as well, since you must be able to create a pointer to the value being matched, which implies that it can't be too "disguised". For example, this prevents us from optimizing something like `Either<~A,~B>` to use a 0 or 1 in the low bit.
One thought that was recently mentioned to me is that it would be useful to define a few types like u31/u63 or u28/u60, which would allow us to siphon off the high bits for sentinel values. Niko On Wed, Jul 24, 2013 at 10:08:27AM -0700, Graydon Hoare wrote: > On 13-07-24 09:33 AM, Brendan Zabarauskas wrote: > >On 25/07/2013, at 2:15 AM, Evan Martin <[email protected] > ><mailto:[email protected]>> wrote: > > > >>Is an Option<u8> implemented as a pair of (type, value) or is it > >>packed into a single word? > > > >A quick test shows: > > > > rusti> std::sys::size_of::<Option<u8>>() > > 16 > > We represent enums as (tag-word, union-of-data-fields) pairs, except > in the optimized representation case of option<~T> where we use > compress the nullary None tag into a sentinel pointer (null) and drop > to 1 word. > > I expect we'll eventually do one other obvious optimization here, to > define tags as the smallest datum width that can accommodate all the > tag values and maintan the alignment "requirement" (or absence of > speed penalty) of the data fields, not just "1 word". That sort of > definition would mean option<u8> drops to 2 bytes (not 16) and on > targets with cheap unaligned access (ivy bridge etc) most tags (with > <256 variants) drop from 8 bytes to 1 (if you pass the appropriate > --target-feature flag). > > To get much more clever than that involves hunting in the > union-of-data-fields for overlapping fields into which you can either > scrounge bits or use sentinel values. This is not totally > implausible: the low 3 bits are available in most pointers from a > malloc, and the entire zero page on almost all platforms is unmapped > for picking sentinels. On x64 there are tons of spare bits in every > pointer, and virtually unlimited sentinel values due to the > noncanonical address range. Plus there are NaN bits and the unused > >21st bits in char and whatnot. But ... I think it'll be a while > before we bother with that sort of thing, if ever. > > -Graydon > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
