与汇编相比,C效率低吗？

Question

可能重复:
汇编程序什么时候比C快？

你好,

这纯粹是一个理论问题,因此,如果有一个"无限"时间来制作一个简单的程序,以及对C和汇编的高级知识,那么在汇编中做一些事情真的更好吗？将C编译成汇编(机器代码)时,"性能"会丢失吗？

根据性能我的意思是,现代C编译器在某些任务中做得不好,直接在Assembly中编程加速吗？

谢谢.

Answer 1

在许多情况下,现代C可以比装配做得更好,因为跟踪哪些操作可以重叠以及哪些操作会阻挡其他操作是如此复杂,只能由计算机合理地跟踪.

是的,您可以执行C编译器可以执行的任何操作,只需*您*必须执行此操作.玩得开心=) (5认同)
@Steven Sudit:Pentium上的情况确实如此,但到了Pentium Pro的时候`rep movsw`又快了.这些说明仍在改进中 - 例如见:http://lkml.org/lkml/2009/11/6/66 (2认同)
+1，并强调这一点：现代编译器通常知道对于数千个不同的CPU（包括实现相同指令集的CPU）来说什么是最有效的。该编译器还知道如何将传统的、更易于人类理解的 C 习惯用法转换为每个特定 CPU 的最高效代码，同时考虑到高速缓存大小、管道深度等因素。编译器并不总是能完美地实现这一点，或者彻底，但它们包含深刻的优化知识，可以利用计算能力在几秒钟内完成人脑需要数小时才能验证的优化。 (2认同)

Answer 2

与任何事物相比,C效率不高.C是一种语言,我们不会在效率方面描述语言.我们在效率方面比较计划.C不写程序; 程序员编写程序.

与C相比,汇编为您提供了极大的灵活性,这是以编程时间为代价的.如果你是一个大师C程序员和一个大师程序员程序员,那么你可能会在编写任何给定的程序时使用Assembly来挤出更多的果汁,但这个价格几乎肯定是令人望而却步的.

我们大多数人都不是这些语言中的大师.对于我们大多数人来说,将性能调优的责任赋予C编译器是一个双赢:你获得了许多汇编大师的智慧,编写C编译器的人,以及你手中的大量时间进一步纠正和增强您的C程序.您还可以获得便携性作为奖励.

+1。我认为还值得补充的是，一个人不会简单地成为一个靠自己*组装*的大师。一个人成为了一个专家，知道什么程序集*在给定的 CPU 模型上*最适合程序，这不仅取决于工作负载，还取决于“透明”的 CPU 详细信息，例如缓存大小和缓存行大小、分支预测器性能、管道深度和在指令集本身下方“隐形”改变的各种其他细节。只要一个贡献者花时间添加对它的支持，编译器就会将每个 CPU 的知识带给所有人。人类大师必须亲自为每个人学习。 (2认同)

Answer 3

这个问题似乎源于错误观念,即更高的性能会自动更好.从更高层次的角度来看,在一般情况下使组装变得更好是太多了.即使性能是您最关心的问题,编译器通常也能比您自己编写的更好地创建高效的汇编.他们对您的所有源代码有了更广泛的"理解",而不是您可能掌握的内容.可以通过NOT使用结构良好的程序集进行许多优化.

显然也有例外.如果您需要直接访问硬件,包括CPU的特殊处理功能(例如SSE),那么组装就是您的选择.但是,在这种情况下,您可能最好使用更直接解决一般问题的库(例如数字包).

但是你应该只担心这样的事情,如果你有一个具体的,特定的需要提高性能,你可以证明你的程序集实际上更快.具体的具体需求包括:注意和测量性能问题,性能是基本设计问题的嵌入式系统等.

Answer 4

除非您是汇编专家和（或）利用编译器未使用的高级操作码，否则 C 编译器可能会胜出。

试试吧 ;-)

更现实的解决方案通常是让 C 编译器做一点，然后分析，如果需要，调整特定部分——许多编译器可以转储某种低级 IL（甚至“汇编”）。

Answer 5

对大多数任务使用C,并为特定任务编写内联汇编代码(例如,利用SSE,MME,...)

Answer 6

这取决于。Intel 的 C 编译器现在做得相当不错。我对 ARM 的编译器印象不深 - 我可以轻松编写内部循环的汇编版本，其执行速度是原来的两倍。您通常不需要在 x86 机器上进行汇编。如果您想直接访问 SSE 指令，请研究编译器内在函数！