On Tue, Nov 28, 2017 at 00:32 Kelvin Ma <kelvin1...@gmail.com> wrote:
> 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. > Yes, that’s what we’re talking about here: workarounds to lack of a fixed layout type. I’m saying C is the “best option” workaround, not tuples. plus since it lives across the module boundary, it’s effectively opaque to > compiler optimizations. > What sorts of optimizations are you referring to? Recall that we are talking about taking a value and unsafe bitcasting for the purposes of calling other C APIs.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution