Swift 3.1 discussions, go?


(Anton Zhilin) #1

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?


(Charlie Monroe) #2

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


(Muse M) #3

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


(Saagar Jha) #4

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 <mailto: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 <mailto: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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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


(Xiaodi Wu) #5

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


(Charlie Monroe) #6

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 <james.lei65@gmail.com> 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 <mailto: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 <mailto: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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Mark Lacey) #7

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

···

On Aug 2, 2016, at 07:38, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

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


(Xiaodi Wu) #8

I'm going to guess, since Musa mentioned science and engineering, that a
good chunk of that work is floating point :slight_smile:

···

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 <james.lei65@gmail.com> 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


(Xiaodi Wu) #9

Already filed as SR-2247, complete with XCode project and performance test
:slight_smile:

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

···

On Tue, Aug 2, 2016 at 09:44 Mark Lacey <mark.lacey@apple.com> 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


(Charlie Monroe) #10

That's a good point. :slight_smile:

···

On Aug 2, 2016, at 5:55 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

I'm going to guess, since Musa mentioned science and engineering, that a good chunk of that work is floating point :slight_smile:

On Tue, Aug 2, 2016 at 10:41 AM, Charlie Monroe via swift-evolution <swift-evolution@swift.org <mailto: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 <james.lei65@gmail.com <mailto:james.lei65@gmail.com>> 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 <mailto: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 <mailto: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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #11

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


(Muse M) #12

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 <charlie@charliemonroe.net> wrote:

That's a good point. :slight_smile:

On Aug 2, 2016, at 5:55 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

I'm going to guess, since Musa mentioned science and engineering, that a
good chunk of that work is floating point :slight_smile:

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 <james.lei65@gmail.com> 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


(Xiaodi Wu) #13

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 <clattner@apple.com> 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


(Karl) #14

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

···

On 3 Aug 2016, at 05:29, Chris Lattner via swift-evolution <swift-evolution@swift.org> 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


(Chris Lattner) #15

Great, thanks! (and thanks to Roman for fixing it already)

-Chris

···

On Aug 2, 2016, at 10:29 PM, Xiaodi Wu <xiaodi.wu@gmail.com> 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 <clattner@apple.com <mailto:clattner@apple.com>> wrote:
Awesome, thanks! What is the bug #?

-Chris

On Aug 2, 2016, at 10:17 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> 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 <clattner@apple.com <mailto:clattner@apple.com>> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Michael Peternell) #16

Haha :wink:

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 :wink:

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 <swift-evolution@swift.org>:

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 <charlie@charliemonroe.net> wrote:
That's a good point. :slight_smile:

On Aug 2, 2016, at 5:55 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

I'm going to guess, since Musa mentioned science and engineering, that a good chunk of that work is floating point :slight_smile:

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 <james.lei65@gmail.com> 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


(Chris Lattner) #17

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

···

On Aug 7, 2016, at 8:14 AM, Karl <razielim@gmail.com> wrote:

On 3 Aug 2016, at 05:29, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote: