[swift-evolution] Swift 3.1 discussions, go?
Xiaodi Wu
xiaodi.wu at gmail.com
Tue Aug 2 10:37:50 CDT 2016
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 <mark.lacey at apple.com> wrote:
>
> On Aug 2, 2016, at 07:38, 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.
>
>
> 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 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/20160802/8daf8b8c/attachment.html>
More information about the swift-evolution
mailing list