On Mon, Nov 27, 2017 at 9:43 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> On Mon, Nov 27, 2017 at 5:56 PM, Kelvin Ma <kelvin1...@gmail.com> wrote: > >> >> >> On Mon, Nov 27, 2017 at 4:21 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >> >>> On Mon, Nov 27, 2017 at 15:46 Taylor Swift <kelvin1...@gmail.com> wrote: >>> >>>> they use packed buffers of floats, which for type safety are better >>>> rebound to a structured type. right now (Float, Float, Float) works because >>>> the tuple is laid out contiguously and the GPU can’t tell the difference >>>> but it’s not guaranteed. also you’re ignoring all the CPU stages that occur >>>> before anything even gets sent to the GPU. >>>> >>> >>> Precisely, there is no guarantee of performance if you call these APIs >>> with an array of Swift tuples. >>> >> >> which is exactly why i support a dedicated language-level vector type >> which guarantees contiguous, fixed storage, and which the compiler knows >> about so it can vectorize operations on them. >> > > That's an entirely separate discussion. > > >> tuples right now try to fill too many roles and that makes life difficult >> for both the compiler and the programmer. however, until then, we need some >> kind of common, fixed layout currency type for vector data, and by >> implementation-detail, *tuples are our best option* since for some >> reason everyone is so opposed to the simple solution of baking vec2, vec3, >> … vec5 into the language and the generic integer Vector<Float, k> >> solution everyone wants likely isn’t going to materialize for the >> foreseeable future. >> > > Disagree. If you want a particular memory layout, define your type in C. > Swift's interop story is very good, and your type will have a fixed layout > forever. > “*write it in c and import it*” is *not* a solution,, it is a workaround. plus since it lives across the module boundary, it’s effectively opaque to compiler optimizations.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
