BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Swift并不像苹果说的那么快:第一次基准测试

| 作者 Sergio De Simone 关注 12 他的粉丝 ,译者 梅雪松 关注 0 他的粉丝 发布于 2014年6月14日. 估计阅读时间: 3 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

性能是苹果声称新编程语言Swift将带给OS X和iOS开发人员的好处之一。然而,由独立开发者执行的第一次实验和基准测试显示,Swift在某些场景的性能并不如人意。

开发人员Jukka Suomela在Stack Overflow发表了一篇帖子说明他的发现。当用Swift实现一个算法时,他注意到其性能非常差。深入分析后,Jukka最终发现代码的主要瓶颈来自一个数组排序这样的简单任务。

事实上,Swift对100万个随机整数的数组进行排序,需要耗时6秒,而C++只用了0.06秒,Python为0.6秒。这些测试使用的是-O3编译优化级别,这是Xcode发布构建时常用的级别。Jukka说,如果禁用所有编译优化,即对应于Xcode调试构建的-O0,上述测试用了88秒。

Stack Overflow上回复该帖的其他开发人员证实了Jukka的发现。开发人员sjeohp用Swift实现快速排序算法时,发现如果不启用编译优化(-Onone)会比C慢1000倍。另一方面,他发现当强制积极的编译优化(-Ofast)时,Swift比C稍快。Stack Overflow的另一个帖子描述了图像处理测试,也强调了类似的研究结果。

根据LLVM文档,积极优化忽略了严谨的标准规范。-Ofast启用了所有-O3优化并开启了-ffast-math,后者放宽了IEEE或ISO的数学函数规范,可能导致那些应该具有规范保证的程序产生不正确的输出。此外,-Ofast禁用了整型溢出和数组下标越界的检查,因此降低了Swift的安全特性。

Jukka进行了深入分析,他在编译器对另一个测试所生成的汇编代码中,发现一个数组的简单循环产生了大量的内存管理调用(保留和释放),而这是完全没有必要的。这个测试没有涉及数学,因此主要的性能瓶颈似乎来自这些无用的调用。

数名开发人员指出Swift仍然处于Beta状态,这可能是Swift当前这种行为的最好解释。具体来说,文中提到的毫无必要的释放/保留调用暗示了ARC优化存在一些Bug,可能不需要积极优化就可以修复

因为该语言仍处于Beta状态,苹果不会允许开发者提交Swift开发的应用进行审查。Xcode的最终版本预计在今年秋天发布

查看英文原文:Swift Might Not Be As Fast As Apple Claims It To Be: First Benchmarks

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

只是Beta版的錯 by Wu Leonard

希望在Swift正式啟用的時候 蘋果能兌現在WWDC上的諾言

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT