Hi Arnold, Thank you and atr...@apple.com very much for your answers. That helps already a lot. Are you Arnold from the WWDC Video? I removed all the answers that are clear and have some follow-up questions inline.
> Am 14.07.2016 um 23:02 schrieb Arnold Schwaighofer <aschwaigho...@apple.com>: > >> 3. Then Arnold says that four existential containers pointing to the same >> value (greater than the value buffer) use 4 heap allocations. He proposes >> copy-on-write (using a local storage class), but **does he mean this should >> be implemented by hand or is this an optimization that the swift compiler >> does on its own?** > > No the swift compiler does not do this on its own. Are there corresponding plans? Storing „big“ values (using some statistics to evaluate where the break-even is) as reference types always, storing them in a big table per type (each value occurs only once) should be possible, right? Is this something I should post on the swift-evolution mailing list? > >> The issue here is, that the switch between "swift subscript" for showing an >> abstraction of internals and real swift code that one should write is >> sometimes not clear. > > Sorry about this. This was meant as positive criticism. I really like the video! > >> Doing this by hand has some clear disadvantages as this would add a >> reference to each usage of `Line` (and reference counting) even in the first >> examples of Kyle. > > Yes, it is a tradeoff. Either, in the type erased context (as an instance of > protocol value) copies are expensive for large value types and in the non > generic/existential concrete context it is fast. Is it really fast in the latter context for „big“ values? All collection types use copy-on-write. Especially if you have a lot of reference type properties copying seems to be slow even in the latter context. And since all collection types (including String) are backed by a reference type, even properties of these type incur additional reference counting. > Or you make the type have indirect storage with copy on write to preserve > value semantics and then you have an overhead for reference counting. > > You can get the best of both worlds if you write a wrapper. > > All of this comes at the cost of a lot of boiler plate code and discussions > are taking place how-to improve this situation. Are there already proposals available or is it still in early discussions? Can you give me a hint where to find more about it? > >> 6. Is the Value-Witness-Table a (kind of) dictionary for all values of a >> given value type (bigger than the value buffer), so that you do not store >> any value twice on the heap, but share the reference? If this is the case >> the answer of *3.* should be *automatically*. But then again, the "manual" >> implementation of `String` and `Array` (see *4.*) make no sense anymore, >> does it? Or are `Array` and `String` implemented only on the lower-level and >> the copy-on-write implementation is not visible in their Swift >> implementation? > > > I don’t full understand the question. > > The value-witness-table exists per type and contains functions that describe > how to copy, allocate, and deallocate values of that type. OK. I am still a little bit unsure what it is now. Andrew Trick says: > A value witness table is a dictionary for all values of a type regardless of > whether it fits in a buffer. > The keys are operations that can be done to any value (copy/destroy), the > implementation for > that type knows where the value is stored. In the example Arnold (you?) used the value witness table to copy the value (see slide 171 last line of code): ```swift pwt.draw(vwt.projectBuffer(&local)) ``` Since I didn’t know that the „storage“-trick is done manually, I thought there is a (hash)table/dictionary of all values of a „big“ value type where each value is uniquely stored (constant time access). For „small“ values it would just point, to the concrete value of this very value. As mentioned above: should I post this on the swift-evolution mailing list? All the best Johannes
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
