[swift-evolution] Swift 3.1 discussions, go?

Xiaodi Wu xiaodi.wu at gmail.com
Tue Aug 2 09:38:50 CDT 2016


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160802/5853e887/attachment.html>


More information about the swift-evolution mailing list