[swift-evolution] Proposal: Implement == and < for tuples where possible, up to some high arity

[plx]

FWIW — and without trying to address why the absolute size is what it is — at least in my experience, "generic families” like “== for tuples of length 2 , … n“ seem to require size that reliably grows as O(n^2). 

On the one hand, this growth pattern doesn't actually seem *surprising* (think about it); but, on the other hand, I’d also be curious to know if the ABI changes for Swift 3 will have any significant impact on the *absolute* size of such constructs (or if other features will provide other solutions).

> On Dec 8, 2015, at 12:04 AM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Code size turns out to be much higher than expected.
> 
> When implementing ==, !=, <, <=, >, and >= for tuples of arities 2–6, I
> end up with a 1.4% increase in libswiftCore.dylib code size:
> 
>                                   Section       Old       New  Percent
> libswiftCore.dylib                  __text:  3198165   3242853   -1.4%
> libswiftCore.dylib                  __text:  2939740   2980844   -1.4%
> 
> (or about 43.6KiB)
> 
> After increasing it to go up to arity 12, it reaches a 5.3–5.5%
> increase:
> 
>                                   Section       Old       New  Percent
> libswiftCore.dylib                  __text:  3198165   3373349   -5.5%
> libswiftCore.dylib                  __text:  2939740   3096140   -5.3%
> 
> (171KiB for macosx, 152.7KiB for iphoneos)
> 
> I'm surprised at how large this is. 43.6KiB for arities 2–6 alone seems
> bad enough, but up to 171KiB for arities 2–12? Where did all that code
> size come from!
> 
> Note: this is compiling as Ninja-ReleaseAssert.
> 
> Based on this, I'm inclined to submit the change with arities 2–6, but
> if anyone has any idea why this results in so much code size I'd love to
> hear it.
> 
> -Kevin Ballard
> 
> On Mon, Dec 7, 2015, at 12:32 PM, Dmitri Gribenko wrote:
>> On Mon, Dec 7, 2015 at 12:22 PM, Kevin Ballard <kevin at sb.org> wrote:
>>> On Mon, Dec 7, 2015, at 12:01 PM, Dmitri Gribenko wrote:
>>> 
>>> On Mon, Dec 7, 2015 at 11:48 AM, Kevin Ballard via swift-evolution
>>> <swift-evolution at swift.org> wrote:
>>> Good question. What's the best way to measure this? File size of
>>> build/$target/swift-macosx-x86_64/lib/swift/macosx/libswiftCore.dylib (does
>>> that even include generic functions)? Or the x86_64/libswiftCore.dylib from
>>> the same folder (what's the difference)? Or x86_64/Swift.swiftmodule?
>>> Something else?
>> 
>> Use utils/cmpcodesize.
>> 
>> The swift-macosx-x86_64/lib/swift/<target>/libswiftCore.dylib dylibs
>> are fat ones, the dylib nested inside the architecture directory is a
>> regular one.  Please also measure for iOS (to build those, run
>> build-script with -i).
>> 
>>> I personally don't see a point in going as high as 12 tuple elements.  About
>>> 4 or 5 makes sense to me.  Given that Swift does not have variadic generics
>>> right now, these long tuples have to be defined by someone manually.  If one
>>> is defining a tuple that is that long, I'd argue that they should be using a
>>> custom struct instead.
>>> 
>>> 
>>> Depends on how much code size it is. I'd rather err on the side of defining
>>> it for a higher arity tuple than we expect people to actually use in
>>> practice. Just because it's probably a good idea to not point more than a
>>> handful of elements in a tuple doesn't mean people will actually stick to
>>> that, and it's surprising behavior to have == suddenly break because you
>>> added one more (Equatable) value to the tuple. As an example, my coworker
>>> recently wrote some code that uses a tuple of 7 elements (as a typedef). It
>>> probably should have been a struct, but I think it was originally defined
>>> with just 3 or 4 elements and sprouted the others as he worked on it.
>>> Granted, this particular tuple wouldn't actually support ==, but I'm sure
>>> others have written similarly long tuples.
>>> 
>>> I'll probably prototype this some time today, and I can produce some
>>> measurements of code size at different arities (if I can figure out the best
>>> way to measure that).
>> 
>> I can see that.  Definitely depends on the code size, though!
>> 
>> Dmitri
>> 
>> -- 
>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution