Re: [swift-evolution] Swift 3.1 discussions, go?

2016-08-08 Thread Chris Lattner via swift-evolution 

> On Aug 7, 2016, at 8:14 AM, Karl  wrote:
> 
> 
>> On 3 Aug 2016, at 05:29, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> If you see such a drastic slowdown, then tat sounds like a critical 
>> regression that you found in the latest beta.  We would really appreciate a 
>> bug report (radar or jira) with a testcase!
>> 
>> -Chris
> 
> Aside: is there some way to export radars for fixed issues to jira? 

Not in bulk.  Customers of all sorts upload data to Apple’s radar system, and 
we can’t just make their confidential information public.

> Sometimes I see a bug-fix and it looks interesting, and I want to see if the 
> bug is related to something else that I’ve been looking at - but I can’t 
> because the commit just references a radar.

We did make a pass at publishing important radars to jira, but don’t have the 
bandwidth to do every single one.  If you have a specific question, feel free 
to ask about it on swift-dev.

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

2016-08-07 Thread Karl via swift-evolution 

> On 3 Aug 2016, at 05:29, Chris Lattner via swift-evolution 
>  wrote:
> 
> If you see such a drastic slowdown, then tat sounds like a critical 
> regression that you found in the latest beta.  We would really appreciate a 
> bug report (radar or jira) with a testcase!
> 
> -Chris

Aside: is there some way to export radars for fixed issues to jira? 

Sometimes I see a bug-fix and it looks interesting, and I want to see if the 
bug is related to something else that I’ve been looking at - but I can’t 
because the commit just references a radar.

Karl
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

2016-08-02 Thread Chris Lattner via swift-evolution 
Great, thanks!  (and thanks to Roman for fixing it already)

-Chris

> On Aug 2, 2016, at 10:29 PM, Xiaodi Wu  wrote:
> 
> SR-2247. Fixed by Roman Levenstein with PR #3924, which is already merged.
> 
> I've yet to test myself because the toolchain isn't building right on my 
> machine (lldb...) :/
> On Wed, Aug 3, 2016 at 00:19 Chris Lattner  > wrote:
> Awesome, thanks!  What is the bug #?  
> 
> -Chris
> 
>> On Aug 2, 2016, at 10:17 PM, Xiaodi Wu > > wrote:
>> 
>> Agreed! The bug has been filed, looked at by the wonderful people over at 
>> your HQ, and resolved--all faster than I can get the new toolchain to 
>> compile.
>> 
>> It looks like the operators && and || were missing a transparent annotation. 
>> I wonder if such issues are worth testing more systematically for primitive 
>> numeric types, and if so, how that might be done.
>> On Tue, Aug 2, 2016 at 22:29 Chris Lattner > > wrote:
>> If you see such a drastic slowdown, then tat sounds like a critical 
>> regression that you found in the latest beta.  We would really appreciate a 
>> bug report (radar or jira) with a testcase!
>> 
>> 
>> -Chris
>> 
>> On Aug 2, 2016, at 7:38 AM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>>> I'd like to echo Muse's point. Accelerate is no solution: it's not 
>>> available on Linux (and cross-platform numerics is very much essential for 
>>> the sciences--I assume engineering and finance as well); moreover, it 
>>> doesn't solve the issue of, as you point out, other kinds of math.
>>> 
>>> The appeal to me of Swift was that it promised a memory-safe-by-default 
>>> systems programming language, a compiled language with performance that can 
>>> be in the same ballpark as C. So while specialized libraries like BLAS can 
>>> speed up matrix algebra considerably, IMO, the same kinds of math that are 
>>> done in C or Go or Rust without calling BLAS should perform roughly 
>>> equivalently when ported to Swift. That it doesn't should be a bug, and the 
>>> workaround shouldn't have to be dropping down to or calling out to 
>>> libraries written in C or Fortran.
>>> 
>>> Recently, I discovered that a straightforward numerics algorithm that only 
>>> adds, divides, multiplies, and compares floating point values slowed down 
>>> five to ten *times* between preview 3 and preview 4. This was stunning--and 
>>> if performance ever was comparable to C before (I didn't check for this 
>>> particular function), I know for sure that it isn't anymore! Although I'm 
>>> confident that the underlying cause will be found, it does raise questions 
>>> as to the continued wisdom of writing even somewhat performance-sensitive 
>>> math in Swift.
>>> On Mon, Aug 1, 2016 at 20:04 Saagar Jha via swift-evolution 
>>> > wrote:
>>> Well, it depends on what kind of Math you’re trying to do. The Accelerate 
>>> framework is available if you need performance.
>>> 
>>> Saagar Jha
>>> 
>>> 
>>> 
 On Aug 1, 2016, at 18:01, Muse M via swift-evolution 
 > wrote:
 
 Have always wonder why Maths in Swift is slower than C and Go, it should 
 be address with priority if Swift is to be adopt for engineering, 
 financial and science industry.
 
 On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution 
 > wrote:
 See 
 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
  
 
 
 From what I understand, the discussion should stay focused on the main 
 topics for Swift 4 that Chris highlighted in 
 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
  
 
 
 I had several ideas in mind, but am postponing them for Swift 5, seeing 
 the schedule...
 
 
> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution 
> > wrote:
> 
> It was stated that 27th of July was the last date for proposal 
> acceptance, 29th of July was the last day for implementation, and 1th of 
> August should be the starting day of Swift 3.1-related discussions.
> Am I right? Should we begin?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
>

Re: [swift-evolution] Swift 3.1 discussions, go?

2016-08-02 Thread Xiaodi Wu via swift-evolution 
Agreed! The bug has been filed, looked at by the wonderful people over at
your HQ, and resolved--all faster than I can get the new toolchain to
compile.

It looks like the operators && and || were missing a transparent
annotation. I wonder if such issues are worth testing more systematically
for primitive numeric types, and if so, how that might be done.
On Tue, Aug 2, 2016 at 22:29 Chris Lattner  wrote:

> If you see such a drastic slowdown, then tat sounds like a critical
> regression that you found in the latest beta.  We would really appreciate a
> bug report (radar or jira) with a testcase!
>
>
> -Chris
>
> On Aug 2, 2016, at 7:38 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I'd like to echo Muse's point. Accelerate is no solution: it's not
> available on Linux (and cross-platform numerics is very much essential for
> the sciences--I assume engineering and finance as well); moreover, it
> doesn't solve the issue of, as you point out, other kinds of math.
>
> The appeal to me of Swift was that it promised a memory-safe-by-default
> systems programming language, a compiled language with performance that can
> be in the same ballpark as C. So while specialized libraries like BLAS can
> speed up matrix algebra considerably, IMO, the same kinds of math that are
> done in C or Go or Rust without calling BLAS should perform roughly
> equivalently when ported to Swift. That it doesn't should be a bug, and the
> workaround shouldn't have to be dropping down to or calling out to
> libraries written in C or Fortran.
>
> Recently, I discovered that a straightforward numerics algorithm that only
> adds, divides, multiplies, and compares floating point values slowed down
> five to ten *times* between preview 3 and preview 4. This was stunning--and
> if performance ever was comparable to C before (I didn't check for this
> particular function), I know for sure that it isn't anymore! Although I'm
> confident that the underlying cause will be found, it does raise questions
> as to the continued wisdom of writing even somewhat performance-sensitive
> math in Swift.
> On Mon, Aug 1, 2016 at 20:04 Saagar Jha via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Well, it depends on what kind of Math you’re trying to do. The Accelerate
>> framework is available if you need performance.
>>
>> Saagar Jha
>>
>>
>>
>> On Aug 1, 2016, at 18:01, Muse M via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Have always wonder why Maths in Swift is slower than C and Go, it should
>> be address with priority if Swift is to be adopt for engineering, financial
>> and science industry.
>>
>> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> See
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>>>
>>> From what I understand, the discussion should stay focused on the main
>>> topics for Swift 4 that Chris highlighted in
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>>>
>>> I had several ideas in mind, but am postponing them for Swift 5, seeing
>>> the schedule...
>>>
>>>
>>> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> It was stated that 27th of July was the last date for proposal
>>> acceptance, 29th of July was the last day for implementation, and 1th of
>>> August should be the starting day of Swift 3.1-related discussions.
>>> Am I right? Should we begin?
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

2016-08-02 Thread Chris Lattner via swift-evolution 
If you see such a drastic slowdown, then tat sounds like a critical regression 
that you found in the latest beta.  We would really appreciate a bug report 
(radar or jira) with a testcase!

-Chris

> On Aug 2, 2016, at 7:38 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I'd like to echo Muse's point. Accelerate is no solution: it's not available 
> on Linux (and cross-platform numerics is very much essential for the 
> sciences--I assume engineering and finance as well); moreover, it doesn't 
> solve the issue of, as you point out, other kinds of math.
> 
> The appeal to me of Swift was that it promised a memory-safe-by-default 
> systems programming language, a compiled language with performance that can 
> be in the same ballpark as C. So while specialized libraries like BLAS can 
> speed up matrix algebra considerably, IMO, the same kinds of math that are 
> done in C or Go or Rust without calling BLAS should perform roughly 
> equivalently when ported to Swift. That it doesn't should be a bug, and the 
> workaround shouldn't have to be dropping down to or calling out to libraries 
> written in C or Fortran.
> 
> Recently, I discovered that a straightforward numerics algorithm that only 
> adds, divides, multiplies, and compares floating point values slowed down 
> five to ten *times* between preview 3 and preview 4. This was stunning--and 
> if performance ever was comparable to C before (I didn't check for this 
> particular function), I know for sure that it isn't anymore! Although I'm 
> confident that the underlying cause will be found, it does raise questions as 
> to the continued wisdom of writing even somewhat performance-sensitive math 
> in Swift.
>> On Mon, Aug 1, 2016 at 20:04 Saagar Jha via swift-evolution 
>>  wrote:
>> Well, it depends on what kind of Math you’re trying to do. The Accelerate 
>> framework is available if you need performance.
>> 
>> Saagar Jha
>> 
>> 
>> 
>>> On Aug 1, 2016, at 18:01, Muse M via swift-evolution 
>>>  wrote:
>>> 
>>> Have always wonder why Maths in Swift is slower than C and Go, it should be 
>>> address with priority if Swift is to be adopt for engineering, financial 
>>> and science industry.
>>> 
>>> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution 
>>>  wrote:
 See 
 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
 
 From what I understand, the discussion should stay focused on the main 
 topics for Swift 4 that Chris highlighted in 
 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
 
 I had several ideas in mind, but am postponing them for Swift 5, seeing 
 the schedule...
 
 
> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> It was stated that 27th of July was the last date for proposal 
> acceptance, 29th of July was the last day for implementation, and 1th of 
> August should be the starting day of Swift 3.1-related discussions.
> Am I right? Should we begin?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

2016-08-02 Thread Michael Peternell via swift-evolution 
Haha ;)

1) Maybe converting the algorithm into a tail-recursive form should be the 
first optimization?

func factorial(_ n: Int, multipliedBy m: Int = 1) -> Int {
return n <= 1 ? m : factorial(n-1, multipliedBy: m*n)
}

2) Using a non-recursive algorithm would improve performance even more, I guess.

3) The third is maybe to use precalculation or an efficient algorithm that 
doesn't call `factorial` that often. (Assuming that your use-case isn't just 
calculating factorial numbers for fun.) (E.g. if you try to calculate (52 over 
3) by using the formula (52!/(49!*3!)) it will be inefficient, and btw it will 
crash, because 52! does not fit into an Int. The efficient way is 52*51/2*50/3 
("*","/": same precedence, left-associative.)) On my 64-bit computer I cannot 
go beyond 20!, factorial(21) gives an EXC_BAD_INSTRUCTION a.k.a. integer 
overflow. There is no point in optimizing 20!, and there certainly is no point 
in optimizing 40!, at least with Int's.

There is really no point in optimizing that anymore beyond that. A silly 
SIMD-optimized algorithm is always worse than a well-designed algorithm 
compiled with -O0. If you do standard optimization techniques first, the 
advantage of SIMD-instructions for factorial become unmeasurable ;)

However, I agree that special optimizations for numeric computations (SIMD and 
other extension) would be cool..

-Michael

> Am 02.08.2016 um 18:37 schrieb Muse M via swift-evolution 
> :
> 
> I'm concern if simd could improve factorials code and faster timing.
> 
> import simd
> func factorial(n: Int) -> Int {
> return n < 1 ? 1 : n * factorial(n: n - 1)
> }
> print(factorial(n: 40))
> 
> 
> On Wed, Aug 3, 2016 at 12:00 AM, Charlie Monroe  
> wrote:
> That's a good point. :)
> 
>> On Aug 2, 2016, at 5:55 PM, Xiaodi Wu  wrote:
>> 
>> I'm going to guess, since Musa mentioned science and engineering, that a 
>> good chunk of that work is floating point :)
>> 
>> 
>> On Tue, Aug 2, 2016 at 10:41 AM, Charlie Monroe via swift-evolution 
>>  wrote:
>> Are you using the variants of operators without overflow check? I.e.
>> 
>> let num = a &+ b // [1]
>> 
>> [1] 
>> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AdvancedOperators.html
>> 
>> 
>> 
>>> On Aug 2, 2016, at 3:01 AM, Muse M  wrote:
>>> 
>>> Have always wonder why Maths in Swift is slower than C and Go, it should be 
>>> address with priority if Swift is to be adopt for engineering, financial 
>>> and science industry.
>>> 
>>> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution 
>>>  wrote:
>>> See 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>>> 
>>> From what I understand, the discussion should stay focused on the main 
>>> topics for Swift 4 that Chris highlighted in 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>>> 
>>> I had several ideas in mind, but am postponing them for Swift 5, seeing the 
>>> schedule...
>>> 
>>> 
 On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution 
  wrote:
 
 It was stated that 27th of July was the last date for proposal acceptance, 
 29th of July was the last day for implementation, and 1th of August should 
 be the starting day of Swift 3.1-related discussions.
 Am I right? Should we begin?
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

2016-08-02 Thread Muse M via swift-evolution 
I'm concern if simd could improve factorials code and faster timing.

import simd
func factorial(n: Int) -> Int {
return n < 1 ? 1 : n * factorial(n: n - 1)
}
print(factorial(n: 40))

On Wed, Aug 3, 2016 at 12:00 AM, Charlie Monroe 
wrote:

> That's a good point. :)
>
> On Aug 2, 2016, at 5:55 PM, Xiaodi Wu  wrote:
>
> I'm going to guess, since Musa mentioned science and engineering, that a
> good chunk of that work is floating point :)
>
>
> On Tue, Aug 2, 2016 at 10:41 AM, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Are you using the variants of operators without overflow check? I.e.
>>
>> let num = a &+ b // [1]
>>
>> [1]
>> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AdvancedOperators.html
>>
>>
>>
>> On Aug 2, 2016, at 3:01 AM, Muse M  wrote:
>>
>> Have always wonder why Maths in Swift is slower than C and Go, it should
>> be address with priority if Swift is to be adopt for engineering, financial
>> and science industry.
>>
>> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> See
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>>>
>>> From what I understand, the discussion should stay focused on the main
>>> topics for Swift 4 that Chris highlighted in
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>>>
>>> I had several ideas in mind, but am postponing them for Swift 5, seeing
>>> the schedule...
>>>
>>>
>>> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> It was stated that 27th of July was the last date for proposal
>>> acceptance, 29th of July was the last day for implementation, and 1th of
>>> August should be the starting day of Swift 3.1-related discussions.
>>> Am I right? Should we begin?
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

2016-08-02 Thread Charlie Monroe via swift-evolution 
That's a good point. :)

> On Aug 2, 2016, at 5:55 PM, Xiaodi Wu  wrote:
> 
> I'm going to guess, since Musa mentioned science and engineering, that a good 
> chunk of that work is floating point :)
> 
> 
> On Tue, Aug 2, 2016 at 10:41 AM, Charlie Monroe via swift-evolution 
> > wrote:
> Are you using the variants of operators without overflow check? I.e.
> 
> let num = a &+ b // [1]
> 
> [1] 
> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AdvancedOperators.html
>  
> 
> 
> 
> 
>> On Aug 2, 2016, at 3:01 AM, Muse M > > wrote:
>> 
>> Have always wonder why Maths in Swift is slower than C and Go, it should be 
>> address with priority if Swift is to be adopt for engineering, financial and 
>> science industry.
>> 
>> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution 
>> > wrote:
>> See 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>>  
>> 
>> 
>> From what I understand, the discussion should stay focused on the main 
>> topics for Swift 4 that Chris highlighted in 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>>  
>> 
>> 
>> I had several ideas in mind, but am postponing them for Swift 5, seeing the 
>> schedule...
>> 
>> 
>>> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution 
>>> > wrote:
>>> 
>>> It was stated that 27th of July was the last date for proposal acceptance, 
>>> 29th of July was the last day for implementation, and 1th of August should 
>>> be the starting day of Swift 3.1-related discussions.
>>> Am I right? Should we begin?
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> 
>> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

2016-08-02 Thread Xiaodi Wu via swift-evolution 
I'm going to guess, since Musa mentioned science and engineering, that a
good chunk of that work is floating point :)


On Tue, Aug 2, 2016 at 10:41 AM, Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

> Are you using the variants of operators without overflow check? I.e.
>
> let num = a &+ b // [1]
>
> [1]
> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AdvancedOperators.html
>
>
>
> On Aug 2, 2016, at 3:01 AM, Muse M  wrote:
>
> Have always wonder why Maths in Swift is slower than C and Go, it should
> be address with priority if Swift is to be adopt for engineering, financial
> and science industry.
>
> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> See
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>>
>> From what I understand, the discussion should stay focused on the main
>> topics for Swift 4 that Chris highlighted in
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>>
>> I had several ideas in mind, but am postponing them for Swift 5, seeing
>> the schedule...
>>
>>
>> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> It was stated that 27th of July was the last date for proposal
>> acceptance, 29th of July was the last day for implementation, and 1th of
>> August should be the starting day of Swift 3.1-related discussions.
>> Am I right? Should we begin?
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

2016-08-02 Thread Charlie Monroe via swift-evolution 
Are you using the variants of operators without overflow check? I.e.

let num = a &+ b // [1]

[1] 
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AdvancedOperators.html
 




> On Aug 2, 2016, at 3:01 AM, Muse M  wrote:
> 
> Have always wonder why Maths in Swift is slower than C and Go, it should be 
> address with priority if Swift is to be adopt for engineering, financial and 
> science industry.
> 
> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution 
> > wrote:
> See 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>  
> 
> 
> From what I understand, the discussion should stay focused on the main topics 
> for Swift 4 that Chris highlighted in 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>  
> 
> 
> I had several ideas in mind, but am postponing them for Swift 5, seeing the 
> schedule...
> 
> 
>> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution 
>> > wrote:
>> 
>> It was stated that 27th of July was the last date for proposal acceptance, 
>> 29th of July was the last day for implementation, and 1th of August should 
>> be the starting day of Swift 3.1-related discussions.
>> Am I right? Should we begin?
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

2016-08-02 Thread Xiaodi Wu via swift-evolution 
Already filed as SR-2247, complete with XCode project and performance test
:)

Jordan Rose was kind enough to duplicate it into Radar as well.

On Tue, Aug 2, 2016 at 09:44 Mark Lacey  wrote:

