<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Great, thanks! (and thanks to Roman for fixing it already)<div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 2, 2016, at 10:29 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">SR-2247. Fixed by Roman Levenstein with PR #3924, which is already merged.<br class=""><br class="">I've yet to test myself because the toolchain isn't building right on my machine (lldb...) :/<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Aug 3, 2016 at 00:19 Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Awesome, thanks! What is the bug #? </div><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">-Chris</div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 2, 2016, at 10:17 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class=""><div class="">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.<br class=""><br class="">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.<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Aug 2, 2016 at 22:29 Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank" class="">clattner@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class="">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!</div></div><div dir="auto" class=""><div class=""><br class=""><br class=""><div class="">-Chris</div></div></div><div dir="auto" class=""><div class=""><br class="">On Aug 2, 2016, at 7:38 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">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.<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Aug 1, 2016 at 20:04 Saagar Jha via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Well, it depends on what kind of Math you’re trying to do. The Accelerate framework is available if you need performance.</div><div style="word-wrap:break-word" class=""><br class=""><div class="">
<div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word" class="">Saagar Jha<br class=""><br class=""><br class=""></div>
</div></div><div style="word-wrap:break-word" class="">
<br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 1, 2016, at 18:01, Muse M via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">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.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">See <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html" target="_blank" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html</a><div class=""><br class=""></div><div class="">From what I understand, the discussion should stay focused on the main topics for Swift 4 that Chris highlighted in <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html" target="_blank" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html</a></div><div class=""><br class=""></div><div class="">I had several ideas in mind, but am postponing them for Swift 5, seeing the schedule...</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><span class=""><div class="">On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""></span><div class=""><span class=""><div dir="ltr" class="">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.<div class="">Am I right? Should we begin?<br class=""></div></div></span>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></blockquote></div>
</div></blockquote></div><br class=""></div></div></blockquote></div>
</div></blockquote></div><br class=""></div></body></html>