Great, thanks! (and thanks to Roman for fixing it already) -Chris
> On Aug 2, 2016, at 10:29 PM, Xiaodi Wu <[email protected]> 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 <[email protected] > <mailto:[email protected]>> wrote: > Awesome, thanks! What is the bug #? > > -Chris > >> On Aug 2, 2016, at 10:17 PM, Xiaodi Wu <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> 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 >>>> <[email protected] <mailto:[email protected]>> 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 >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> See >>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html >>>> >>>> <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 >>>> >>>> <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 >>>>> <[email protected] <mailto:[email protected]>> 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 >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
