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

[Kevin Ballard]

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>*/