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

[Kevin Ballard]

I've pushed my code (no tests) as
https://github.com/kballard/swift/commit/3b61da42986689d0f26323f88a49bf7d1175c717
if anyone wants to see it.

-Kevin Ballard

On Mon, Dec 7, 2015, at 10:04 PM, Kevin Ballard 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>*/