<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 28, 2017 at 3:18 AM, Xiaodi Wu <span dir="ltr"><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br><div class="gmail_quote"><span class=""><div dir="auto">On Tue, Nov 28, 2017 at 00:32 Kelvin Ma <<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 27, 2017 at 9:43 PM, Xiaodi Wu <span><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span>On Mon, Nov 27, 2017 at 5:56 PM, Kelvin Ma <span><<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Nov 27, 2017 at 4:21 PM, Xiaodi Wu <span><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><div><div>On Mon, Nov 27, 2017 at 15:46 Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>> wrote:<br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>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.</div></div></blockquote><div dir="auto"><br></div></div></div></div></span><div><div><div class="gmail_quote"><div dir="auto">Precisely, there is no guarantee of performance if you call these APIs with an array of Swift tuples.</div></div></div></div></blockquote><div><br></div></span><div>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.</div></div></div></div></blockquote><div><br></div></span><div>That's an entirely separate discussion.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote"><div>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, <i>tuples are our best option</i> since for some reason everyone is so opposed to the simple solution of baking <span style="font-family:monospace,monospace">vec2</span>, <span style="font-family:monospace,monospace">vec3</span>, … <span style="font-family:monospace,monospace">vec5</span> into the language and the generic integer <span style="font-family:monospace,monospace">Vector<Float, k></span> solution everyone wants likely isn’t going to materialize for the foreseeable future.</div></div></div></div></blockquote><div><br></div></span><div>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.</div></div></div></div></blockquote><div><br></div></div></div></div><div><div class="gmail_extra"><div class="gmail_quote"><div>“<i>write it in c and import it</i>” is <i>not</i> a solution,, it is a workaround.</div></div></div></div></blockquote><div dir="auto"><br></div></span><div dir="auto">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.</div><span class=""><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote"><div>plus since it lives across the module boundary, it’s effectively opaque to compiler optimizations.<br></div></div></div></div>
</blockquote></span></div></div><div dir="auto">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.</div><div dir="auto"><br></div>
</blockquote></div></div><div class="gmail_extra">you misunderstand the use-case. C and C APIs usually don’t show up in the story until the very last step, when you send the buffer to the drawing library (cairo, opengl, etc). all the stages that come before are swift and involve passing data between two swift interfaces.<br></div></div>