[swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types
xiaodi.wu at gmail.com
Tue Nov 28 03:18:08 CST 2017
On Tue, Nov 28, 2017 at 00:32 Kelvin Ma <kelvin13ma at gmail.com> wrote:
> On Mon, Nov 27, 2017 at 9:43 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>> On Mon, Nov 27, 2017 at 5:56 PM, Kelvin Ma <kelvin13ma at gmail.com> wrote:
>>> On Mon, Nov 27, 2017 at 4:21 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>> On Mon, Nov 27, 2017 at 15:46 Taylor Swift <kelvin13ma at gmail.com>
>>>>> 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
> “*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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution