[swift-evolution] protocol-oriented integers (take 2)

[Max Moiseev]

Hi Xiaodi,

>  What is the performance penalty as compared to the existing operators?

First of all, I don’t have the concrete numbers unfortunately. But…
If we are talking about concrete types, there should be very little difference between the two smart and masking shifts.
For example, the following functions:

public func foo(x: UInt) -> UInt {
  return x >> 32
}

public func bar(x: UInt) -> UInt {
  return x &>> 32
}

Produce equivalent SIL and LLVM IR when compiled with optimizations. Moreover, if you change 32 to 100, then foo will become something like:

foo(x: UInt) { return 0 }

whereas bar will still call the llvm.shl.

> Beyond performance, what are the implications for migrating existing bit twiddling algorithms written in Swift 3?
Let’s take for example the ‘&>>” operator. There are 2 overloads: &>>(Self, Self) and &>><Other : BinaryInteger>(Self, Other)
(In Swift 3 there is only one version of >>, that takes both arguments of the same type.)

So, in an expression `x &>> 32`, compiler assumes 32 to have type Int (which is the default type for the integer literals) and prefer the heterogeneous overload. It might not be too bad, as I showed in examples above, but in order to increase chances of success you might want to specify an explicit type context, as in `x &>> (32 as TypeOfX)`.

As always, only concrete benchmarks will tell. We spent many hours optimizing the implementation for our existing benchmark suite.

Max

> On Jan 13, 2017, at 2:14 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> [Resending to list with original message removed for length.]
> 
> This is fantastic. Glad to see it take shape. Very neat and insightful to have trailingZeros on BinaryInteger but leadingZeros on FixedWidthInteger. A couple of questions on smart shifts: What is the performance penalty as compared to the existing operators? Beyond performance, what are the implications for migrating existing bit twiddling algorithms written in Swift 3?
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170113/c3d2ccbc/attachment.html>