[swift-evolution] Swift 3.1 discussions, go?

[Xiaodi Wu]

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 at 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 at 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 at 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 at 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 at 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 at 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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160803/0594c815/attachment.html>