On Thu, Aug 3, 2017 at 11:17 PM, Karl Wagner <razie...@gmail.com> wrote:
> > On 4. Aug 2017, at 02:44, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> The root cause, of course, is that the VLAs require new stack allocations >> each time, and the stack is only deallocated as one lump when the frame >> ends. >> >> >> That is true of alloca(), but not of VLAs. VLAs are freed when they go >> out of scope. >> >> >> Learned something today. >> >> Anyway, if the goal is stack allocation, I would prefer that we explored >> other ways to achieve it before jumping to a new array-type. I’m not really >> a fan of a future where [3; Double] is one type and (Double, Double, >> Double) is something else, and Array<Double> is yet another thing. >> > > They are completely different things. > > [3; Double] is three *contiguous* Doubles which may or may not live on > the stack. > > (Double, Double, Double) is three Doubles bound to a single variable > *name*, which the compiler can rearrange for optimal performance and may > or may not live on the stack. > > Array<Double> is an vector of Doubles that can dynamically grow and always > lives in the heap. > > > > Yeah, I understand that — the problem I have is that I’m not sure it’s > going to be obvious to everybody *else* when they should use which. We > need to balance semantic purity against simplicity and ease-of-learning. > > For example, I’m not sure many users are aware that tuple elements in > Swift don’t have an ordered relationship; they certainly give that > impression. This is especially confusing as "In mathematics a tuple is a > finite ordered list (sequence) of elements.” [https://en.wikipedia.org/ > wiki/Tuple] > > >> From what I’ve read so far, the problem with stack-allocating some Array >> that you can pass to another function and which otherwise does not escape, >> is that the function may make an escaping reference (e.g. assigning it to >> an ivar or global, or capturing it in a closure). >> >> How about if the compiler treated every Array it receives in a function >> as being potentially stack-allocated. The first time you capture it, it >> will check and copy to the heap if necessary. All subsequent escapes >> (including passing to other functions) use the Array known to be allocated >> on the heap, avoiding further checking or copying within the function. >> >> The same goes for Dictionary, and really any arbitrary value-type with >> COW storage. The memory that those types allocate is part of the value, so >> it would be cool if we could treat it like that. >> >> > This is not true. FSAs have nothing to do with automatic storage, their > static size only makes them *eligible* to live on the stack, as tuples > are now. The defining quality of FSAs is that they are static and > contiguous. > > > Really, the only *practical* difference between a FSA and a tuple is the > memory layout. Do most users really need to care about that? For those > users that do, wouldn’t an @-attribute be a less intrusive change to the > language than a whole new list-style type? > > For example, the benefit to having Collection-conforming tuples as our > FSAs would be that they don’t necessarily have to be contiguous. If you > have a large multi-dimensional list of Bools or some other tiny type, you > might also *benefit* from those layout optimisations. > > I like the simplicity in telling people: > > - If you need a dynamically-sized list, use an Array > - If you need a fixed-sized list, use a tuple (and it will get an > optimised layout. You can override this with an attribute, similar to > @fixed_layout or @inlineable). > > - Karl > Actually, if you do a lot of graphics programming like I do, the memory layout is very, *very* important. Swift may not care about layout, but many APIs that it interacts with do. Is @fixed_layout actually planned to be part of the language? I was under the impression it’s just a placeholder attribute. Either way, I’d appreciate not having to write Float sixteen times for a 4x4 matrix type.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution