对于使用冒泡排序的C语言和汇编语言之间的速度比较,哪一种通常更快?[关闭]

wvt8vs2t  于 2023-11-16  发布在  其他
关注(0)|答案(3)|浏览(112)

已关闭。此问题为opinion-based。目前不接受回答。
**要改进此问题吗?**更新此问题,以便editing this post可以使用事实和引文来回答。

27天前关闭
社区在24天前审查了是否重新打开这个问题,并将其关闭:
原始关闭原因未解决
Improve this question
我研究了C和汇编语言之间的冒泡排序速度差异,发现代码优化是一个因素。
C语言和汇编语言之间的冒泡排序速度差异还有哪些因素需要考虑,哪种更快?

myss37ts

myss37ts1#

CPU运行机器代码,C编译器可以从C源代码中为您生成机器代码,而汇编语言则需要您自己做出所有重要的决定。
最重要的因素是,冒泡排序是一个糟糕的算法,你基本上不应该使用,特别是当你关心性能(* Why bubble sort is not efficient? *)。(只有当你关心微小的代码大小时,比如代码高尔夫Sort an Integer List)。
除此之外,如果你确切地知道你在asm中做什么,它永远不会比C慢,你可以控制微优化选择,比如那些导致GCC在尝试自动向量化时进行非常慢的冒泡排序的选择。
但是,如果你不知道asm和CPU架构的细节,你就不太可能提高编译器的输出。*没有“一般”适用于所有CPU(微)架构和所有程序员技能水平。
相关:
Why does C++ code for testing the Collatz conjecture run faster than hand-written assembly? * -初学者错误的另一个例子,它会使你的asm甚至比调试C程序的构建还要慢。
如果你想让一个排序函数运行得更快,你首先要改变的是算法,比如插入排序或其他什么,或者SIMD排序网络,特别是如果你首先用的是不可移植的汇编语言。
所以这个问题只有在有什么东西迫使你使用像冒泡排序这样糟糕的算法时才有意义。或者如果你一开始就不以性能为目标,而是随意选择算法。或者不知道冒泡排序很慢,在这种情况下,我们绝对应该对程序员汇编语言技能做出悲观的假设。(汇编语言的性能甚至比大多数语言对程序员的优化技能更敏感。
但是如果有人强迫你花时间优化冒泡排序,使用asm你可能会优化一个元素冒泡很长的情况,也许可以避免存储/重载作为循环依赖链的一部分。但是你可能会在C中用tmp变量做同样的事情,所以IDK是否计数它。
如果你知道它的asm /CPU架构原因,你只会在C中这样做,但通常你可以通过改变C来让编译器生成你想要的高效asm。

mspsb9vt

mspsb9vt2#

C被编译器转换成汇编语言,现在编译器做得很好,甚至比一个非常有经验的人更快,即使他们手中有无限的时间。
这不仅仅是使用哪条指令的问题,还包括它们的顺序。现在CPU有多个内部资源,编译器知道如何优化它们,以便最大化吞吐量。内存加载和存储也被显式优化。
从这个意义上说,在一个CPU架构上运行最快的汇编代码,在另一个架构上可能会很慢,即使是在同一个家族(如Intel)中。因此,C语言作为算法正确性的通用模板,所有艰苦的优化工作都由编译器完成。这种优化工作通常由机器完成得更好。
所以总的来说,我想说,除了非常特殊的情况,如音频/视频或密码学中的SIMD重型算法,C(具有现代编译器)总是赢家。

nxowjjhe

nxowjjhe3#

实际上,速度并没有太大的差异。

虽然Assembly允许您直接访问CPU上的各个寄存器,并且这可能允许您进行一些小的优化,但人类通常不擅长看到这样的小优化。
因此,通常只使用C编程并允许编译器对其进行优化会更好(或者至少不会更慢)。即使没有非常低级别的访问,C编译器通常也可以比人类在汇编中更好地优化程序。

相关问题