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
