C++之那些年踩过的坑-阿里云开发者社区

开发者社区> 茶花盛开> 正文

C++之那些年踩过的坑

简介: C++之那些年踩过的坑
+关注继续查看

上次提到了一个问题:代码优化。并留了一个小测试:无符号数与有符号数的性能比较。不知道有没有人去实验。我做了一个简单的测试:

C++之那些年踩过的坑

#include <iostream>#include <chrono>int main()

C++之那些年踩过的坑

在上述代码在 VS 的 Debug 模式下运行(Release就优化掉了),稳定后运行时间在 2800ns,然后把注释去掉,再次运行,稳定后运行时间还是 2800ns。在我在电脑上,计算有符号类型和无符号类型几乎是没有差别的,我相信在绝大多数的电脑上也是相同的结果。

类似的还有浮点数的计算比整型数慢

首先我要声明:我不是反对代码优化。对于有很多流传广泛的所谓的优化技巧,我觉得我们应该应该抱着学习探索的心态,而不是一味地追求一些没有什么意义的东西。有些优化,确实很精妙。但很多所谓的技巧,看起来的意思就是:做编译器的那群人都是傻逼。想优化我们的程序,这是正常的、应该的想法,但我们应该用科学的方法,而不是听了一些奇淫技巧,却不知道里面发生了什么。

其实很简单,探究性能瓶颈靠 profiling,探究代码背后的不为人知的故事看 assembly。我们先讲后面一个。如果你想学习C/C++可以来这个群,首先是三三零,中间是八五九,最后是七六六,里面有大量的学习资料可以下载。

我想大多数人还是在 Windows 下编程,所以用的肯定也是宇宙最强 IDE VS。在 VS 下看汇编很简单,随便设置一个断点,然后按调试下面的开始调试,然后在打开在调试下的窗口找到反汇编,就可以看了。比如我们研究有符号数和无符号数,先写一个程序:

int main()

然后按照刚刚的方法(在 Debug 下)看反汇编:

C++之那些年踩过的坑

/*unsigned */int a = 123456789;00B4104E mov dword ptr [a],75BCD15h

C++之那些年踩过的坑

然后在把注释去掉试试:

C++之那些年踩过的坑

unsigned int a = 123456789;00C3104E mov dword ptr [a],75BCD15h

C++之那些年踩过的坑

几乎是一模一样的,最大的差别就是有符号数使用 idiv指令(带符号除法),无符号数使用 div指令(不带符号除法),而这两种指令,CPU周期都是一样的。

当然我不是说不用无符号数,而是说我们用什么要看场合,而不是你觉得用了性能更好,除非是被大众认可的或者你经过严谨的测试的。像对于某些书籍或者什么地方说,只要确定范围不为负数的,就用无符号类型,我是不认可的。如果你讲范围,那如果一个有符号类型不够用,那么通常(相同bit下)它对应的无符号类型也不够用。比如你 int32_t 不够用,就应该用 int64_t,如果还不够,考虑写个 BigInteger类 吧 :) 。不过对于无符号和有符号类型,它们之间的性能在当代确实是几乎没有什么差别。那具体什么场合用什么呢?这个也不一定,比如一般来说:

  • 对于位储存、位运算、模运算等,使用无符号类型

  • 对于一般运算使用有符号类型

其实我对于无符号有符号是觉得很那个什么的。。平时我们说一个数,要么就是整数,要么就是小数得了,还要去分有没有符号那真的是。不过因为是 C++ 所以也就没什么奇怪的了。