>
> On Aug 2, 2016, at 07:38, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I'd like to echo Muse's point. Accelerate is no solution: it's not
> available on Linux (and cross-platform numerics is very much essential for
> the sciences--I assume engineering and finance as well); moreover, it
> doesn't solve the issue of, as you point out, other kinds of math.
>
> The appeal to me of Swift was that it promised a memory-safe-by-default
> systems programming language, a compiled language with performance that can
> be in the same ballpark as C. So while specialized libraries like BLAS can
> speed up matrix algebra considerably, IMO, the same kinds of math that are
> done in C or Go or Rust without calling BLAS should perform roughly
> equivalently when ported to Swift. That it doesn't should be a bug, and the
> workaround shouldn't have to be dropping down to or calling out to
> libraries written in C or Fortran.
>
> Recently, I discovered that a straightforward numerics algorithm that only
> adds, divides, multiplies, and compares floating point values slowed down
> five to ten *times* between preview 3 and preview 4.
>
>
> Can you open a bug at bugs.swift.org and include a test case that can be
> compiled and executed to demonstrate the issue?
>
> Mark
>
> This was stunning--and if performance ever was comparable to C before (I
> didn't check for this particular function), I know for sure that it isn't
> anymore! Although I'm confident that the underlying cause will be found, it
> does raise questions as to the continued wisdom of writing even somewhat
> performance-sensitive math in Swift.
> On Mon, Aug 1, 2016 at 20:04 Saagar Jha via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Well, it depends on what kind of Math you’re trying to do. The Accelerate
>> framework is available if you need performance.
>>
>> Saagar Jha
>>
>>
>>
>> On Aug 1, 2016, at 18:01, Muse M via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Have always wonder why Maths in Swift is slower than C and Go, it should
>> be address with priority if Swift is to be adopt for engineering, financial
>> and science industry.
>>
>> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> See
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>>>
>>> From what I understand, the discussion should stay focused on the main
>>> topics for Swift 4 that Chris highlighted in
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>>>
>>> I had several ideas in mind, but am postponing them for Swift 5, seeing
>>> the schedule...
>>>
>>>
>>> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> It was stated that 27th of July was the last date for proposal
>>> acceptance, 29th of July was the last day for implementation, and 1th of
>>> August should be the starting day of Swift 3.1-related discussions.
>>> Am I right? Should we begin?
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

2016-08-02 Thread Xiaodi Wu via swift-evolution 
I'd like to echo Muse's point. Accelerate is no solution: it's not
available on Linux (and cross-platform numerics is very much essential for
the sciences--I assume engineering and finance as well); moreover, it
doesn't solve the issue of, as you point out, other kinds of math.

The appeal to me of Swift was that it promised a memory-safe-by-default
systems programming language, a compiled language with performance that can
be in the same ballpark as C. So while specialized libraries like BLAS can
speed up matrix algebra considerably, IMO, the same kinds of math that are
done in C or Go or Rust without calling BLAS should perform roughly
equivalently when ported to Swift. That it doesn't should be a bug, and the
workaround shouldn't have to be dropping down to or calling out to
libraries written in C or Fortran.

Recently, I discovered that a straightforward numerics algorithm that only
adds, divides, multiplies, and compares floating point values slowed down
five to ten *times* between preview 3 and preview 4. This was stunning--and
if performance ever was comparable to C before (I didn't check for this
particular function), I know for sure that it isn't anymore! Although I'm
confident that the underlying cause will be found, it does raise questions
as to the continued wisdom of writing even somewhat performance-sensitive
math in Swift.
On Mon, Aug 1, 2016 at 20:04 Saagar Jha via swift-evolution <
swift-evolution@swift.org> wrote:

> Well, it depends on what kind of Math you’re trying to do. The Accelerate
> framework is available if you need performance.
>
> Saagar Jha
>
>
>
> On Aug 1, 2016, at 18:01, Muse M via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Have always wonder why Maths in Swift is slower than C and Go, it should
> be address with priority if Swift is to be adopt for engineering, financial
> and science industry.
>
> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> See
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>>
>> From what I understand, the discussion should stay focused on the main
>> topics for Swift 4 that Chris highlighted in
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>>
>> I had several ideas in mind, but am postponing them for Swift 5, seeing
>> the schedule...
>>
>>
>> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> It was stated that 27th of July was the last date for proposal
>> acceptance, 29th of July was the last day for implementation, and 1th of
>> August should be the starting day of Swift 3.1-related discussions.
>> Am I right? Should we begin?
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

2016-08-01 Thread Saagar Jha via swift-evolution 
Well, it depends on what kind of Math you’re trying to do. The Accelerate 
framework is available if you need performance.
Saagar Jha



> On Aug 1, 2016, at 18:01, Muse M via swift-evolution 
>  wrote:
> 
> Have always wonder why Maths in Swift is slower than C and Go, it should be 
> address with priority if Swift is to be adopt for engineering, financial and 
> science industry.
> 
> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution 
> > wrote:
> See 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>  
> 
> 
> From what I understand, the discussion should stay focused on the main topics 
> for Swift 4 that Chris highlighted in 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>  
> 
> 
> I had several ideas in mind, but am postponing them for Swift 5, seeing the 
> schedule...
> 
> 
>> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution 
>> > wrote:
>> 
>> It was stated that 27th of July was the last date for proposal acceptance, 
>> 29th of July was the last day for implementation, and 1th of August should 
>> be the starting day of Swift 3.1-related discussions.
>> Am I right? Should we begin?
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

2016-08-01 Thread Muse M via swift-evolution 
Have always wonder why Maths in Swift is slower than C and Go, it should be
address with priority if Swift is to be adopt for engineering, financial
and science industry.

On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

> See
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>
> From what I understand, the discussion should stay focused on the main
> topics for Swift 4 that Chris highlighted in
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>
> I had several ideas in mind, but am postponing them for Swift 5, seeing
> the schedule...
>
>
> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It was stated that 27th of July was the last date for proposal acceptance,
> 29th of July was the last day for implementation, and 1th of August should
> be the starting day of Swift 3.1-related discussions.
> Am I right? Should we begin?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

2016-08-01 Thread Charlie Monroe via swift-evolution 
See 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
 


>From what I understand, the discussion should stay focused on the main topics 
>for Swift 4 that Chris highlighted in 
>https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
> 
>

I had several ideas in mind, but am postponing them for Swift 5, seeing the 
schedule...


> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> It was stated that 27th of July was the last date for proposal acceptance, 
> 29th of July was the last day for implementation, and 1th of August should be 
> the starting day of Swift 3.1-related discussions.
> Am I right? Should we begin?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Swift 3.1 discussions, go?

2016-08-01 Thread Anton Zhilin via swift-evolution 
It was stated that 27th of July was the last date for proposal acceptance,
29th of July was the last day for implementation, and 1th of August should
be the starting day of Swift 3.1-related discussions.
Am I right? Should we begin?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution