<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 9, 2017, at 6:14 PM, Jens Persson <<a href="mailto:jens@bitcycle.com" class="">jens@bitcycle.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Thanks for that clarification John McCall.</div>My code is using a lot of generic structs (in which memory layout is important) though, an example would be:<div class="">struct Vector4<E> : Vector {</div><div class=""> typealias Index = VectorIndex4</div><div class=""> typealias Element = E</div><div class=""> var e0, e1, e2, e3: Element</div><div class=""> …</div><div class="">}</div><div class="">And I guess I'm out of luck trying to represent those as C structs?</div><div class="">So AFAICS it looks like it is currently impossible to write generic low level code in Swift, unless I just keep doing what I've been doing (It does currently work after all) knowing that it will probably break in some future versions of Swift. But in that possible future version of Swift, I could probably find a way to make it work again (using some possible explicit tools for layout control present in that version of Swift).</div><div class="">Correct?</div></div></div></blockquote><div><br class=""></div>Correct.</div><div><br class=""></div><div>John.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">/Jens</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Jul 9, 2017 at 11:41 PM, John McCall <span dir="ltr" class=""><<a href="mailto:rjmccall@apple.com" target="_blank" class="">rjmccall@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jul 9, 2017, at 4:49 PM, Jens Persson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_-7384661522464151848Apple-interchange-newline"><div class=""><div dir="ltr" class="">Sorry for making so much off topic noise in this thread, but I made a mistake regarding the Metal tutorial:<div class="">Looking more carefully I see now that they rebuild a vertedData: [Float] from their vertices: [Vertex] using the floatBuffer() method of the Vertex struct, which returns an Array with the stored properties of Vertex in correct order.</div><div class=""><br class=""></div><div class=""><div class="">While searching the internet about this I saw Joe Groff mentioning on Twitter that:</div><div class="">"We plan to sort fields in padding order to minimize size, and may also automatically pack bools and enums in bitfields."</div></div><div class=""><br class=""></div><div class="">So AFAICS my current image processing code is making the possibly invalid assumption that eg</div><div class="">struct S {</div><div class=""> var a, b, c, d: Float</div><div class="">}</div><div class="">will have a memory layout of 4*4=16 bytes (stride and size == 16) and an alignment of 4, and most importantly that a, b, c, d will be in that order.</div></div></div></blockquote><div class=""><br class=""></div></span>This is currently true, but may not always be. We want to reserve the right to re-order the fields even if it doesn't improve packing — for example, if two fields are frequently accessed together, field reordering could yield substantial locality benefits. We've also discussed reordering fields to put them in a canonical order for resilience, since it's a little counter-intuitive that reordering the fields of a struct should be ABI-breaking. (There are arguments against doing that as well, of course — for example, the programmer may have chosen the current order for their own locality optimizations.)</div><div class=""><br class=""></div><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">It looks like I should be defining my structs (the ones for which memory layout is important) in C and import them.</div></div></div></blockquote><div class=""><br class=""></div></span>This should always work, yes.</div><div class=""><br class=""></div><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Although I would be surprised if a Swift-struct containing only same-sized fields (all of the same primitive type) would be reordered, and such changes to the language would probably include some per-struct way to express some sort of layout control (since being able to define structs to be used for low level data manipulation is important in a systems language).</div></div></div></blockquote><div class=""><br class=""></div></span>Exactly. In the long term, Swift will have some explicit tools for layout control.</div><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">John.</div></font></span><div class=""><div class="h5"><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">/Jens</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Jul 9, 2017 at 7:01 PM, Jens Persson via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><span class="">I should perhaps add that in my image processing code, I use code like this:</span><div class=""><span class=""><br class=""><div class=""><div class="">func withVImageBuffer<Data, R>(for table: Table<Data>, body: (vImage_Buffer) -> R) -> R</div><div class=""> where</div><div class=""> Data.Coordinate.Index == VectorIndex2</div><div class="">{</div><div class=""> let vib = vImage_Buffer(</div><div class=""> data: table.baseAddress,</div><div class=""> height: vImagePixelCount(table.size.e1<wbr class="">),</div><div class=""> width: vImagePixelCount(table.size.e0<wbr class="">),</div><div class=""> rowBytes: table.stride.e1</div><div class=""> )</div><div class=""> return withExtendedLifetime(table) { body(vib) }</div><div class="">}</div></div><div class=""><br class=""></div><div class="">Here, Table<Data> is the raster image. Data.Coordinate == VectorIndex2 makes it a 2D table, and a Table's Data also has a type parameter Data.Value which can be eg one of the "pixel"-struct I showed before.</div><div class="">This works without any problems (I've tested and used the some variant of this type of code for years) but it would surely break if the memory layout of simple structs changed.</div><div class=""><br class=""></div><div class="">I can't see how this usage is much different from the one in the Metal tutorial. It too uses pointers to point into a data created using the (Swift) struct "Vertex", and the GPU hardware has its expectations on the memory layout of that data, so the code would break if the memory layout of the Vertex struct changed.</div><div class=""><br class=""></div></span><div class="">/Jens</div><div class=""><br class=""></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote"><span class="">On Sun, Jul 9, 2017 at 6:35 PM, Jens Persson <span dir="ltr" class=""><<a href="mailto:jens@bitcycle.com" target="_blank" class="">jens@bitcycle.com</a>></span> wrote:<br class=""></span><div class=""><div class="m_-7384661522464151848h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="">I don't think I'm misunderstanding you, but I might be, so I'll add more detail:</div><div class=""><br class=""></div>If you look at the Metal article, you'll see that the (Swift) struct "Vertex" is used to specify the data that is sent to Metal for creating a buffer (using MTLDevice<span style="color:rgb(56,58,66);font-family:'Droid Sans Mono',sans-serif;font-size:12px;white-space:pre-wrap;background-color:rgb(250,250,250)" class="">.makeBuffer</span>). The result that the GPU will produce surely depends on the fields of the Vertex struct (x, y, z, r, g, b, a) being in the specified order (ie swapping the red channel with the x coordinate would produce an unexpected result).<br class=""><div class=""><br class=""></div><div class="">And regarding the second example, pixel structs used for manipulating raster image data. Manipulating raster image data presumably includes stuff like displaying to screen, loading and saving raster images.</div><div class="">I currently use this way of doing this right now without any problems, but if the order of the fields (eg a, r, g, b) should change in the future, then my code would break (the colors of the images would at least not come out as expected).<span class="m_-7384661522464151848m_-3742573560874670849HOEnZb"><font color="#888888" class=""><br class=""></font></span></div><span class="m_-7384661522464151848m_-3742573560874670849HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">/Jens</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></font></span></div><div class="m_-7384661522464151848m_-3742573560874670849HOEnZb"><div class="m_-7384661522464151848m_-3742573560874670849h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Jul 9, 2017 at 5:53 PM, Chris Lattner <span dir="ltr" class=""><<a href="mailto:clattner@nondot.org" target="_blank" class="">clattner@nondot.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jul 9, 2017, at 12:23 AM, Jens Persson <<a href="mailto:jens@bitcycle.com" target="_blank" class="">jens@bitcycle.com</a>> wrote:</div><br class="m_-7384661522464151848m_-3742573560874670849m_1299701481412508098m_939603476265006243Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><div class="gmail_quote">On Sat, Jul 8, 2017 at 6:28 PM, Chris Lattner via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="">Hi Susan,<div class=""><br class=""></div><div class="">Swift does not currently specify a layout for Swift structs. You shouldn’t be using them for memory mapped i/o or writing to a file, because their layout can change. When ABI stability for fragile structs lands, you will be able to count on it, but until then something like this is probably a bad idea.</div><div class=""><br class=""></div><div class="">-Chris</div></div></blockquote></div><br class=""></div><div class="gmail_extra">Does this imply that you should never use Swift structs to eg interact with Metal?</div></div></div></blockquote><div class=""><br class=""></div></span>No.</div><div class=""><br class=""></div><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">This seems to be a very common practice. Here is a typical example (from a Metal tutorial at <a href="http://raywenderlich.com/" target="_blank" class="">raywenderlich.com</a>):</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra"><div class="gmail_extra">struct Vertex {</div><div class="gmail_extra"> var x,y,z: Float // position data</div><div class="gmail_extra"> var r,g,b,a: Float // color data</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra"> func floatBuffer() -> [Float] {</div><div class="gmail_extra"> return [x,y,z,r,g,b,a]</div><div class="gmail_extra"> }</div><div class="gmail_extra">}</div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">This doesn’t appear to expose the layout of the struct.</div><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">Also, does it imply that we cannot use structs (of only primitive types) like:</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">struct RgbaFloatsLinearGamma {</div><div class="gmail_extra"> var r, g, b, a: Float</div><div class="gmail_extra"> …</div><div class="gmail_extra">}</div><div class="gmail_extra">struct BgraBytesSrgbGamma {</div><div class="gmail_extra"> var b, g, r, a: UInt8</div><div class="gmail_extra">}</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">for manipulating raster image data?</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I don’t see why that would be a problem.</div><span class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">I vaguely remember a swift evo discussion where it was concluded that such usage was considered OK provided the stored properties of the structs was only primitive types, but I can't find it now.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">Perhaps it could be considered OK at least when the intended platforms are known to be only iOS devices?</div></div></div></blockquote><br class=""></span></div><div class="">I think you’re misunderstanding what I’m saying. It isn’t correct to take (e.g.) an unsafepointer to the beginning of a struct, and serialize that out to disk, and expect that the fields are emitted in some order with some specific padding between them. None of the uses above try to do this.</div><span class="m_-7384661522464151848m_-3742573560874670849m_1299701481412508098HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div><br class=""></font></span></div></blockquote></div><br class=""></div>
</div></div></blockquote></div></div></div><br class=""></div>
<br class="">______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
______________________________<wbr class="">_________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>