好像有点偏离我想说的主题了(拽回来

我并不是想专门讲这个什么有符号无符号,而是想借这个题引出(我的)一些看法:

  • 过早的优化是万恶之源

  • 不要试图帮编译器优化

  • 优化时不要去猜测,想当然得去优化自己“觉得”性能差的地方

  • 探究性能的瓶颈靠 profiling

我们一点一点讲。

对于一个需求,我们应该先完成功能,若性能达不到要求之后,在确定瓶颈之后再去优化。过早优化,不仅让代码不直接,还容易出bug,还可能对性能几乎没有影响。而且,我们优化时,应该关注大方向,确定大方向是正确的。比如写一个算法,我们首先应该确保 Big-O 的时间复杂度能达标,可以用 O(n) 的就不用 O(nlogn),可以用 O(nlogn) 的就不用 O(n²),而不是先在那里扣 i++ 还是 ++i。另外,不要想着去帮编译器优化,因为编译器是一堆比你强不知道多少的人写出来的,而对于一般人,想着去帮编译器优化,大部分是无效的,少部分是错的。比如有人学了一点点 std::move,就老是想着 move move move 去提高性能,举个栗子,(不同的)容易写出这样的代码:

template <typename T>T create()

确实运行不会错,但是,代码背后做的事情不一定就跟你想的一样,往往跟你想象的还不一样。有些情况编译器可以采用更好的办法,结果因为你那么一搞,迫不得已只能采用次一点的办法。可以看看 这个问题 ,不赘述了。

还有比如说用异或来交换两个变量,有人就会想,用位运算,不仅不需要创建临时变量,而且位运算一般不是更快嘛!

如果你已经看了上面的链接,那么你也就知道了,你(几乎)不会知道编译器做了什么,编译器可以做的优化超出你的想象(不过有的时候人能明显看出来的优化编译器却做不到,但影响不大),在我的系列文章(二)中也反复强调了,不要试图帮助编译器去优化。若你想探究一小段代码背后的细节,就去看反汇编吧!

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Human vs AI,人类和机器的学习究竟谁更胜一筹?
在各种任务中人类的学习能力和机器的学习能力究竟哪个更胜一筹?
6 0
Java 性能优化:35个小细节,让你提升Java代码运行的效率
  代码优化,一个很重要的课题。可能有些人觉得没用,一些细小的地方有什么好修改的,改与不改对于代码的运行效率有什么影响呢?这个问题我是这么考虑的,就像大海里面的鲸鱼一样,它吃一条小虾米有用吗?没用,但是,吃的小虾米一多之后,鲸鱼就被喂饱了。   代码优化也是一样,如果项目着眼于尽快无BUG上线,那么此时可以抓大放小,代码的细节可以不精打细磨;但是如果有足够的时间开发、维护代码,这时候就必须考虑每个可以优化的细节了,一个一个细小的优化点累积起来,对于代码的运行效率绝对是有提升的。
12 0
如何让Transformer在GPU上跑得更快?快手:需要GPU底层优化
Transformer 对计算和存储的高要求阻碍了其在 GPU 上的大规模部署。在本文中,来自快手异构计算团队的研究者分享了如何在 GPU 上实现基于 Transformer 架构的 AI 模型的极限加速,介绍了算子融合重构、混合精度量化、先进内存管理、Input Padding 移除以及 GEMM 配置等优化方法。
6 0
重磅发布开源框架2.0RC版 、生物计算平台「螺旋桨」,百度飞桨交了份年终成绩单
在 12 月 20 日举行的「WAVE SUMMIT+ 2020 深度学习开发者峰会」上,飞桨平台交出了一份非常亮眼的年终成绩单。
6 0
表现优于ViT和DeiT,华为利用内外Transformer块构建新型视觉骨干模型TNT
华为诺亚实验室的研究者提出了一种新型视觉 Transformer 网络架构 Transformer in Transformer,它的表现优于谷歌的 ViT 和 Facebook 的 DeiT。论文提出了一个全新的 TNT 模块(Transformer iN Transformer),旨在通过内外两个 transformer 联合提取图像局部和全局特征。通过堆叠 TNT 模块,研究者搭建了全新的纯 Transformer 网络架构——TNT。值得注意的是,TNT 还暗合了 Geoffrey Hinton 最新提出的 part-whole hierarchies 思想。在 ImageNet 图像
4 0
2020学术会议回顾:从这些最佳论文中一窥研究趋势
2020 年,是充满变化的一年。人工智能学术会议也不例外,线上举办、改革评审制度、增加可复现性要求、伦理要求等,这些是「变」。而不变的是大家对学术会议的热情,以及我们总能透过这些会议探究学术前沿发展趋势。
3 0
成立两年,清华出身的他们用产品描绘出了基于第三代AI的基础设施蓝图
「第三代人工智能」能帮助我们做什么?瑞莱智慧 RealAI 用两年的时间给出了一个答案。
6 0
登上NIST竞赛榜单,获得BCTC增强级活体认证:小视再攀高峰!
你的人脸不会被恶意「盗刷」,也有小视科技 AI 算法的一份力。
7 0
+关注
茶花盛开
web前端新手群291851189
217
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载