> 在 2016年10月19日，12:21，Joe Groff <jgr...@apple.com> 写道： > >> >> On Oct 19, 2016, at 9:16 AM, Guoye Zhang via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> >>> 在 2016年10月19日，11:43，Kevin Nattinger <sw...@nattinger.net> 写道： >>> >>>> >>>> On Oct 19, 2016, at 8:13 AM, Guoye Zhang via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> >>>>> 在 2016年10月19日，07:10，Jeremy Pereira <jeremy.j.pere...@googlemail.com> 写道： >>>>> >>>>> >>>>>> On 18 Oct 2016, at 19:17, Guoye Zhang via swift-evolution >>>>>> <swift-evolution@swift.org> wrote: >>>>>> >>>>>> Currently, Swift Int family and UInt family have compact representations >>>>>> that utilize all available values, which is inherited from C. However, >>>>>> it is horribly inefficient to implement optional integers. It takes >>>>>> double the space to store [Int?] than to store [Int] because of >>>>>> alignment. >>>>> >>>>> Is this a general problem with Swift? Are lots of people complaining that >>>>> they are running out of space for their Optional<Int> arrays? >>>>> >>>> It's just that a common data type wasting almost half the space seems >>>> inefficient. I guess this is also the reason why they didn't adopt >>>> optional integers widely in stdlib. >>> >>> I’ve only needed an array of optionals once, maybe twice. I don’t think >>> arrays of optionals are widely used to begin with, and the reason there are >>> few optional integers in the stdlib is because the interface is from objc, >>> which doesn’t have optionals. I doubt any thought at all was given in >>> designing the standard library to the extra space for an optional. >>> >> Swift stdlib is independent from objc. Currently, "Int?" storage has a >> tradeoff between less space (n + 1 bytes) and unaligned access, and more >> space (n * 2 bytes) and fast access. Neither of them is optimal. > > Something worth considering at a higher level is whether Array ought to align > storage at all. Modern Intel and Apple CPUs pay much less of a penalty for > unaligned access than older microarchitectures, and the memory savings of > packing arrays of Int? and similar types would be significant. (There are C > compatibility issues here too, since C's semantic model requires pointers to > be well-aligned for their type, and we want Swift.Arrays of C types to be > cheaply interoperable with pointer-based C APIs. This could perhaps be dealt > with by guaranteeing that C basic types and structs always have sizeof(T) % > alignof(T) == 0, and well-aligning the beginning of arrays.) > > -Joe > That would be great, and certainly needs exploring before locking ABI.
- Guoye >> >>>>> >>>>>> >>>>>> I propose to ban the top value in Int/UInt which is 0xFFFF... in hex. >>>>>> Int family would lose its smallest value, and UInt family would lose its >>>>>> largest value. Top value is reserved for nil in optionals. An additional >>>>>> benefit is that negating an Int would never crash. >>>>> >>>>> Well the “top value” for signed ints would have to be 0x8000... not >>>>> 0xffff... which is the representation of -1. The top value for unsigned >>>>> ints cannot be banned because unsigned integers are often used as bit >>>>> fields either directly or in OptionSets. >>>>> >>>>> Furthermore, how would the semantics of &+ and &- be affected? What about >>>>> the performance of those two operators? >>>>> >>>> I was originally going for the symmetry between Int and UInt as in >>>> compatible bit patterns. Now that I think of it, UInt is commonly used for >>>> bitwise operations, and it doesn't make sense to optimize for "UInt?" >>>> which is uncommon. So I agree that 0x80... is better. >>>> >>>> Int performance would surely suffer because of current instruction sets, >>>> but Int? would improve. >>> >>> In my experience, ints are used orders of magnitude more often than >>> optional int?s. Why optimize for the rare case? >>> >> If we were to have safe arithmetic that produces optionals, or lenient >> subscript, it is important to have efficient optional integers. I do agree >> that Int slowing down is unacceptable. >> >> - Guoye >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
