> On Aug 3, 2017, at 7:20 AM, Tino Heth <2...@gmx.de> wrote:
>
> Hi Daryle,
>
> I think we agree a lot on the importance of fixed-size arrays, but have a
> different opinion on which aspect is the most valuable… (so we now only have
> to agree that mine is better ;-) ;-)
> My motivation for FSA is safety and convenience:
> I want to iterate over C arrays in a straightforward way, but primarily, I
> don't want to accidentally multiply a vector of size 3 with a 2×2 matrix.
Data modeling is important for me too. That’s why the proposal includes
multi-dimensionality and why I didn’t just jam in Collection support. We don’t
want to add conformance then find out that was a mistake.
> Of course, fast is cool, but I don't expect to suffer from bad performance
> because of implementation details like how, where and when memory allocation
> happens.
> Your focus, on the other hand, seems to be performance:
> You don't want to give guarantees about the order because of (hypothetical?)
> optimisations that could be blocked by that, and avoid initialisation
> overhead.
I also don’t want to block parallel/vector processing.
let a: @vector [4; Int] = //…
let b: @vector [4; Int] = //…
var c: @vector [4; Int] = //…
//…
loop: for i in a {
c[ #indexOf(loop) ] = i * b[ #indexOf(loop) ]
}
//…
I want the compiler to potentially be able to see that the elements are being
computed in formation and use vector-unit instructions instead of serial
processing.
> You brought "withUnsafeFlattening" to the table to add convenience, but I
> think that is the wrong direction:
> Safe should be default, and it's quite common that you have to live with
> "unsafe" when you need "fast".
The name has “Unsafe” because the Collection type used, UnsafeBufferPointer,
does. I don’t know enough about what makes the existing “Unsafe” API that way
for the flattening function to declared “safe”. It could be safe for all I know.
A substitute Collection-access function besides “withUnsafeFlattening” would
either copy the elements (i.e. be inefficient, especially for large arrays) or
somehow secretly maintain a reference to the array in memory. The latter would
then be “withUnsafeFlattening” with a prettier name.
My first reason for “withUnsafeFlattening” was to allow API to use any FSA of a
given element type, no matter the shape.
> As you don't want to confirm to Sequence at all, it shouldn't bother you if
> the iterator sacrifices a tiny bit of performance in exchange for a reliable
> order, and when you really need piecemeal initialisation, you could take a
> FSA-Variant that skips initialisation of elements.
> Of course, that wouldn't be ideal, and there should be an "Unsafe" in the
> name of that type — but I don't think tuple-like delayed initialisation would
> help when solving real-world problems:
> The "x.0 = 0; x.1 = 1" case is trivial and can be done with normal init, and
> when this isn't enough, you most likely loose all guarantees because you use
> a loop to fill that array*.
Using a loop for array initialization is why I suggested we should look into
run-time DI, which should be kept to restricted circumstances.
> I really appreciate the effort you spend for digging into the low-level
> details, and hope that we end up with a draft that satisfies your use case.
>
> - Tino
>
> * There are actually cases where you want to compute the value of one element
> based on another one, but that might as well be an indicator that you are
> better off with a tuple, instead of using an array.
>
>>> So would you say Dictionary shouldn't conform to Collection either?
>>> Just because a type conforms to a protocol doesn't mean it can't add its
>>> own methods on top.
>>
>> But the FSA interface and the Sequence/Collection interface would be very
>> similar, basically competing, leading to a schizophrenic interface. Since
>> another part of the overall FSA interface implements Collection, just use
>> that.
> Yes, I can't argue against the claim that Collection sometimes feels a little
> bit odd :-( — but it is what it is, and maybe there will be improvements in
> the future that could take into account the experience with FSA.
>
>>> Swift has one-dimensional arrays, and they support Collection... this may
>>> sound like nitpicking that only works because there is no explicit
>>> "fixed-size" in you statement, but feel free to prove me wrong for FSAs.
>>
>> Yes, I meant FSAs, not both them and Array; it’s long-winded to keep adding
>> the “fixed-size” part.
> So we do agree that there is no fundamental reason that stops FSAs from being
> collections? ;-)
Besides that they can’t be Sequences, unless you throw away allowing
parallel/vector processing in the future. (That can’t be bolted onto Version 2,
since committing to Sequence means you committed to single-thread iteration.)
Just found out that C++ 17 (optionally) adds parallel/vector processing to its
for-loops. I guess I caught on to a trend.
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
